[rdiff-backup-users] my usage model assumptions

[Fred]

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