Backup Central

Hi. I've been using rdiff-backup for a while now happily, but haven't
been reading the mailing list, so I apologize if I'm bringing up any
ground that's already been covered.

I was about to set up remote backup for another machine when I realized
that I have some different basic assumptions for the default usage
scenario from those used in the design of rdiff-backup. I'm hoping
someone can explain to me how to use rdiff-backup to fit my assumptions
better or to suggest that rdiff-backup might be changed to accommodate
them.

Assumptions:

1. The backup server is always available. The clients to be backed up
may not be.

I've followed the directions for unattended rdiff-backup [1] but I
notice they put the cron job on the server, instead of the client. This
doesn't work for me, because I have one reliable backup server and
multiple unreliable clients. At the time the cron job is running on the
server, the clients could be turned off, or rebooting, or otherwise
unavailable. I prefer to put the cron job on the clients, such as in
/etc/cron.daily, and to run anacron. That way I know they'll be backed
up daily regardless of when they're turned on or off.

2. I don't want the backup clients to be able to write anywhere
arbitrarily on the server.

Today the cron job on my client invokes rdiff-backup something like
this:

rdiff-backup /home/fred backupServer::/my/backup/directory

This makes me nervous, because the client could write over any directory
on the server. I could add the option "--restrict <path>", but that
would be left to the discretion of the client. I want assurance on the
server that no client can write outside of, e.g., /var/backups. Perhaps
what I want is to invoke rdiff-backup on the server directly, as
"rdiff-backup --server --restrict /var/backups", but the man page
contraindicates that:

--server
Enter server mode (not to be invoked directly, but
instead used by another rdiff-backup process on a
remote computer).

3. rdiff-backup is a backup solution, not a VPN solution. I've already
secured my communication channel, so I find ssh to be unnecessary
overhead.

All communication between my machines over insecure networks is already
done through VPNs, so SSH is just annoying overhead. In fact, I'd like
to configure my firewalls to allow some machines to be backup clients
without having access to SSH. It would therefore be helpful for the
rdiff-backup communication to use a specific port, so I can configure my
firewall to block port SSH while accepting the rdiff-backup port.
Perhaps what I should do here is run rdiff-backup over Netcat instead of
SSH? Would that work?

Fred

[1] http://arctic.org/%7Edean/rdiff-backup/unattended.html

I've followed the directions for unattended rdiff-backup [1] but I
notice they put the cron job on the server, instead of the client.

I have been using rdiff-backup for a well over a year with the cron jobs
on the client rather than the server. It isn't hard to do - I used the
principles outlined in the 'unattended rdiff-backup' document. If you
have problems implementing this then shout and I'll see if I can help.

2. I don't want the backup clients to be able to write anywhere
arbitrarily on the server.

In principle, my setup is that the cron job on the client runs as root,
but runs on the server under a non-priv'd account. It is therefore
relatively simple to restrict writes to the client's own directory tree.

3. rdiff-backup is a backup solution, not a VPN solution. I've
already secured my communication channel, so I find ssh to be
unnecessary overhead.

This I have not done (although, coincidentally, I have an ssh-related
problem which means I'd like to avoid ssh for one of my clients.
However, rdiff-backup does have the '--remote-schema' switch which
should pave the way to achieving what you want. I'd be interested to
know how you get on, though.

Keith

Keith Edmunds wrote:
This I have not done (although, coincidentally, I have an ssh-related
problem which means I'd like to avoid ssh for one of my clients.
However, rdiff-backup does have the '--remote-schema' switch which
should pave the way to achieving what you want. I'd be interested to
know how you get on, though.

on windows we use plink with the remote-schema .
it works pretty well - an example is in the archives.
I think you need an ssh transport at this stage - how else to do you
start rdiff-backup --server?

dave

Having thought about my assumptions some more, I realized that I'm
asking for the rsync usage model. It's possible to run an rsync server
directly (without ssh) on a specific port, and to limit access for the
clients.

On Wed, 2004-02-18 at 00:06, Keith Edmunds wrote:
I have been using rdiff-backup for a well over a year with the cron jobs
on the client rather than the server. It isn't hard to do - I used the
principles outlined in the 'unattended rdiff-backup' document. If you
have problems implementing this then shout and I'll see if I can help.

Thanks for the offer; I've got it working on the clients too. I'm just
not totally happy with the arrangement.

In principle, my setup is that the cron job on the client runs as root,
but runs on the server under a non-priv'd account. It is therefore
relatively simple to restrict writes to the client's own directory tree.

Yes, that's a good idea. I just figured out another way to do this,
which is to add --restrict to the .authorized_keys2 file in the
"unattended rdiff-backup" document:

primary# cat >>/root/.ssh/authorized_keys2 <<EOF
command="rdiff-backup --server --restrict /var/backups" ssh-rsa AAAAB3NzaC1yc2EAAAAB[...] root < at > mirror
EOF

This I have not done (although, coincidentally, I have an ssh-related
problem which means I'd like to avoid ssh for one of my clients.
However, rdiff-backup does have the '--remote-schema' switch which
should pave the way to achieving what you want. I'd be interested to
know how you get on, though.

I may no longer have time to work on this now but when I do I will let
you know what I come up with.

On Wed, 2004-02-18 at 02:27, David Kempe wrote:
on windows we use plink with the remote-schema .
it works pretty well - an example is in the archives.
I think you need an ssh transport at this stage - how else to do you
start rdiff-backup --server?

Perhaps with inetd?

Fred