This is a "copy & paste" HowTo! The easiest way to follow this tutorial is to use a command line client/SSH client (like PuTTY for Windows) and simply copy and paste the commands (except where you have to provide own information like IP addresses, hostnames, passwords,...). This helps to avoid typos.

Automated Backups With rdiff-backup

Version 1.0
Author: Falko Timme
Last edited 10/13/2005

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:

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, you would type rdiff-backup boot on your backup server (in this tutorial we name it which would try to save's directory /boot in's directory boot. Now this is what happens:

rdiff-backup@backup:~$ rdiff-backup 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

But fortunately there is a solution: the use of public keys. We create a pair of keys (on our backup server, one of which is saved in a file on the remote system ( 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 directly from; 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 And

First we have to install rdiff-backup on both and 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

On, 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/
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/

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

host server1_backup
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

ssh-copy-id -i ~/.ssh/

This will look like this:

rdiff-backup@backup:~$ ssh-copy-id -i ~/.ssh/
The authenticity of host ' (' 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 '' (RSA) to the list of known hosts.
Now try logging into the machine, with "ssh ''", and check in:


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


Once again you have to type in the root password of 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

Share this page:

12 Comment(s)

Add comment


From: Anonymous at: 2005-11-30 16:16:17

hi guys

when i try to run this command

ssh-copy-id -i ~/.ssh/

i am getting following error

main1:/backup$ ssh-copy-id -i .ssh/
ssh: Name or service not known

can some one help me with this

From: Anonymous at: 2006-02-20 17:52:50

Things like are simply examples. You have to use your own server names.

From: at: 2007-07-20 17:41:49

Try (for example):

ssh-copy-id -i .ssh/

From: at: 2007-01-18 03:47:43

I have lots of data that will be backed up across servers and I don't want this affecting the performance of my websites and stuff I have happening specifically on other nic devices so is it possible to specify which nic I want to do the backups on?

 It would be nice to add a brief description on how to do this in your article.

From: at: 2008-01-21 23:26:03

If you're going to do Linux backups and you want them to be trustworthy, you should really read the following article on reliable Linux backups: How to backup Linux, BSD and other Unix-like systems properly

In this article, the author (a good buddy of mine) describes in great length the does and don't of backing up Unix-like systems. He also goes into great detail about the advantages and disadvantages of various backups methods, so that you will be able to estimate whether you're beter of with rdiff-backup/rsync or something like Dar.

Read it. It will almost inevitably make you consider something you've never considered before. It did me. 

From: Anonymous at: 2009-06-06 19:43:32

Re Step1

Do you really need to install rdiff-backup on both machines?

Why not just the backupserver?

From: Huzoor Bux at: 2012-01-11 06:37:46

I have 4 servers and i need to make backup of all these servers on my backup server please suggest me that is this possible or not if possible then how can i manage   /backup/.ssh/config  file.

 Thanks in Advance.. :)

From: Anonymous at: 2006-07-21 13:24:00

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

 this broke my crontab

 fixed with:  export EDITOR=vi && crontab -e

From: at: 2008-02-18 13:55:24

I'm working on a start script which can be run in the crontab fields for rdiff-backup. It will initiate the backup and send an email with result to a pre-defined person.

I would also suggest that anyone who run rdiff-backup also add --exclude /sys to their crontabs/rdiff-backup commands as sysfs is often mounted on /sys and has no point to be backed-up. Takes a lot of extra time to process files which are changed during runtime.

There are more of these directories and files which you can block out to improve performance. But it's the same reason why you dont backup /proc for all of them. 

From: Anonymous at: 2006-08-22 16:38:12

ssh-keygen -t rsa
# hit return three times

ssh-copy-id -i ~/.ssh/ username@remote_host
# enter your password for username on remote_host

cat > /etc/cron.daily/remote_backup
rsync -e 'ssh -p 22' -avzp /some/dir remote_host:/var/backups/some_host

chmod +x /etc/cron.daily/remote_backup

ssh username@remote_host mkdir /var/backups/some_host

From: Kim N. Lesmer at: 2008-10-30 00:21:34

When you use rdiff-backup to backup from a local machine to a remote host, rdiff-backup has to be installed on both systems, and it has to be the same version or at least no major changes most appear between the versions.

From: at: 2010-12-28 11:54:00

If your has sshd on different port than 22 eg. 1234 than You have to make additional changes on server

Add extra line to /backup/.ssh/config: port 1234

You shoul also use ssh-copy-id -p 1234 -i ~/.ssh/ instead of ssh-copy-id -i ~/.ssh/

 Sometimes obove doesnt work, so You have to edit by root file ssh-copy-id (located /usr/bin/ssh-copy-id) around line 41:

 { eval "$GET_ID" ; } | ssh -p 1234 $1 "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys" || exit 1