1. ninjahelper
  2. manual ssh key generation & exchange
  3. real world usage

ninjahelper

You can now use ninjahelper to walk you through the process of creating backup action configuration files. In particular, for rdiff actions, backupninja will create the ssh keys and copy them to the backup server. Simply run "ninjahelper" and create an "rdiff" action. Here is a screen shot:

#img helper.png

manual ssh key generation & exchange

In order for rdiff-backup to sync files over ssh unattended, you must create ssh keys on the source server and copy the public key to the remote user's authorized keys file. For example:

root@srchost# ssh-keygen -t dsa
root@srchost# ssh-copy-id -i /root/.ssh/id_dsa.pub backup@desthost 

Now, you should be able to ssh from user 'root' on srchost to user 'backup' on desthost without specifying a password.

Note: when prompted for a password by ssh-keygen, just leave it blank by hitting return.

real world usage

Backupninja can be used to impliment whatever backup strategy you choose. It is intended, however, to be used like so:

  1. First, databases are safely copied or exported to /var/backups. Typically, you cannot make a file backup of a database while it is in use, hence the need to use special tools to make a safe copy or export into /var/backups.
  2. Then, vital parts of the file system, including /var/backups, are nightly pushed to a remote, off-site, hard disk (using rdiff-backup). The local user is root, but the remote user is not priviledged. Hopefully, the remote filesystem is encrypted.
There are many different backup strategies out there, including "pull style", magnetic tape, rsync + hard links, etc. We believe that the strategy outlined above is the way to go because: (1) hard disks are very cheap these days, (2) pull style backups are no good, because then the backup server must have root on the production server, and (3) rdiff-backup is more space efficient and featureful than using rsync + hard links.