I recently started to do regular backups of all my systems using BackupPC. It uses the rsync
protocol to limit the amount of data transferred during backups. Once the initial backup is done, future backups only need to copy incremental changes. This requires far fewer resources than other software I have used
This article covers setting up the server on Ubuntu and configuring backups for Ubuntu and OpenWRT. A future article will cover backing up Windows systems using an rsyncd
daemon process.
Setting up the BackupPC Server
BackupPC is available as an Ubuntu package. The software may be installed using whichever package manager you prefer. I used the command aptitude install backuppc
to install it. During the installation, it will configure a default account to access the web interface. Take note of the id and password. You can add more user ids later.
You will need a substantial amount of disk space to host the repository. However, due to file compression and de-duplication not as much as you might expect. Each additional copy of a file only requires an additional directory link. Adding more history requires small amounts of additional disk space.
You should use an extra disk for your repository. The file system needs to handle lots of files and directories. A file system with unlimited inodes would be ideal. I used an ext4
partition on a secondary disk in my server. Once it was formatted, I moved the contents of /var/lib/backuppc
to it. Then I configured the system to mount it as /var/lib/backuppc
. ❗ Never configure BackupPC to backup this directory.
Changing Defaults
The default configuration is located in /etc/backuppc/config.pl
. This is a well-documented configuration file, so you may edit it directly or use the web interface. ❗ If you configure a system named config
it will overwrite the default configuration.
Some of the changes you will likely want to make include:
- Setting the
ServerHost
. - Adjusting
MaxBackups
andMaxUserBackups
limits. - Configuring DHCP ranges. These are ranges used to find Windows Systems not found in DNS.
- Adjust or add to
BlackoutPeriods
. - Change the default
XferMethod
used to perform backups. - Change the default
ClientCharset
to match your most common character set. - Set the
SmbShareUserName
if you will be using Samba to backup Windows. - Set the
RsyncdUserName
if you will be usingrsyncd
for backups. - Add
--one-file-system
toRsyncArgs
if you prefer to backup file systems individually. - Change
NmbLookupFindHostCmd
if you wish to use WINS to locate hosts. - Set the
EMailUserDestDomain
to your domain. - Modify CGI access my modifying
CgiAdminUserGroup
,CgiAdminUsers
, andCgiURL
.
Reload the configuration once you are done configuring the server.
Adjusting DHCP Lease Times
If you have hosts using DHCP and have multiple DHCP domains, you may need to shorten the DHCP lease time. If hosts always have the same domain, this should not be an issue. However, if you have laptops that may connect using different domains you may want to shorten the lease time on the DHCP servers to a few hours. This will allow the systems to be be found using DNS (assuming they are registering in DNS). I use DNSMasq which automatically registers DHCP hosts.
If your DHCP clients are not registering in DNS, a scan of the DHCP ranges will be done to locate hosts. This may generate a significant number of probes. Using WINS will be faster, but if your hosts don’t get properly removed from the WINS database, you may encounter problems.
Configuring Clients
I chose to use sudo
and ssh
to allow access to clients. Each client has a backuppc user id created in the system range. This requires the following access to be added to the /etc/sudoers
file on each client. This is simpler if you are using Puppet or cfEngine to manage your configuration.
# Allow backuppc to run rsync as root backuppc ALL=NOPASSWD: /usr/bin/rsync
An ssh key is generated using the command sudo -u backupc ssh-keygen
. It is created without a passphrase, so it is configured to allow minimal access to the target systems.
Creating Userids on Clients
I generated the following script to create new user ids. You will need to set the SERVER
variable and paste your public key into the KEY
variable. If your server is multi-homed with different FQDNs depending on the interface you may need to change the SERVER
option for different hosts. You could also list all FQDNs for the server in the SERVER
variable.
#!/bin/bash #### Configure here SERVER=myserver.example.com KEY="Paste public key here" USERID=backuppc HOMEDIR=/var/lib/$USERID GECOS=BackupPC # Exit if already done if [ -d $HOMEDIR ]; then echo Aborting: $HOMEDIR already exists fi # Add a new user adduser --system --disabled-password --gecos "$GECOS" --group \ --home $HOMEDIR --shell /bin/sh $USERID # Setup ssh umask 077 sudo -u $USERID mkdir $HOMEDIR/.ssh sudo -u $USERID cat > $HOMEDIR/.ssh/authorized_keys <<EOF from="$SERVER",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty $KEY EOF # EOF
The script prevents the connection from getting a PTY, so interactive shells will not be available. You can test access to a host with a command like sudo -u backuppc ssh client.example.com echo OK
.
Adding Backup Clients
When adding new backup clients pick one host of each category to configure first. Once you have configured the first host successfully, you can use a copy format to duplicate the configuration across hosts. Each host must have a unique name that BackupPC can use to connect to it. If necessary, an IP address or FQDN can be specified as an alias.
Each host has its own configuration file which holds any configuration items required by the host. This includes a minimal set of data required to locate the host and any configuration items which have been overridden. For this reason, it helps to set up the default configuration so that hosts need minimal changes.
Hosts are added using the Edit Hosts menu item in the Server section of the Web Interface. Once you have configured a host you can select it in the search box in the Hosts section. The Host Backup Summary pages allow you to trigger backups and cancel a running backup. It also provides access to information on all current backups.
If you have another mechanism to recover a base system from bare metal, you may want to skip backing up your root directory. If you don’t backup up the root directory, you will want to backup /etc as shown in the configuration below.
$Conf{BackupFilesExclude} = { '/var' => [ '.Trash*', '/cache', '/lock', '/spool/exim4', '/run', '/tmp' ], '*' => [ '.cache', '.gvfs', '.thumbnails', '.Trash*', 'Cache', 'Dropbox' ] }; $Conf{ClientCharset} = 'utf-8'; $Conf{RsyncClientCmd} = '$sshPath -q -x $host sudo $rsyncPath $argList+'; $Conf{RsyncClientRestoreCmd} = '$sshPath -q -x $host sudo $rsyncPath $argList+'; $Conf{RsyncShareName} = [ '/etc', '/var', '/root', '/home']; $Conf{XferMethod} = 'rsync';
This configuration has a separate BackupFilesExclude
hash for the /var
share. The other shares will use the hash defined by '*'
. You may want to define additional exclude hashes for other shares.
The RsyncClientCmd
and RsyncClientRestoreCmd
configuration items are overridden to use sudo
. These items could be specified in the main common configuration file. The main configuration file could also include a standard value for RsyncShareName
. Because I have configured the defaults to backup Windows systems the configuration needs to define XferMethod
and ClientCharset
.
Verifying the configuration.
To verify the configuration trigger a full backup. The first full backup may take a long time to run. Once it is done, you can open up the Backup Summary for the backup and browse the directories and files backed up. Look for directories or files which should be excluded. If you find any directories which should be excluded add them to the appropriate BackupFilesExclude
hash.
You may also want to use find
to see which files are being excluded by the entries in the BackupFilesExclude
. If you are missing files that should be backed up, try adding them to a BackupFilesInclude
hash.
The backuppc log file will record files that caused problems during the backup. You should resolve any issues you find there.
Once you have your first full backups, further backups should run much quicker. Rerun the full backup until you are happy with the results. Once you have a good configuration, you can begin configuring other hosts. Review each host to verify you aren’t missing any host-specific directories.
Backing up OpenWRT
Before backing up OpenWRT you will need to install the rsync
package. You will also need to add the backuppc ssh key to /etc/dropbear/authorized_keys
. The dropbear ssh server does not support options in the authorized_keys file, so just append the raw key file.
All the added files are isolated in /overlay
. Unless you have additional storage mounted on a USB drive this should be all you need to backup. Files in /tmp will disappear on reboot, although some generated configuration files can be found there. The following configuration file is what I am using.
$Conf{ClientCharset} = 'utf-8'; $Conf{RsyncShareName} = [ '/overlay' ]; $Conf{XferMethod} = 'rsync';
Notes
This document assumes rsync has been configured to use the --one-file-system
option. You should seriously consider adding mount points to the BackupFilesExclude
hash if you don’t use this option.
If you wish to gather data for bare metal recovery, you should include the root directory in the RsyncShareName
hash. You can then exclude /etc
and /root
.
The listed excludes do not handle open database files which should be excluded. I generally configure my systems so that databases are dumped to files that will be included in the system’s backup. There may be other cases that require such special handling. There are configuration hooks that could be used to shut down the database and enable a cold backup to be taken.
BackupPC has very good documentation. The documentation is available directly from the Web Interface.
The backup server will have root access to all your systems. Take care to secure it. Take extra care with the ssh key for the backuppc userid. Using rsyncd will allow you to secure access more closely, but will require additional setup.
Great how-to thanks, just one little typo in the user generation script :
“adduser –geocos” should read “adduser –gecos”
Samuel.
Thanks Samuel I have updated the script in the article accordingly.
Bill