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-agent-forwarding,no-port-forwarding,no-user-rc,\
  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@192.168.56.105::/etc /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@192.168.56.1::/etc /mnt/backup
rdiff-backup /etc/ rdiff@192.168.56.105::/mnt/backup

Rsnapshot only supports pull backups in its configuration file:

backup rsnap@192.168.56.1:/etc 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].

Conclusions

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.