Setting Up BackupPC on Ubuntu

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/ 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 and MaxUserBackups 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 using rsyncd for backups.
  • Add --one-file-system to RsyncArgs 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, and CgiURL.

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.


#### Configure here
KEY="Paste public key here"


# Exit if already done
if [ -d $HOMEDIR ]; then
   echo Aborting: $HOMEDIR already exists

# 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


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 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';


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.


  1. Great how-to thanks, just one little typo in the user generation script :
    “adduser –geocos” should read “adduser –gecos”


Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Cookie Consent with Real Cookie Banner