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

  • 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.
    – oldfred
    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.
    – Lizardx
    Commented Aug 24, 2020 at 19:02

2 Answers 2


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.

  • 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=
    – Krackout
    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

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:
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
      search --no-floppy --fs-uuid --set=root 4e97fe69-93ae-4e6a-a2cc-3406cb21176c
    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! :)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .