I use rsnapshot from a remote host to back up important directories on my linode. I've been happy with the results. (I'm not running Debian, but the behavior of rsnapshot should be the same regardless.)

–John

I back up my linode by running rsync over ssh to my home.

rsync -aSuvrx --delete -e ssh / ptomblin@xcski.com:/backup_1/linode/

Of course that means I need a private key file so that I can ssh without a password. Some people don't like that idea. If you're worried, make sure it's an account with very limited access (and chrooted).

I'm one of those people who don't like having a private key without a passphrase. :)

To get around this without too much trouble, on my local box (the one I'm backing up to) I have a perl wrapper that does the following:

1. Asks for the ssh key passphrase.

2. Use Schedule::Cron to set up a schedule to run rsnapshot and then detach so it's running in the background.

3. Each time Schedule::Cron runs the backup loop, it takes the saved passphrase, runs ssh-agent to get the right credentials for the backup user, runs rsnapshot, then kills the agent.

This solves the following concerns for me:

1. Remote machine (the one being backed up) still has a passphrase on the ssh key.

2. Local machine (the one being backed up to) doesn't have a passphrase sitting on disk somewhere.

3. The ssh-agent only has the credentials when needed.

Downsides are:

1. Need to manually restart the backup wrapper if the local machine goes down or is rebooted.

2. Passphrase is stored in memory somewhere all the time. This is only an issue if someone gets root access on my local box, and if that happens, I have bigger problems to worry about.

–John

The easiest way is to simply allow root ssh logons using public key

EDIT: I don't want to give root ssh access so this isn't the path I chose.

This article mentions one way to do remote backups using rsnapshot with a non-root user (with the help of sudo).

http://blog.innerewut.de/articles/2005/ … -rsnapshot">http://blog.innerewut.de/articles/2005/06/03/follow-up-on-remote-filesystem-snapshots-with-rsnapshot

After trying rsnapshot-1.2.1, I'm sold. It has a near-perfect balance of simplicity and features--most importantly, it passed my backup & restore tests which included doing an automated sql dump of a database. It only took a few minutes to setup because the config file and example scripts covered all the scenarios I needed. Being able to specify external scripts to run from inside the config file is really helpful in doing database dumps.

I recommend rsnapshot for scheduled backups and rdiff-backup for adhoc backups initiated at the command prompt. Both should be evaluated by anyone considering rsync-based backup solutions.

Here's a simple article about using rsnapshot on Debian:

http://www.debian-administration.org/articles/217

@sarge:

The easiest way is to simply allow root ssh logons using public key (which I don't prefer).

When I first read that I thought you were saying you prefer to use passwords instead of keys, but then I realized you meant you don't like to log in remotely as root.

Thanks for pointer to the sudo article, I think I'll add that to my existing setup - sshing as root (even with keys) always makes me feel uneasy.

–John

I use ssh-agent's SSHAUTHSOCK to solve the problem with empty passphrases. Ie. something like this:

1) on home system I create socket that can be used to get they keys. This session can be left open in any "screen" session:

ssh-agent -a /tmp/ssh-agent.socket bash

ssh-add

Enter passphrase for /root/.ssh/id_rsa:

Identity added: /root/.ssh/idrsa (/root/.ssh/idrsa)

ssh-add -l

1024 35:0e:ff:ff:8a:71:dc:2f:c2:b6:5e:e8:5c:f2:a8:9e /root/.ssh/id_rsa (RSA)

Then, from any other shell you can do this:

export SSHAUTHSOCK=/tmp/ssh-agent.socket

ssh linode date

This way you need to add your public key to linode but it's not empty passphrase. And you don't need to import keys more than once and all your cronjobs can be hitting it.

Cheers,

Risto

Another thing you could do, assuming that your sshd is configured to only accept public-key authentication, is to allow root logins, but restrict the authorized key to running a specific command (such as a wrapper script with sanity checking for its parameters).

Something like this could go in root's .ssh/authorized_keys file:

command="/your/wrapper/script/here" ssh-dss (EDITED-OUT-KEY) your-key-identifier

In your script, you can check the SSHORIGINALCOMMAND environment variable for something acceptable, and exec the contents of that variable if it's OK.

linky goodness

You can also limit the key to specific hosts/IPs, too, by using the 'from=' parameter.

(See sshd man page for more information, under the 'AUTHORIZED KEYS FILE FORMAT' section)

@sarge:

If I didn't want to stick with Debian's stable branch, then arnie 1.10, rdiff-backup 1.0.2, and rlbackup 2.20 would be on my evaluation list too. And of these, I really like rdiff-backup and am looking forward to trying it once Debian Etch is released in 2006-2007.

I'm running rdiff-backup 0.13.4 on debian stable.

Paul

Normally involves any number of the follow apps:

rsync (1) - faster, flexible replacement for rcp

svn (1) - Subversion command line client tool

cpio (1) - copy files to and from archives

gpg (1) - encryption and signing tool

par2 (1) - PAR 2.0 compatible file verification and repair tool.

I use cpio over tar because one can use -H crc and pick up on which files are corrupted, something tar doesn't do.