Requirements: Backups Blow depends on GNU tar, and the Log::Log4perl module.
It also depends on gzip by default but can use any tar compatible compression
program (such as bzip2) instead.  Of course it requires a working perl
installation too.

For FTP backups, it depends on ncftp.
For SSH backups, it depends on an openssh compatible ssh command.
For S3 backups, it depends on the Net::Amazon::S3 perl module and uses bfr if
    available to improve performance.
    Also, please see http://rt.cpan.org/Ticket/Display.html?id=34729, this can
    cause backupsblow to quit unexpectedly rather than retrying.  I posted a
    fix which I suggest you apply to your S3 if you are going to use this
    transport.

To get started, just copy the .cfg and .log4perl file to /etc/backupsblow, put
the .pl file somewhere where root can execute it, copy the BackupsBlow module
directory to somewhere in your perl search path (/usr/local/lib/site_perl for
instance), set the options in the configuration files and add a cronjob for
the backup.

If no log configuration file is specified, log4perl will be configured in
easy-debug style to print all log messages on STDERR.

I've included an example cron file that I use in my cron.daily, along with a
set of configuration files placed in /etc/backupsblow/.

SSH Transport only works if you have a no password key setup to allow ssh for
the username specified in the backup file.  At some point later, I might add
password based expect ssh transport, but then the ssh password would be just
as insecure as the ftp password any way.

Caveat: There is some reliance on expected output to stderr by GNU tar -- tar
normally writes "removing leading / from names" to stderr after doing its
preparatory work, but before it begins writing data to stdout.  I count on
this behavior in order to delay the opening of the ftp connection until there
is data to transfer.  I was having trouble with FTP timing out while tar
figured out its fileset.