Cheap VPS & Xen Server


Residential Proxy Network - Hourly & Monthly Packages

Automated Backups With rdiff-backup


This tutorial describes how to do automated server backups with the tool rdiff-backup. rdiff-backup lets you make backups over a network using SSH so that the data transfer is encrypted. The use of SSH makes rdiff-backup very secure because noone can read the data that is being transferred. rdiff-backup makes incremental backups, thus saving bandwidth.

Please find out more about rdiff-backup’s features here: http://www.nongnu.org/rdiff-backup/index.html

The problem is that SSH requires a password for logging in which is not good if you want to run rdiff-backup as a cron job. The need for a password requires human interaction which is not what we want. For example, to backup the directory /boot of server1.example.com, you would type rdiff-backup root@server1.example.com::/boot boot on your backup server (in this tutorial we name it backup.example.com) which would try to save server1.example.com’s directory /boot in backup.example.com’s directory boot. Now this is what happens:

rdiff-backup@backup:~$ rdiff-backup root@server1.example.com::/boot boot
Password:
—————————————————————–
Detected abilities for source (read only) file system:
Access control lists Off
Extended attributes Off
Mac OS X style resource forks Off
Mac OS X Finder information Off
—————————————————————–
Warning: ownership cannot be changed on filesystem at boot/rdiff-backup-data
—————————————————————–
Detected abilities for destination (read/write) file system:
Characters needing quoting ”
Ownership changing Off
Hard linking On
fsync() directories On
Directory inc permissions On
Access control lists Off
Extended attributes Off
Mac OS X style resource forks Off
Mac OS X Finder information Off
—————————————————————–
rdiff-backup@backup:~$

You see, in line 2 you are asked for the root password of server1.example.com.

But fortunately there is a solution: the use of public keys. We create a pair of keys (on our backup server backup.example.com), one of which is saved in a file on the remote system (server1.example.com). Afterwards we will not be prompted for a password anymore when we run rdiff-backup. This also includes cron jobs which is exactly what we want.

Oh, as you might have guessed already from what I have written so far, the concept is that we initiate the backups of server1.example.com directly from backup.example.com; server1.example.com does not have to do anything to get backed up.

This howto is meant as a practical guide; it does not cover the theoretical backgrounds. They are treated in a lot of other documents in the web.

This document comes without warranty of any kind! I want to say that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

Step 1: Install rdiff-backup On server1.example.com And backup.example.com

First we have to install rdiff-backup on both server1.example.com and backup.example.com. On Debian systems you can simply do that by running

apt-get install rdiff-backup

On other distributions the installation is different (on Fedora it might be something like yum install rdiff-backup, on Mandriva urpmi rdiff-backup, and on SuSE you should use yast to install rdiff-backup).

Step 2: Create The Keys On backup.example.com

On backup.example.com, we create a group and an unprivileged user called rdiff-backup. This user rdiff-backup will run the backups. We do not want root to run the backups for security reasons!

groupadd -g 3500 rdiff-backup
useradd -u 3500 -s /bin/false -d /backup -m -c “rdiff-backup” -g rdiff-backup rdiff-backup

The second command creates the user rdiff-backup with the home directory /backup (which is created automatically by this command if it does not exist already) who is not allowed to login on the shell (again for security reasons). If the group ID and user ID 3500 are already in use on your system, replace them by another (free) ID.

Then run

su -m rdiff-backup

With this command you become the user rdiff-backup on the shell. All the following commands must be run as user rdiff-backup!

Create the keys:

cd /backup
ssh-keygen -t rsa

You will see something like this:

rdiff-backup@backup:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/backup/.ssh/id_rsa):
Created directory ‘/backup/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /backup/.ssh/id_rsa.
Your public key has been saved in /backup/.ssh/id_rsa.pub.
The key fingerprint is:
88:18:4e:55:e9:27:8e:2a:44:4b:03:bd:9d:0f:fc:48 rdiff-backup@backup

It is ok to save the key in /backup/.ssh/id_rsa so you can simply hit enter. It is important that you do not enter a passphrase otherwise the backup will not work without human interaction so again hit enter. In the end two files are created: /backup/.ssh/id_rsa and /backup/.ssh/id_rsa.pub.

Next create the file /backup/.ssh/config with the following contents:

host server1_backup
hostname server1.example.com
user root
identityfile /backup/.ssh/id_rsa
compression yes
cipher blowfish
protocol 2

The value of host is what we use later on to start the backup. You can use any name the you like (e.g. server1_backup, this_is_the_machine_i_want_to_backup, etc.) (but it should not contain whitespace; underscores are ok).

Change the permissions of that file:

chmod -R go-rwx /backup/.ssh

Now we copy over our public key to server1.example.com:

ssh-copy-id -i ~/.ssh/id_rsa.pub root@server1.example.com

This will look like this:

