I'm switching away from hdup2 because of directory attributes getting lost upon restore (this hdup2 bug can only be fixed by patching tar which I'm unwilling to do).

I'd like to run pure Debian stable--no apt-pinning to grab stuff from testing or unstable--if at all possible.

I've come across these, which have their latest stable version in Debian's stable branch:

1. Dirvish - recently selected by OSL at Oregon State University to backup their servers (which covers Mozilla, kernel.org, Gentoo, Drupal and other major projects...). Dirvish uses a file format similar to rlbackup, which is the backup tool used by phy.bnl.gov

2. rsnapshot - looks promising but maintainer started looking for someone else to take over the project a week ago. EDIT: A new maintainer took over the project in Nov 2005 with help and support from the original maintainer. It passed my backup/restore testing with flying colors so I chose this one for now.

3. dar - well, the very latest version isn't in Debian stable but version 2.2.1 is close enough.

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.

Have you used any of these? Any recommendations?

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

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

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 SSH_AUTH_SOCK 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/id_rsa (/root/.ssh/id_rsa)
# 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 SSH_AUTH_SOCK=/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 SSH_ORIGINAL_COMMAND environment variable for something acceptable, and exec the contents of that variable if it's OK.

_________________
Bus error (passengers dumped)

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)

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.