Backup Server

ssh root@gudang
The authenticity of host 'gudang (192.168.178.28)' can't be established.
RSA key fingerprint is 92:f1:cf:b7:26:af:ab:2a:fe:c1:5d:c6:77:ae:93:44.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gudang' (RSA) to the list of known hosts.
root@gudang's password: 

Welcome to ReadyNASOS 6.1.8

Install rdiff-backup

apt-get install rdiff-backup

The general model I use is to initiate all rdiff-backups from a central backup server, and pull the data from the hosts to be backed up. The central backup server uses a non-root user to perform the backups — this relies on metadata features of recent rdiff-backup in order to support proper restores, and has the benefit that rdiff-backup exploits/bugs have reduced potential to damage the backup server. The backup still requires root on the host being backed up, but it is protected by ssh mechanisms which restrict the invoked command, and rdiff-backup mechanisms which restrict it to read-only access.

For convenience I’ll call the backup server gudang and the host to be backed up yogya.
On the backup server gudang, create a new account which will be used to perform the backup. I’ll use the account name backup. The shell can typically be set to /bin/false. In my case the home directory is set to /backup which is where I’ve mounted the filesystem containing all my backups. The account password should be disabled. For example you might have the following entries in your passwd/shadow files:

/etc/passwd
backup:x:34:34:backup:/backup:/bin/false
/etc/shadow
backup:*:12644:0:99999:7:::

Your uid/gid may differ, as may many of the fields in shadow.

Note that if you’re backing up multiple hosts, for an extra layer of paranoia you could create an account per host.

Command to delete user password under Linux

Type the following command to delete a user password

root@gudang:/etc# passwd --delete yogya
passwd: password expiry information changed.
root@gudang:/etc# su -m yogya
Creating directory '/home/yogya'.
bash: /root/.bashrc: Permission denied

Generate public/private rsa key pair

yogya@gudang:/etc$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/yogya/.ssh/id_rsa): /home/yogya/.ssh/id_rsa_rdiff
Created directory '/home/yogya/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/yogya/.ssh/id_rsa_rdiff.
Your public key has been saved in /home/yogya/.ssh/id_rsa_rdiff.pub.

Create an ssh config alias which defines how to contact yogya with the backup key.

vi /home/yogya/.ssh/config:

host yogya-backup
  hostname yogya
  user root
  identityfile /home/yogya/.ssh/id_rsa_rdiff
#  compression yes
  protocol 2
  

Note that “compression yes” is optional, and you may wish to omit it if gudang and yogya are connected over high-speed nets. The cipher line is also optional, but may reduce cpu overhead. (On a trusted switched network, or over localhost, you may also wish to patch OpenSSH to enable cipher none.)

This config entry enables backup@gudang to use the “hostname” yogya-backup wherever ssh expects a real hostname. ssh will use the information specified in the config file, which will result in a connection to yogya, using the specified key, compression, cipher, and protocol.

You may need to make some file permission adjustments, it depends on your system:

yogya@gudang:/home/yogya$ chmod -R go-rwx /home/yogya/.ssh

Give permission for backup to access yogya and run rdiff-backup.
Assuming that root@yogya’s home directory is /root, we will construct a terribly long line in the file /root/.ssh/authorized_keys (on yogya). The line is so long that I’m going to break it in two here for demonstration purposes only, you must join this first line and the public key from above on one line, with only a space between them:

yogya@gudang:/home/yogya$ scp /home/yogya/.ssh/id_rsa_rdiff.pub root@yogya:


[root@yogya .ssh]# cat ../id_rsa_rdiff.pub >> authorized_keys
[root@yogya .ssh]# vi authorized_keys
command="rdiff-backup --server --restrict-read-only /",from="gudang",no-port-forwarding,no-X11-forwarding,no-pty
ssh-rsa AAAAB3NzaC1yc2E[......] yogya@gudang

Ensure file permissions are set properly:

[root@yogya ~]#  chmod -R go-rwx /root/.ssh

This entry in /root/.ssh/authorized_keys permits anyone with the specified key (i.e. backup@gudang) to connect with ssh from the host named gudang and issue the forced rdiff-backup command. It further restricts the ssh connection to eliminate port forwarding, X11 forwarding and a pty. The rdiff-backup invocation is also restricted to read-only operations starting from the root of the file system.

Install rdiff-backup on yogya

[root@yogya .ssh]# yum -y install rdiff-backup
..  

NOTE: rdiff-backup 0.13.4 fails to support “–restrict-read-only /” without a patch. It works fine with sub-paths (i.e. /home), but you’ll need my patch to backup from the root of the filesystem. If you’d prefer not to patch rdiff-backup then you can skip the “–restrict-read-only /” parameters — it is up to you how paranoid you wish to be.

If you have any troubles, this step is the one which has most likely caused you problems. Here are some troubleshooting guidelines:

– Make sure there are no line breaks in the authorized_keys entry.
– Use the reverse DNS response for gudang’s IP address in from=”gudang”.
– Make sure you copied the public key properly.
– Make sure rdiff-backup is in root’s PATH, or add a full path to command=”/path/to/rdiff-backup…”.

Perform a test backup and populate known_hosts.

You should now be able to perform a test backup. During this test ssh will probably ask you to accept the yogya host key — you will need to complete this step before you can begin an unattended backup.

yogya@gudang:/home/yogya$ rdiff-backup yogya-backup::/home/pdeneef/cma test-backup

If you are asked for a password or passphrase then something is wrong. Other than asking you to verify the host key it should succeed in performing a backup of yogya::/tmp in test-backup.

Assuming the first attempt asked you to verify the host key, run the test a second time to verify that it asks you nothing.

$ rdiff-backup -v8 yogya-rdiff::/mnt/data/backup/mysqldumps/ /data/backup-yogya/mysqldumps

Create a cron job on gudang to initiate your backup (i.e. crontab -e -u backup):

# su -m yogya
$ crontab -e

10 4 * * * rdiff-backup --force --remove-older-than 4W /data/backup-welgg/mysqldumps >/dev/null  2>&1
50 * * * * rdiff-backup welgg-rdiff::/home/data/backup/mysqldumps /data/backup-welgg/mysqldumps >/dev/null 2>&1