mixed system backups

[Drake Diedrich]

On Fri, Jan 04, 2002 at 10:29:43AM +1100, Sam Couter wrote:
> 
> Using SSH keys has one *HUGE* advantage over RSH, and that is forced
> commands. You can dedicate a passphraseless key to doing backups, and on
> each machine you want to backup, you add they key to authorized_keys
> with a forced command of whatever starts sending backup data.

 
   If you don't know about this feature [ me :) ], but still want to limit
root compromises to single machines, create regular users and tiny setuid
root programs (executable only by the backup user) to do the root jobs:
taring up your filesystem for export for instance.  It's more work than
these forced commands appear to be.

   Alternatively, if you're willing to split the backup into multiple
scripts, run a cron job as root on each client, and rsh/ssh to the backup
server as a regular user to access the backup device or filesystem
(ownership will be lost unless you unpack as non-root, but that's probably
fine for a backup).

   If you're using a hard disk as an online backup you can also play with
setuid wrapper programs to avoid root trust issues.  This can be made to
work with vbackup-gather (the reader), and presumably with rsyncd (scaling
issues with hardlinks if you try to do a vbackup-like cp -H first). If
you're already exporting a filesystem network transport is unnecessary.

    Backing up an online backup to tape may be preferable to backing up the
live filesystem: can run the online backup at night unattended, and run the
tape backup during the day without interfering with daytime use or suffering
as many inconsistencies as you'd get from a live and changing filesystem.
Filesystem snapshots (when they become real) would also nearly solve this
issue, but in practice early morning backups tend to be almost as good for
most users - if you don't have many international users spread out over many
timezones.


-Drake