UZB/RaZberry Firmwares - Update

[ArcherS]

For all systems backup is a vital part of the long-term usability.

I thought that I describe my set up with Z-way so far. Hopefully others can fill in with their backup thoughts as well. I am sure that there are much more streamlined ways of doing this and hope to learn from you all.

I run Z-way on a Raspberry Pi 3B+ with a daughter RaZberry card. In order to reduce the risk of getting corrupt SD cards I have it running off an SSD. So far this works very well. Setting it up was really easy just reading a standard Raspbian image onto the SSD. The only minor obstacle was that I had to test a few old 2.5" enclosures to find one that the Pi liked.
The Pi is then also powered via an UPS, hopefully this will avoid problems in the event of power outages.

In order to backup Z-way I have so far done manual backups from the regular Smarthome backup & restore function creating .zab files and from the Expert UI creating .zbk files. As far as I have understood the .zab files which are bigger contain more information than the .zbk files. The strategy so far has been to make backup files after each inclusion/exclusion. Also before updating Z-way. I have yet to test restoring from these files.

From Smarthome it is also possible to set up cloud backup. I have not yet set up this as I need to decide that it is safe enough to do so. On the other hand I had this set up on my two Veras.
It would have been nice to be able to schedule a local backup of Z-way instead of having to put them in the cloud, perhaps from OpenLuup via the Z-way bridge?

In addition to the built in backup function I try to do complete image copies of the SD cards on my Pi's with Win32DiskImager. When I moved to an SSD the image file grew to the size of the SSD since it is a raw copy including all the empty space. Image files of 160GB are not practical to handle so I found a good instruction on how to shrink the .img file with Gparted in Linux: https://steemit.com/raspberrypi/@wizzle/shrink-raspberry-pi-images-using-windows-virtualbox-running-raspberry-pi-desktop
By shrinking the .img file with Gparted it is now a more reasonable 4GB. These file are stored on my NAS for safekeeping. The strategy here so far is to make a new image file before updating Z-way and to use these in combination with more frequent Z-way backups.

I have tested restoring a Gparted shrinked .img file to the SSD when my Z-way for some strange reason became unreachable through the regular UI but remained reachable through the Expert UI. Always good to test the restore function and to see that it works.

The downside of the .img strategy is that I need to power-off the Pi for a while when making the backup. However if the Z-way backup files work then the complete .img backup need not be done so very often.

//ArcherS

[kfxo]

@ArcherS said in Z-way backup strategy:

The downside of the .img strategy is that I need to power-off the Pi for a while when making the backup. However if the Z-way backup files work then the complete .img backup need not be done so very often.

//ArcherS

This is good information. However, no need to power-off the pi for a while as you can clone the SSD to a USB drive and then make the .img from the USB. Check out rpi-clone: https://github.com/billw2/rpi-clone . I just succesffully used this method yesterday.

[ArcherS]

@kfxo Thank you for the link; I did not know about that way of cloning. I will look into it.
It could perhaps also be a good way to make a clone of the SSD in my Ubuntu PC (an old Fujitsu i3) that I am running OpenLuup on.

Regards
ArcherS

[powisquare]

There's an option on pi in Accessories - SD Card Copier which clones the sd card. Don't know if it works on SSDs. I rotate the cards (8gb) and keep one in the drawer just in case. After reading posts I wonder if I do need SSD now though.

[powisquare]

@kfxo said in Z-way backup strategy:

@ArcherS said in Z-way backup strategy:

The downside of the .img strategy is that I need to power-off the Pi for a while when making the backup. However if the Z-way backup files work then the complete .img backup need not be done so very often.

//ArcherS

This is good information. However, no need to power-off the pi for a while as you can clone the SSD to a USB drive and then make the .img from the USB. Check out rpi-clone: https://github.com/billw2/rpi-clone . I just succesffully used this method yesterday.

Is it possible to copy the .img across a network?

[kfxo]

@powisquare said in Z-way backup strategy:

Is it possible to copy the .img across a network?

I'm not really sure what you are asking. Once you create the .img you can do whatever you want with it, including copying it across your network to a different storage location.

[DesT]

If that can help others... I'm running all these in a VMs and using RaZboard or UZB with a raspberry just to send out the serial traffic over the network to the VM that run z-way!

So in my case, the only thing I need to do on rPI it's installing debian + sending the traffic to the VM!
Of course, all the VMs are doing backup!

[PerH]

@dest
I wondered about doing the same, but with 3 devices. RFXTRX, Zigate and UZB. Just wondering if the extra communication link could make a noticable latency? Gues not, as it's ethernet?

My backup plan is to have a script that copies the config files of the systems to a network location. If total breakdown occurs, I run a docker-compose file on a reset system and copy in the config files. Should be an OK plan right?

[powisquare]

@kfxo said in Z-way backup strategy:

@powisquare said in Z-way backup strategy:

Is it possible to copy the .img across a network?

I'm not really sure what you are asking. Once you create the .img you can do whatever you want with it, including copying it across your network to a different storage location.

I read somewhere the card is unmounted after writing a backup using the in-build card copier. This is to prevent two system images competing with each other. Would the rpi-clone .img have the same issue?

[powisquare]

@dest said in Z-way backup strategy:

If that can help others... I'm running all these in a VMs and using RaZboard or UZB with a raspberry just to send out the serial traffic over the network to the VM that run z-way!

So in my case, the only thing I need to do on rPI it's installing debian + sending the traffic to the VM!
Of course, all the VMs are doing backup!

This sounds ideal. I have a rpi in the cupboard behind me doing the heavy lifting already. Is there a guide available to do this?

[kfxo]

@powisquare said in Z-way backup strategy:

@kfxo said in Z-way backup strategy:

@powisquare said in Z-way backup strategy:

Is it possible to copy the .img across a network?

I'm not really sure what you are asking. Once you create the .img you can do whatever you want with it, including copying it across your network to a different storage location.

I read somewhere the card is unmounted after writing a backup using the in-build card copier. This is to prevent two system images competing with each other. Would the rpi-clone .img have the same issue?

rpi-clone does not actually create an .img but instead clones the booted source disk, e.g. if you boot from a SD card, while running, you can clone the SD card to a USB drive so you can boot from the USB drive if the SD card fails.

[powisquare]

Which one would that be out of the various methods on https://github.com/billw2/rpi-clone ?

[powisquare]

As i understand it in layman's terms rpi-clone will backup an installation to a connected USB. This creates a bootable copy of the system. If one wanted to copy that copy across a network to safe storage would that be possible? Just been reading about dd comand https://robotzero.one/headless-pi-zero-backup-clone/ that creates an .img file of a running system. Is that the way to go to have something transferable? Without having a SSD is it safe enough to have just a USB plugged in and rpi-clone?