Moving hassbian install from pi3B to pi3B+

I have hassbian installed on a pi3B and I managed to get zwave working, add 4 zwave devices, configure a few automations, link to my alexa etc. I was just playing around while I waited for my newer pi3B+ to arrive.

Now I have the new pi and a raspbee hat that I want to switch over to. I have that up and running also with a fresh hassbian install.

Can I now just shut down both swap the SD card from the older pi and move the zwave stick over to the pi and continue from where I left off?

Or should I exclude the 4 devices, and just build up the new system?

I am tempted to try the move just as a learning experience but I figured I would see if anyone knows if this approach should work.

I think the included devices are basically stored on the zwave stick and configured in entity_registry.yaml and the other configuration files right. So other than perhaps needing to change a fixed IP I was thinking this should work.

as long as Raspbian is up to date, just swap in the card. I’d also back up the card in case…

@DavidFW1960, thanks for quick response.

And move the zwave stick over. I have a new stick but think it is best if I move the old one over to the new pi, the other pair will become my work HA config when I am done. Any I correct that the zwave stick holds the pairing info?

Thanks, What do you use to backup? I found instructions on backing up from command line in mac os but it only backs up the boot sector so it doesn’t work.

I installed Apple-Pi Baker also but have not tried that yet.

I am curious how they make the images that install with etcher. Etcher seems to only be a one way tool from img to card.

Just plug the card into your computer and use something like win32diskimager to create an image. This should be no issue with Raspbian/Hassbian.

Yes I’d also transfer the shave stick - everything the same as before.

Thanks, I am looking for a program that works on mac osx. I have used win32 imager but I don’t use a windows much anymore so was looking for a good option for my macbook.

Ah no idea. Etcher only goes to writing to a card. You’d need to google it.

On OSX you can use the command line utility “dd”.

I use Apple-Pi Baker all the time it works great.

This is the command I mentioned that doesn’t work. I find these steps documented all over the place but when I try to backup a 32gb card with at least 2gb of data it creates a really small image. It seems to only see the boot sector and backs up only that sector. Which of course doesn’t contain any of the data we are trying to backup.

Thanks, I have heard good things. I will give it a try.

Actually under the hood most of these SD backup and image writer apps are just fancy front-ends to dd. Once you understand how it works it gets your job way easier.
Try this: https://www.howtoforge.com/linux-dd-command/
And this: https://www.howtoforge.com/tutorial/linux-dd-command-clone-disk-practical-example/

They explain what dd does. Be aware that it is quite easy to overwrite something with it. Always think before you press enter :slight_smile:

I have followed many documents on how to clone raspberry micro-sd cards and these instructions seem to provide the same commands. But when I run the dd command to backup my cards I get an image that is way too small and when I try to restore from them it doesn’t work. So somehow this doesn’t work correctly on mac os or there is something I am still missing. It’s been a while since I tried this but the commands look the same as what I have always tried. I guess the key to using the wrapper tools is they get the commands right :slight_smile:

Use this all the time,

Backup - make sure you get the source right, you dont want anything with a number on the end, e.g. sdb1…4, as you’ll just be backing up a partition, should just be sdb, thats the whole device. Name may vary depending on whether its a HDD or your using an SD card.

dd if=/dev/sdX conv=sync,noerror bs=4K status=progress | gzip -c > /home/pi/backup.img.gz

Restore - again make sure you get the restore location right, or you could wipe something out. Again should not be something with a number (e.g. sdb1) but the device (e.g. sdb).

gunzip -c /path/to/backup.img.gz | dd of=/dev/sdX conv=sync,noerror bs=4K status=progress

Easiest to grab something like GParted to look at your HDDs and get the correct device. Check the size and expected partitions from there. As mentioned be very careful, its secondary name ‘Destroyer of Disks’ isn’t for nothing.

Thanks! that must be the key. Every example I read uses a device with a number on it so when I try it I just get the partition. Thanks for sharing the actual command example, that really helps! I will give this a try. I am an old school command line kinda guy so I was bummed that I couldn’t get this working from what I was reading.

Ron

Some devices do show up with a number instead of a letter though, specifically some sd card readers, so it may look like this,

/dev/mmcblk0 - SD card
/dev/mmcblk0p1 - SD Card Partition1
/dev/mmcblk0p2 - SD Card Partition 2
… etc

So /dev/mmcblk0, not the ones with p1,p2,p3

Also there was mention about the sizes of backups can’t possibly be correct.

If run without gunzip, it will backup every block on the device, including empty space, so a 32GB SD card, that only has 100MB of data, will be 32GB.

Gunzip compresses out the empty space, and would compress it down to a bit over 100MB. You will still need to read in, and write out all 32GB though (even with only 100MB used on the filesystem), so it will take a while.