This post is both an announcement of a new service called Package Backup, and a brief introduction to it.

Backing-Up a Modern Linux System

When it comes to backing-up a Linux system, backups are a piece of cake, as long as you follow a couple of standard rules. As a general rule of thumb, there are three main areas of concern for backups on a modern Linux system:

1. Packages installed via dpkg, pacman, etc..
2. Configuration in /etc
3. User home directories

I’m omitting the web-server directories (usually in /var/www), custom-built applications (usually a trivial concern), and the root home directory (which shouldn’t have anything substantial in it).

Theoretically, if you backup /etc, the home directories, and a list of the installed packages, you can recover immediately after a catastrophic event. This can be further simplified by moving your home directories to some central location on a RAID volume, on another system, and mounting it locally via NFS.

How do you restore all previously-installed applications? Using Debian/Ubuntu:

dpkg --set-selections < selections.txt
dselect update
apt-get dselect-upgrade

It’s even simpler on Arch:

pacman -S $(< selections.txt) 

It’s awesome, and the data is very light.

As for the practical aspects of backing-up a personal system, /etc will only occasionally change, so the occasional manual backup will be sufficient. For personal files, all of my code is stored in remote source-control, and all of my data is stored on a central server. So, my home directory is [arguably] disposable.

Usually, the only important thing to me is that, when my system crashes or I need to build another machine, I have a recent list of packages to install from, after I install the OS. This means that I’ll forego tons of frustration having to encounter and install missing applications and tools for the next month or two. For companies, this means that you can install the OS and get a system with identical applications/tools installed in minutes.

To get the package-list backups going, you’ll write a dump script, schedule it in Cron, and schedule a job to sync those lists to some central, safe backup location.

Though this is the ideal solution, these are the problems you might encounter:

• You’ll have to migrate scripts and schedule jobs on every machine you want backed-up.
• You’ll have to kill old package lists every couple of months.
• Since the need for these lists rarely come up, it’s fairly easy to forget they’re there, or to forget to configure the backup on new systems that you suddenly have to rebuild.
• When you want to retrieve a list, you’ll have to browse through the lists on the remote system, which may not be connectable just after you built a new system.

Package Backup

This is the purpose for Package Backup. It’s a centralize service that puts all of your package-lists in the same place, and hides them behind a nice little DatePicker calendar. You can monitor all of the systems that are pushing lists, can see the last time that they pushed, and can recover your lists by either downloading one from the webpage, or using the console tool to pull one. At its simplest, you can run a command like “pb_getlist_dpkg -” from the console, and the most recent list is printed to standard output. It plugs right in to the recovery commands, above.

An additional bonus of using this service is that you can see when a list has changed since the previous list that was pushed. You can also monitor the OS versions running on each of your systems.

Future Features

Package Backup will soon be adding SFTP functionality, for convenience. You’ll be able to use pbclient to automatically sync a set of physical files to a remote system. The functionality will be similar to scp, rsync, etc.., except that the same solution manages everything while still allowing you to specify paths, certificates, hostnames, etc..

For more information, see the Package Backup homepage.

System info:

Pushes for system: