RSnapshot provides a fairly convenient front end to managing multiple backups of a given system, in a minimal amount of space, by utilisating features of rsync (wikipedia). It can back up a system in any way that rsync supports, and when run regularly automate the process of keeping multiple daily/weekly/monthly backups (or any other frequency you choose) which store any unchanged files as hard links to the original copy.
Within a LAN one common way to configure it is to use rsync's daemon mode (which listens on TCP/873), with simple IP address authentication possibly combined with username/password authentication. A simple rsync configuration file will look something like:
[rsnapshot] path = / read only = true uid = root gid = root hosts allow = A.B.C.D hosts deny = 0.0.0.0/0
where A.B.C.D is the IP address of the backup server which is allowed to connect. Password configuration can be set up by creating a simple password file:
USERNAME:PASSWORD
where USERNAME is the username that must be passed on the rsync
command line, and PASSWORD must be passed either on the command line
or entered, or specified via --password-file
(the latter is
the recommended approach). The additional configuration snippets are:
auto users = USERNAME
secrets file = /PATH/TO/FILE/ABOVE
plus ensuring that the file is readable only by root.
When running rsync over more than the local LAN, it becomes desirable to
avoid sending password and file contents in plain text over the network.
The obvious solution at this point is to use ssh for authentication and
encryption. rsync does support ssh directly, but when run in this mode
it expects to be able to launch an arbitrary command starting
rsync --server
on the remote end. Authenticating the ssh
access, without user intervention, requires creating an ssh key --
without any authentication credentials on the ssh key.
Unfortunately having ssh keys without passphrases on them is a security risk, especially when (as is the case when doing backups with rsnapshot) they need to log in as root. ssh can be told to only run a specific command when a given key is used, which is fairly effective at restricting access when the command is fixed, but not very useful when the command needs to vary. Some people have tried to solve this by using a shell script to filter the rsync command, but these are mostly blacklists of characters that might be a problem.
The best solution seems to be to combine the rsync daemon mode with a ssh connection, as described in the rysnc manual ("USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION"). That way the remote command that is run is a fixed "rsync --daemon" command, and the variable arguments are passed through the rsync protocol.
To do this, create an /etc/rsnapshot-backup.conf
containing:
[rsnapshot] path = / read only = true uid = root gid = root hosts allow = A.B.C.D hosts deny = 0.0.0.0/0
And a /root/.ssh/authorized_keys
containing:
from="A.B.C.D",no-pty,no-X11-forwarding,no-port-forwarding,no-agent-forwarding,no-user-rc,command="/usr/bin/rsync --config=/etc/rsnapshot-backup.conf --server --daemon ." ssh-rsa AAAAB3Nza....
(all on one big long line)
Then ensure that rsync is called with:
rsync ... -e '/usr/bin/ssh -i /PATH/TO/KEY' ... server::rsnapshot/ ./
where the explicit -e
(or --rsh
) is
required to trigger this mode.
When using rsnapshot, it's necessary to hard code this on the rsync commnad line as when you specify a "::" in the backup source, rsync assumes that the normal rsync daemon is being used, and omits all the ssh arguments. Viz:
rsync_long_args --delete --numeric-ids --relative --delete-excluded -e '/usr/bin/ssh -i /PATH/TO/KEY -p 22'
As a result this key is accepted only to run rsync in daemon mode, and what can be done is controlled by rsync and the configuration file. (With rsnapshot to back up the entire system the best that you can limit it to is read-only access to the whole system -- but at least that avoids allowing the user run arbitrary commands on the system, or writing files onto the system.)
This could be combined with rsync daemon user/password authentiation too, with the authentication going through the ssh connection (and thus encrypted over the network).
(Another option is to use ssh keychain to semi-permanently remember the key in memory, even after you log out, and make it available to daemon processes like rsnapshot. While this allows ensuring that the ssh key on disk is secure (with only the "insecure" copy being held in memory) it's not clear to me that it's all that much more secure in practice if the key stays in memory for extended periods of time and can be used for arbitrary things. I've also seen this deployed in a mode where (root) logins were booby-trapped that threw the keys out of memory and required the passphrase to add them back in again -- but that mostly seemed to inconvenience regular users, and lead to missed backups, without actually improving security.)
ETA, 2012-09-21: It turns out that, at least with older versions of
rsnapshot, the rsync_long_args
cannot contain a multi-part
(single quoted) string and have those quotes be preserved through all the
calling layers of shells. To make it work properly you need to create
a tiny shell script with all the right ssh arguments, and either use
-e SHELLSCRIPT
or make that your ssh command. Ie, embedding
all the specialisations into the ssh wrapper.