rdiff-backup@backup:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub root@server1.example.com
23
The authenticity of host ‘server1.example.com (1.2.3.4)’ can’t be established.
RSA key fingerprint is c7:19:55:7a:54:ce:93:c8:b6:f9:0e:e3:65:24:64:11.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘server1.example.com’ (RSA) to the list of known hosts.
Password:
Now try logging into the machine, with “ssh ‘root@server1.example.com'”, and check in:

.ssh/authorized_keys

to make sure we haven’t added extra keys that you weren’t expecting.

rdiff-backup@backup:~$

Once again you have to type in the root password of server1.example.com. What this command does is it copies the public key of the user rdiff-backup to the file /root/.ssh/authorized_keys on the remote server server1.example.com.

Step 3: Edit The Public Key On server1.example.com

Log in as root on server1.example.com and have a look at /root/.ssh/authorized_keys. It should look similar to this:

ssh-rsa AAAAB3Nza[...]W1go9M= rdiff-backup@backup

Now prepend the following string to /root/.ssh/authorized_keys:

command=”rdiff-backup –server –restrict-read-only /”,from=”backup.example.com”,no-port-forwarding,no-X11-forwarding,no-pty

It must be in one line(!) with the key, only seperated by a space:

command=”rdiff-backup –server –restrict-read-only /”,from=”backup.example.com”,no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3Nza[…]W1go9M= rdiff-backup@backup

This will run the command rdiff-backup –server –restrict-read-only / when the user rdiff-backup fom backup.example.com connects to server1.example.com over SSH. –restrict-read-only / makes sure that rdiff-backup has only read access on server1.example.com. It depends on your rdiff-backup version if this works. If this does not work for you you can leave out –restrict-read-only / so that it reads

command=”rdiff-backup –server”,from=”backup.example.com”,no-port-forwarding,no-X11-forwarding,no-pty

In from=”backup.example.com” you should use the hostname that a reverse lookup of backup.example.com’s IP address returns. For example, if backup.example.com’s IP address is 1.2.3.4, and

dig -x 1.2.3.4

returns

rdiff-backup@backup:~$ dig -x 1.2.3.4

; <> DiG 9.2.4 <> -x 1.2.3.4
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38020
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;4.3.2.1.in-addr.arpa. IN PTR

;; ANSWER SECTION:
4.3.2.1.in-addr.arpa. 43200 IN PTR server3245.somehoster.com.

;; Query time: 118 msec
;; SERVER: 145.253.2.75#53(145.253.2.75)
;; WHEN: Thu Oct 13 14:56:03 2005
;; MSG SIZE rcvd: 83

rdiff-backup@backup:~$

then you should use server3245.somehoster.com:

command=”rdiff-backup –server –restrict-read-only /”,from=”server3245.somehoster.com”,no-port-forwarding,no-X11-forwarding,no-pty

You can as well use backup.example.com’s IP address:

command=”rdiff-backup –server –restrict-read-only /”,from=”1.2.3.4″,no-port-forwarding,no-X11-forwarding,no-pty

Next run

chmod -R go-rwx /root/.ssh

Then have a look at /etc/ssh/sshd_config. It should contain the lines

RSAAuthentication yes
PubkeyAuthentication yes

Restart ssh if you had to change /etc/ssh/sshd_config:

/etc/init.d/ssh restart

Step 4: Test rdiff-backup On backup.example.com

Back on backup.example.com, again as the user rdiff-backup, we test the backup:

cd /backup
rdiff-backup server1_backup::/boot boot

In the second command you see the string server1_backup. That is the string we used in /backup/.ssh/config after host. With this second command, the user rdiff-backup will connect to server1.example.com as the root user and save the directory /boot of server1.example.com to the directory /backup/boot on backup.example.com. If you see that it is working and you do not have to type in a password, then – congratulations! You did it!

Now all there is left to do is to create a cron job. Still as user rdiff-backup, run

crontab -e

and create a cron job like this:

40 2 * * * /usr/bin/rdiff-backup –exclude /tmp –exclude /mnt –exclude /proc –exclude /dev –exclude /cdrom –exclude /floppy server1_backup::/ /backup/server1

This runs the backup every night at 2.40h, saving the directory / with all subdirectories (excluding /tmp, /mnt, /proc, /dev, /cdrom, /floppy) of server1.example.com in /backup/server1 on backup.example.com.

(Note (a little off-topic): on Debian Sarge crontab -e will automatically open the editor nano. If you are used to working with the editor vi (like me), run the following commands:

rm -f /etc/alternatives/editor
ln -s /usr/bin/vi /etc/alternatives/editor

Afterwards, run crontab -e, and vi will come up.)
To find out more rdiff-backup commands (especially how to restore a backup), run

man rdiff-backup

and have a look at http://www.nongnu.org/rdiff-backup/examples.html.

Comments

comments