[wplug-internet] Backup script

[Vance Kochenderfer]

Thanks for the feedback, Mike.  I am more concerned with getting
backups in place than in the specific method used.  However, I
did have reasons for why I selected my method rather than using
duplicity or another tool.  These are the advantages I see of the
script I wrote over those.  (Note that the "target" machine is the
one hosting the backup.)

1. It preserves hard links; duplicity does not.

2. It accounts for files (such as MySQL database files) that may
   be open and in an inconsistent state.  It briefly shuts down
   the services using those files to get a consistent snapshot,
   then restarts them for minimal downtime.

3. It uses tools that are part of the base distribution.  This is
   particularly important when restoring, as extra stuff may not
   be available (or may be a different version than was used to
   back up).  All you need to restore is a kernel with encrypted
   device mapper and ext2 filesystem support (both standard), and
   normal utilities like cp.  Duplicity appears to require
   duplicity to restore a backup.  The version available through
   RPMForge is somewhat old (0.4.11); I don't know if there are
   any compatibility problems between versions.

4. It doesn't store history, just a current snapshot, so the
   amount of disk space used on the target is relatively constant.
   Alternatives which store historical and incremental backups
   will continue to grow and consume more space over time.

5. Things are slightly simpler as viewed from the target machine.
   There is only a single image file.  Duplicity and other backup
   solutions generate multiple files - if the target owner wants
   to free up disk space, it's not clear which ones he can safely
   delete without ruining the backup's integrity.

6. It is easier on the target's bandwidth as well - when the
   script is run, it looks at all the configured targets, then
   chooses the one which is reachable over the network that has
   the oldest existing backup.  This effectively backs up to
   targets in a round-robin fashion rather than using them all
   every time the script runs.

There are certainly disadvantages to the script also.  But the
above concerns (particularly #2 and #3) I felt were important
enough to not just simply use an existing application.

It may be possible to combine elements from both approaches.

Vance Kochenderfer        |  "Get me out of these ropes and into a
vkochend at nyx.net          |   good belt of Scotch"    -Nick Danger