Ceci est une ancienne révision du document !
As anyone who has used a computer for any period of time will know - sometimes, things disappear. This can be from a power outage, careless deleting, or hardware failure. As such, backups are always necessary. There are a number of ways to go about this, so today I will outline my personal approach, and the thoughts behind it.
Distinctions
I segment my backups into three tiers - automatic, manual, and defaults. Automatic backups are pretty simple - I run Borg once a day at 5pm to create a snapshot of my system. You can compare it to Time Machine on OS X. The Borg backups are saved on my NAS (2 disks, in a RAID). The script for that can be found here: http://pastebin.com/nMbuRubx
Manual backups are ones I do by hand - typically for large files (such as Linux ISOs), and that I save on an external hard drive. I’m not typically too worried about redundancy for these files, as I can easily download them again. For some files that I want a bit of safety for, I copy it to multiple drives. They’re irregular, and, as such, not worth automating.
Lastly, the backups I call defaults. These are mostly dotfiles (configuration files) that I will re-use if I ever set up a new computer, or have to reset my computer for some reason. I save these in a git repository, saved to a private gitlab repository. The actual copying and committing happens through a shell script, which can be found here: http://pastebin.com/1HUAVGHh
Explanations
Borg
The script for Borg is pretty simple - I set up a few variables which will need to be updated. The script also has one optional switch “-p”, which shows the progress of the backup when run manually. The borg command itself is pretty self-explanatory (though less legible thanks to the variables). It essentially skips a few folders that I don’t want backed up, and backs up my home folder to the NAS, while compressing it. After the backup is complete, old backups are pruned down - daily backups for a week, 4 weekly backups, and 6 monthly backups. This helps to keep the space requirements down.
I focus mainly on the home folder, as those are the files I want safe. I hardly make any changes to the root filesystem, and the important configuration files I want to keep are covered in my defaults backup.
I’ve never had to restore anything from Borg, but using borg extract should allow you to extract all (or some) files from the backup. The Borg documentation is fairly thorough.
Manuals
I just use Thunar or a Terminal to copy files around. The thought process on why I do this by hand is outlined above. This also includes a text file in Dropbox listing some fixes I’ve implemented for some bugs my particular setup has dealt with.
Defaults
These are files like my configuration for i3, my git settings, and some system-wide files that I’ve changed. The script listed above contains an array of files and directories. The if statements then check if the file is in /etc/ or in my home folder. It then creates a version of the file path without the leading slash or the home path. This is then saved in my repository folder. If the file ends in a slash - i.e. is a directory - then creates the directory if it doesn’t exist in the repository, and copies the contents over. Otherwise it just copies the file. In the else statement, the -r switch is not really necessary for rsync, but I left it there just in case something slips through the if statement.
I also used rsync instead of cp, in order to be able to avoid .git folders (as they cause permission errors), and because rsync will copy a file only if there are changes.
The script also creates a list of packages installed. Since I run Arch Linux, the script uses pacman. For Ubuntu, replacing line 15 with pkglist=”apt list –installed > pkglist.txt” should work. You can then reinstall the packages with
cat ~/pkglist.txt > sudo dpkg –set-selections && sudo apt-get dselect upgrade
The very last command simply commits and pushes the changes to the git repository.
The reason for doing it this way is so I can easily recreate my setup - whether it’s on a new computer, or if I need to recover after extensive hardware failure. Since the files are pretty small, I pop them into a git repository to keep many versions of it, and then save it to gitlab, so I have access to it, even on other computers. I tend to run the command by hand after editing any of the files it contains. However, you can easily use cron to run it.
Conclusion
I’ve been using these solutions for a few years, and while I haven’t had any cases of having to restore from Borg, I have had a few external drives fail. And I’ve also set up a few new devices in that time. While there can be some hiccups, it’s been a pretty smooth process overall.
I hope this article is helpful to anyone who may be uncertain as to backup approaches. If you already have a setup, feel free to share it with me at lswest34+fcm@gmail.com. I also welcome any questions, or article suggestions.