Full snapshot, howto?

Hello everyone

I’ve been using Restic for a couple of weeks and so far so good. I’m not an expert so be kind.

I self host and I am using Restic to backup emails and the var/www folder every night using Cron.

What I’d really like to do is to backup or snapshot the whole system.

So for now I do

restic -r /mybackup drive/ backup /var/www

If I want to backup everything would it be as simple as:

restic -r /mybackup drive/ backup /

ie just / (root)?

Something tells me it won’t be that simple :slightly_smiling_face:

Many thanks


Basically, yes. But there are some special files on your system that you don’t want to back up, for example the /dev, /proc filesystem and probably /tmp as well. So you should of course exclude these.

But other than that, restic will back up the files that you tell it to back up and that it can read successfully.

@rawtaz thanks very much for your reply. I did play with backing multiple folders which worked as specified. I didn’t really think about folders that shouldn’t however so thanks for the heads up

I realise and understand that you can’t comment on a particular system, but mine is a Debian based self host server, YUNOHOST. So if I backed up the following:

/etc for server config and ./yunohost config
/home for user data etc.
/var/www for the obvious web servers
/opt/yunohost (other servers get put here)
/var/lib/mysql for databases

Is there any other “system” folders you think I should grab or is the quicker way to:

Backup everything (/) then exclude the folders you mentioned?

Six of one half a dozen of the other as we say here.

One last thing. Does Restic backup hidden files contained in a folder, I’m guessing it does?

Again thanks for your help. I appreciate it.


Generally, and personally, I only back up the specific paths I want to back up, which is documents and data, rather than backing up everything and excluding what I don’t want. That works for me because I know what I want to back up.

There’s nothing really wrong with either approach. Do what is easiest and leaves you with the least risk of not having something you wanted backed up not backed up. So perhaps if you are unsure it’s better for you to back up / and add some excludes (you can do that using --exclude-file as well).

Sounds to me like you covered most of the paths that might contain data. It really boils down to which software you use, and it seems you covered your web server and the database server, as well as “home” files and configuration files under /etc. Perhaps also /usr/local/etc if you have anything there? Or even /usr/local.

I can’t really say for sure about the hidden files, I suggest you simply try it to know 100% for sure :slight_smile:

Again @rawtaz many thanks for you help, good stuff. Appreciate you time and advise.

I’ll have a play and see how it goes.

Have a great day


No problem, let us know if you have any other concerns!

A positive thing with doing like this is that if you for example temporarily connect an external hard drive and let it be connected for a day or two, it won’t be backed up and you will not add a lot of unwanted stuff to the repository.

you are backup up config (/etc) and data (user, www and mysql).
i think this is in the first step very good.
if you have to do a restore on a new machine you will get all the data back (hopefully).

is this a shared host or is it a VM that only you have access to?

BUT: what is about additional installed libs and apps and programms? eg when you do apt-get install xxxx or if you install any programms via node/npm or gems via python. do you have things in /opt?


Thanks very much to everyone for their help. I did a successful backup of all the required directories followed by a keep last three prune. All good. Let’s hope I don’t need it!!!

Have a great day all and thanks again.


1 Like

I suggest you to backup databases using periodical dump (mysqldump in your case) first and then add db dump file to the restic backup list. Or pipe mysqldump output directly to restic: rtfm
Just try to restore your current /var/lib/mysql on the “clean” Debian host - DBs might be corrupted and not accessible.

Secondly, add /var/spool/cron to the backup list.

  • and actual list of installed packages (deb/python/php/whatever in use)

Also a good practice is periodical testing your backup by restoring on fresh VM - the only way to be sure and safe.

1 Like

I usualy do full system backups with

restic backup -q --exclude="/var/cache/*" --exclude="/proc/*" --exclude="/sys/*" --exclude="/tmp/*" --exclude="/var/tmp/*" /

depending on which linux flavor you use, you maybe have to exclude some other virtual directories. Or you take a look at the option --one-file-system, which excludes directories like this automatically. But think twice about that, because it also ignores other mounted filesystems that you might want to include in your backup.

Regarding a restore of such a “whole system backup”, I wrote something about that some time ago here: Bare metal restore from restic repo: worked fine!

I second what has been said before, just backing up /var/lib/mysql for the bare database files can lead to corruption, because you can never tell for sure, if the database files are in a consistent state. Always do a mysqldump as well or even just only the dump. Also, for a bare metal restore you need some additional steps, which betatester77 has mentioned in his writeup.