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.
/usr/share/yunohost
/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?
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
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!!!
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.
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.
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.
