Hello,
What is the best way to have a 'ready to use' backup SD of my running one?
I'm using the ext4 image, and would prefer no downtime.
Thanks
Use dd to crate an image
Using dd from a live filesystem may/will produce errors, I may fix them with e2fschk but I'm looking for something more error proof.
Not on the live system. Use a card reader offline.
You could try to remount /overlay as ro.
I'm looking for an online tool
/overlay ? With an ext4 image ?
I'd recommend the simple approach...
- Write a card with the same image as you have running on the live system
- You can use custom images generated by ASU/Firmware Selector that contain all the same installed packages.
- Make a backup of your live system using the LuCI/sysupgrade backup method (this backs up your config files and any other specific files you choose -- it is not intended to backup the entire image, but typically just the configs and other user files).
- Boot the second card and then "restore" your backup to the new card. After this, you have a working backup card.
- Create backups whenever you make further changes to your live config... you can repeat the above step when desired (or if/when you actually need to run the backup card so that it is consistent with that latest config).
Thanks,
but it requires some donwtime 
Why does my method require downtime?
- You can write the card using any card reader on a Linux/Mac/Win machine.
- You can create backups from the live system using the browser or terminal from that same machine.
- Only booting the card to load the backup would require using the "live" hardware. But you could actually defer that until such time as it is necessary (it's literally a 2 minute operation or less).
Running DD will also require downtime as you must pull the card from the live system.
I create live backups of my Linux systems using rsync.
To do this, I mount the partition(s) to /tmp/xyz and copy the data from there using rsync.
This way, you get the actual contents of the drive without /proc, /dev, /tmp, etc..
I'll try it,
thanks
I need to do a new full copy of the SD with dd after a sysupgrade because it changed my partion uuid, and rsync'll copy the new cmdline.txt containing the new uuid to the backup sd still with the previous uuid. That may prevent mounting the root partition at boot time.
So: I'm doing a full dd backup after sysupgrade and later rsync to keep it updated.
You can also set the UUID manually...
tune2fs /dev/yxz -U UUID
You can also write a script to do all of this automatically.
It should work without any problems with ext4, I've done it myself quite a few times.
sounds like a crime but I know some people use tar -czvf /tmp/Full-backup.tar.gz /overlay so they can later restore it using the backup option in luci.
I just took a quick look at the OpenWRT RPI image...
You mean /boot/partuuid.txt and /boot/cmdline.txt?
If that's the only problem, no one's forcing you to include the file in the backup (rsync has an --exclude option).
And as I said, you can also change the UUID manually using tune2fs on an ext filesystem.
There is no /overlay data with the ext4 images
One thing I'd highly recommend, regardless of what method you use...
Grab a spare card and attempt to restore your entire setup to that card. Then swap the cards in the Pi5 (obviously power cycle the Pi) and make sure it boots properly and has all of the expected functionality.
The last thing you want to deal with in a crisis is the inability to restore your previous state because of some wrinkle in the data restoration process.
Also, it doesn't hurt to have more than 1 restore option available... for example, if you prefer to use the dd method, no problem. But also keep a copy of the OpenWrt image (ideally with all the desired packages included) and a regular backup generated by OpenWrt... that should always work and the files are pretty small so not a big deal to have stored.
Yes a backup need to be tested 
.
I''ll also keep the firmware image and a copy of my parameter somewhere else. Thanks for the idea.