5

My intended order of events is as follows:

Backup most of root

sudo rsync -aAXv --delete --exclude={/dev/*,/proc/*,/sys/*,/mnt/*,/media/*} / /BACKUP

Reverse the process

sudo rsync -aAXv --delete --exclude={/dev/*,/proc/*,/sys/*,/mnt/*,/media/*} /BACKUP /

I'm nervous to try the 2nd part without some sanity checking first, hence the post. The --dry-run outputs all look okay, but still want to check first

Improve this question
2
  • We usually do not back up / (root) as it is just as easy to do a new install & restore /home, list of installed apps and perhaps some settings in /etc. If a server you may need the server apps folders like database or web apps. & data. Commented Aug 24, 2020 at 18:59
  • 2
    You want to exclude /run and /var/run as well I believe. Can't remember if there are more. But a good rsync question!. Also /tmp and the various /cache/ directories if relevant probably should be excluded as well. Commented Aug 24, 2020 at 19:02

2 Answers 2

Reset to default
9

For a complete system backup-restore using rsync I've successfully used:

backup command:

sudo rsync -aHAXS --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /* /backup

I've also added -H for hard links. I strongly propose you to use it. And -S, in case you have sparse files. I had lots of them, for VMs.

For restoring, I used a live cd/usb, mounted the empty, freshly formatted soon-to-be-/ disk on /mnt and then,

restore command:

sudo rsync -aHAXS --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /backup/* /mnt

Took care of the soon-to-be /etc/fstab (/mnt/etc/fstab), have a look on grub.cfg also, rebooted and everything ran smoothly.

Regarding exclude, lost+found is not available in some filesystems, XFS for example, so it can be omitted if such an fs is used; no harm done though if it's included.

Improve this answer
4
  • great answer for good backup practice, but the question was mainly asked regarding backing up to a directory that exists in root. I'm curious if that process you described can be done, minus the live cd/usb Commented Aug 25, 2020 at 12:31
  • What I described can surely be done, I've done it many times! I suppose it would be the same if the backup/restore directory is somewhere on the disk (/BACKUP for example) you just have to add it to --exclude= Commented Sep 6, 2020 at 14:50
  • can you please detail the -H (hard links) option? Why do you strongly advise it? What would happen if not? Thank you Commented Sep 21, 2023 at 21:41
  • 1
    Found it in the manual, of course :). It states: This tells rsync to look for hard-linked files in the source and link together the corresponding files on the destination. Thanks for the suggestion ! p.s. Awesome use of bash(?) extension for the exclude={...} part ! Commented Sep 21, 2023 at 21:47
2

The best sanity check is to actually boot from the backup.
That is the only way to be 100% sure, by testing it for real!
You wont be able to do that from a folder inside root as far I know. (Actually, the destination I use is "a folder inside root tree" but at /media/$USER/RootBackup that is actually another filesystem.) You wont even need to restore the backup to promptly use it, in case you are in a hurry and something bad happens, just boot from the backup, and restore it later!

With rsync, it is quite fast to just update a backup of the root any time you need. I do it everytime before I am going to update kernel and other core packages on ubuntu 20.04.

Obs.: In case you use LVM too, I discarded LVM snapshot as an option for being extremelly slow.

I am using this command:
sudo rsync -axHAXv --delete-excluded / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /media/$USER/RootBackup/
I run it a few subsequent times to grant no important files changed.
The importance of --delete-excluded is to really keep it in sync (identical).

I also backup /boot separately because it is another partition mounted there, with:
sudo rsync -axHAXv --delete-excluded /boot/ --exclude=/lost+found /media/$USER/RootBackup/boot/

After the first time you run it, do this:
grub-update
but it did not work properly here, it kept pointing to the LVM device, instead of the new filesystem I created, so I did this:

mount |grep RootBackup #copy the device name, ex.: sdb4 ls /dev/disk/by-uuid/ -l |grep sdb4 # copy the UUID ex.: 4e97fe69-93ae-4e6a-a2cc-3406cb21176c

now copy the new menuentry from grub.cfg to /boot/grub/custom.cfg (I use gpt here, you may not need this, just copy and modify the menuentry generated by grub-update as needed):

menuentry 'RootBackup by UUID' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'osproberfailed-manualadjustment-gnulinux-simple-4e97fe69-93ae-4e6a-a2cc-3406cb21176c' { insmod part_gpt insmod ext2 set root='hd3,gpt13' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd3,gpt13 --hint-efi=hd3,gpt13 --hint-baremetal=ahci3,gpt13 4e97fe69-93ae-4e6a-a2cc-3406cb21176c else search --no-floppy --fs-uuid --set=root 4e97fe69-93ae-4e6a-a2cc-3406cb21176c fi linux /boot/vmlinuz root=UUID=4e97fe69-93ae-4e6a-a2cc-3406cb21176c ro quiet splash $vt_handoff debug --verbose initrd /boot/initrd.img }

obs.: the important modifications needed after the grub-update auto generated menuentry were:

  • grant the corret UUID was set. Note that search and linux commands are using the same UUID, as the whole backup ended up in a single partition.
  • vmlinuz and initrd had to be searched at "/boot/" and are using the automatic symlink to not require maintenance
  • linux command had to use root=UUID=... because /dev/sdb4 randomly changed to sdc4 and was unreliable
  • dont use the PARTUUID as it wont work.

To restore, boot from the backup, so the source path will be /, but the destination will be something else that you will have to mount.

Just in case you do not run the main root backup procedure for too long:

  • boot from the working backup root
  • create a second backup from the main root FS
  • restore the working backup root over the main root FS
  • boot from the main root FS
  • as soon you find something is missing or wrong, get what you need from the second backup you just created.

I hope you can be as tranquil as I am now on a desktop PC, w/o no-break, and needing to update core system files with critical updates! :)

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.