Full system restore


Is restic suited for a full system backup/restore? ea. backing up / and restoring to /?


I haven’t restored a complete system yet, but received reports that this works well. One thing that I can imagine that may be good to know: when you use --one-file-system to exclude things like /proc the directory /proc itself is also not included in the backup, so you’ll nee to recreate it manually.


thanks! I figured out backing up /home /root /var and /etc covers most of what I need. Can I make it more verbose during restore? I can’t see any progress in restoring files. Once I stop it I see it has done something, but that’s not so nice.


restore won’t display progress information, that’s not yet implemented, but there are plans to add it.


Hmm, I’m not sure I like that: Filesystem A contains a directory where another filesystem B is mounted on. If I back up filesystem A, then the directory (in filesystem A) should be backed up - after all, it IS part of filesystem A…


I agree and I think we need to change this (see #909), but this requires implementing additional code to detect it. From a program’s point of view, the directory filesystem node for e.g. /proc that is returned by the statsyscall is the root node of the procfs, so e.g. the modification timestamps, ownership and access bits can be completely different.



I just found this project on Backblaze B2 blog and I decided to try out. I haven’t found any recommendation or guide to how to make a full system backup with Restic.

I think I need the --one-file-system command, but what about the symlinks etc.? I want to make a restorable system backup from my Ubuntu/Debian server.

If anyone did a successfull backup and restore with restic, please post here.


You can use restic backup with --one-file-system and then list all directories that you’d like to save on the command line. Please be aware that there’s a limitation in restic at the moment which only retains the last path element, it’s tracked here (and we’re already working on a solution): https://github.com/restic/restic/issues/549

A workaround for a full system backup and restore is to backup / and use an exclude file to list all the contents of all mountpoints that you don’t want to save, e.g. like this:

$ cat ~/.restic-excludes

$ restic backup --exclude-file ~/.restic-excludes /

This way, the structure in the repository will match your filesystem. Excluding the contents of a directory (/proc/*) instead of the directory itself (/proc) ensures that the directory will be there (and empty) after restore. This is also a current limitation, tracked here: https://github.com/restic/restic/issues/909

You don’t need to worry about things like symlinks, hardlinks or device files: They will be saved and restored exactly as they are now. If something is a symlink before, it will be a symlink after restore.

But please make sure (as with every backup solution) that you thoroughly test restoring, check that everything is really saved (e.g. by using the fuse mount and browsing around a bit), and that backups are run regularly.


Thank you for the answer. #549 bug is pretty serious, I’ll wait for a fix until I replace Duplicity.

Excluding with * is great idea, because empty system dir is better than a non existent.

Can I use restic like this?

sudo restic -r b2:rpi3-fullbackup backup --one-file-system --exclude /dev/* --exclude /lost+found/* --exclude /media/* --exclude /mnt/* --exclude /proc/* --exclude /sys/* --exclude /tmp/* --exclude /var/cache/apt/* /

Or --one-file system is excluding example: /dev/ so the next --exclude /dev/* is ignored (which means no folder is created)? Which has higher priority?

Can we know what directories are excluded when I use --one-file system? I think I need this, because I have various NFS servers mounted in my home dir and --one-file system guarantees that these mounted folders are not backed up.


You can use restic like that, but make sure to quote the arguments, like --exclude "/dev/*". You don’t need --one-file-system any more, but if you specify it, it gets the higher priority because the /dev directory is the root node of the other file system, so anything below (e.g /dev/sda) is never even tested. So you also won’t get an empty directory.


In the past I have used a command line like this:

mount | egrep -v '^/dev/(xvd|sd|mapper|md0)' | cut -d' ' -f 3  > exclude.list
restic --exclude-list exclude.list /

On Linux this mostly removes anything that is not a local drive.
You might want to tweak the script to add the dir/* to the end as suggested by @fd0.

Note: I currently use this script for a different backup program, but it seems like it should work for restic. As always test carefully.


FWIW, I did exactly this a few days ago. A disk on one of my machines unexpectedly and completely failed. I installed a replacement disk temporarily on a working machine, partitioned it, restored my restic backup to the new disk, and moved the new disk to the “broken” machine. Worked perfectly :sweat_smile:. The only hiccup was that I needed to manually update the bootloader (grub in my case) after the restore, presumably to rebuild the MBR etc. (of which restic is of course unaware).

I’m a happy customer!

I should perhaps add that I’ve been following @fd0’s suggestion:

Without this, I would have also needed to recreate several directories manually.


One more question:

Is there any tar like --numeric-owner switch?

–numeric-owner - This option tells tar to restore the numeric owners of the files in the archive, rather than matching to any user names in the environment you are restoring from. This is due to that the user id:s in the system you want to restore don’t necessarily match the system you use to restore (eg a live CD).


No, restic always uses the numeric user ID