I see a lot of tools and guides on how to create backups in Linux, but they often lack an explanation of the key principles behind the backup. In this post, I want to explore the basics, and demonstrate how and why Linux backups can be effectively employed.
About every 5 months I completely break my operating system. My experience with Linux is essentially this: I do some work, install new packages, configure them, and repeat the process until something essential breaks.
Upgrades to new OS versions are a notorious killer for my OSes. I’ve lost at least three Ubuntu installations to
apt dist-upgrade, and a Fedora installation to
dnf system-upgrade reboot.1 A better man knew the knobs to turn to rescue an OS installation after a failed system upgrade. I, unfortunately, do not. If debugging takes longer than 20 minutes, I delete everything on the machine and install the newest release of my favorite OS.
Since this approach results in the loss of all personal data, I need backups.
A nice thing about Linux is that all configuration takes place in plain text files.2 If you use Vim as a text editor, you’ll be familiar with
~/.vimrc, the Vim configuration file. All customizable software on Linux has at least one configuration file. But here’s the thing: To backup software, only the configuration file is required.
The size of the newest GVim release’s binaries including required libraries is about 17MB. The size of my
.vimrc is 16KB, meaning that in this case, the configuration file is roughly 1000 times smaller than the whole program. Still, I can copy my personal
.vimrc onto every machine that runs vim and work with my custom configuration within seconds.
For this reason, an essential paradigm I try to follow is to separate user data from system data: Until I feel the need to customise XServer, I’m happy enough that it works straight out of the box. And, since it works the way it’s shipped by my OS, I don’t need to include the XServer configuration files in my backup.
As a rule of thumb, I try to save all of my personal data and custom configs to
/home/. If at all possible, I try not to alter configuration files outside of
/home/. In case I end up doing so, I almost always work in
/etc/, thus adding
/etc/ to my backup doesn’t hurt.
Note that, depending on your Linux distribution, additional user data might be saved to weird locations. The last time I checked, Ubuntu was saving some user data to
/usr/local. You might want to add this to your backup, although I don’t on Fedora, and didn’t on Ubuntu in the past. Generally speaking, if you include
/home/ in your backup and separate user data as discussed above, you’ll likely cover everything important.
If you’ve never created a backup before in your life, now’s the time. Simply execute the following in your terminal: 3
cp -r /home/* /run/mount/external_drive/backup_001
There are a thousand sophisticated solutions for creating backups, and this one is by far the easiest. Just dump your
home/ directory onto an external hard drive. If you want to restore your system to the state of
backup_001/, start by reinstalling your OS, and then run
cp -rf /run/mount/external_drive/backup_001/* /home/
After that, use a package manager to install the software you use.
This is the essence of what creating backups on Linux comes down to. If you have a lot of disc space available and you store your backups locally, this method is perfectly feasible.
With that said, the approach presented in the previous section does have some downsides:
home/is saved, therefore configurations outside of
- Excluding and including additional directories from the backup is clumsy
- The backup is not compressed, thus takes up a lot of disc space
- The backup is not encrypted, meaning anyone that gets their hands on your backup can do bad things with it
I recommend BorgBackup to help solve all of the problems outlined above. There’s also Borgmatic, a wrapper built atop of BorgBackup that provides a neat interface to automate tasks carried out by BorgBackup. Borgmatic comes with a great setup guide, so start there if you want to set it up for your system.
The deadliness of system upgrades is usually increased by generously enabling third party software repositories.↩
I am aware that there are exceptions to the rule, for example a dynamic window manager that presumably sucks less, although I’m not convinced that requiring users to configure software by writing C code is broadly applicable.↩
Depending on the size of your↩
home/directory, this operation will take between several minutes and several hours.