Backups using rdiff-backup and rsnapshot


Backups via SSH

Performing backups from a production system to a backup server over the network via SSH has the advantage of encrypted data communication. Based on the direction of backup, a distinction is made between:

  • Pull backups: the backup server backs up a remote server locally.
  • Push backups: the server transfers its data to the backup server.

The security measures referred to in the first section relate mainly to pull backups but won't be detrimental for push backups, either. An effective authorized_keys configuration limits the backup user's options:

# cat .ssh/authorized_keys
command="/usr/bin/python /usr/bin/rdiff-backup --server",\
  no-X11-forwarding,no-pty ssh-rsa AAAAB3NzaC1y[...]

Finding the right command for the command parameter can be difficult [3].

To back up system data as well, the backup user needs root privileges on the server to be backed up. A matching sudo configuration avoids the use of a genuine root account:

# vi /etc/sudoers.d/rdiff
rdiff ALL=(root)NOPASSWD:/usr/bin/rdiff-backup

The configuration allows the rdiff user to run the /usr/bin/rdiff-backup command with root privileges and without a password. However, rdiff cannot run any other commands with sudo. During the SSH backup, you then need to ensure that the backup command proper is preceded by sudo:

# rdiff-backup --remote-schema 'ssh -C %s sudo rdiff-backup --server' \
  rdiff@ /mnt/backup

Backups via SSH are part of the rdiff-backup standard repertoire. It supports both pull and push backups equally. The first line below shows the pull variant, and the second uses push mode:

rdiff-backup rdiff@ /mnt/backup
rdiff-backup /etc/ rdiff@

Rsnapshot only supports pull backups in its configuration file:

backup rsnap@ remoteA/

By default, it does not support push backups via SSH. In some situations, push backups are essential – for example, if the firewall rules only allow data to travel from the server to the backup server. In this case, you can use rsync and an intelligent configuration to create push backups with rsnapshot:

  1. On the backup server, an rsync daemon including a configuration is assigned to the server's public key; the authorized_keys file takes care of this.
  2. The rsync daemon's configuration on the backup server states the backup path. It uses post-xfer exec to call a script containing rsnapshot.
  3. To manage multiple servers, a configuration independent of /etc/rsnapshot.conf is created; it defines the backup schema.
  4. When the server wants to trigger a backup, it uses rsync and SSH to sync the data with the backup server.

In authorized_keys, the rsync daemon and its post-exec (step 2) are triggered, and a snapshot is created automatically.

The drawback with this solution turns out to be the detour via rsync. The basis, synchronized via rsync, acts as a source for rsnapshot. In addition to the snapshots, the backed up data also exists in another instance, which is not very efficient in terms of space usage. Solutions for this waste of space are currently being discussed in the rsync mailing list [4].


The Linux on-board tools rdiff-backup and rsnapshot both have their raisons d'être. Incremental backups in rdiff-backup have benefits and drawbacks. The good thing is their efficiency in terms of hard disk capacity, but the computational and time overheads are disadvantageous. If you have a large number of diffs (e.g., an older MySQL dump) a restore can take a considerable amount of time.

Rsnapshot impresses with its transparency: Each snapshot contains the files at the time of backup. Compared with rdiff-backup, however, it is unable to compute deltas; the next snapshot thus contains a complete version of a modified file. For a list of other benefits and drawbacks, refer to Table 3. At the end of the day, both programs do a reliable job of backing up data; which you decide to use is a matter of choice.

Table 3

Benefits and Drawbacks

rdiff-backup rsnapshot
Increments save stored data in a very efficient way Each snapshot is accessible as a legacy directory
Detailed logs and statistics data Hard link mechanism works simply and is fast
Increments cause more overhead Limited use for files that frequently change
No deleting of a single increment (cf. --remove-older-than) Push backups via SSH involve a detour

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Using rsync for Backups

    Although commercial Linux backup tools are available, many people prefer open source to better understand and control the backup process. One open source tool that can do both full and incremental backups is rsync.

  • Encrypted backup with Duplicity
    The free Duplicity backup program consistently encrypts all backups, which means that backups can even be stored in an insecure cloud.
  • Redo Backup
    Redo Backup backs up complete hard drives locally or over a network. The focus is on simple operation and high reliability in a variety of deployment scenarios.
  • How to back up in the cloud
    In cloud computing practice, backups are important in several ways: Customers want to secure their data, and vendors want to secure the essential details of their platforms. Rescue yourself, if you can.
  • Cloud protection with Windows Azure Backup
    Microsoft offers the Windows Azure Backup service, which lets you back up data from servers in the cloud. This removes the need for your own infrastructure, and the service alleviates privacy concerns by using continuous encryption.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=