Note:
You must specify the FULL path to a file that is to be restored. Only specifying 'motd' will not work, as GNU tar will not search for matching files in the archive when restoring specific files from an archive. You must specify '-s /etc/motd'.

1. 
   The secure way
   Use a keychains script. Excellent howto's can be found here:
   
   • www.gentoo.org/proj/en/keychain.xml
   • www-106.ibm.com/developerworks/library/l-keyc2
   • www.linux-mag.com/2002-08/potm_01.html

   The keychain is only broken when the remote machine reboots, but it removes the need for an empty passphrase.

2. 
   The not so secure way
   On localhost:
   Step 1.
   create a identity file:

   ---

   $ ssh-keygen

   ---

   Don't use a passphrase.

   Step 2.
   Copy the contents of the identity file: id_dsa.pub On remotehost:
   Put the contents of id_dsa.pub in the file ~user/.ssh/authorized_keys

   This 'user' is the user under which the archives should be ssh-ed. Thus with:

   ---

   $ hdup monthly localhost @user@remotehost

   ---

   will transfer the archive to remote host without asking for a password.

   Note: this is not a safe technique. If possible use technique 1.

from="IP ADDRESS",command="/usr/local/bin/hdup -c /etc/hdup.conf remote HOST",
no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa 
AAAAB3NzcC1y.....

If your key is now compromised they can only use it to run 'hdup'

dir = /home/miekg
include = *.txt, *.doc

This will backup everything under /home/miekg and it include all files ending in *.txt or *.doc. With the 'tar_patch' hdup will only create full dumps when using this option. Hdup will use 'find' to generate to file list to has to be backed up. Note that the backup is now a two staged process: first the files to backup have to get found, then the backup is run.

[localhost]
remote hdup = /usr/local/bin/hdup
remote hdup option = -c /usr/local/etc/hdup.conf

[localhost]
allow remote = yes

$ hdup monthly localhost @user@remotehost

The restoring can now be done via:

$ hdup restore localhost 2003-03-2003 /tmp/a @user@remotehost

Whatever the scheme is these scripts are always executed. It is best give the scheme to the scripts and let them decide what to do. I.e. 'prerun = script %s'. And shell script then looks like this:

#!/bin/sh
if [ "$1" == "restore" ]; then exit 1; fi
echo "rest of the script here"
   

If you have this problem upgrading to tar version 1.13.25 fixes this. [Confirmed by Petr Divina for Solaris]

The chunks of the split archive get the suffix: "__split__XX", where X is a letter. The first archive is gets the suffix: "__split__aa", the second "__split__ab", up to "__split__zz". So currently 26*26 = 676 chunks are supported.

mcrypt --list
...
rijndael-192 (32): cbc cfb ctr ecb ncfb nofb ofb 
saferplus (32): cbc cfb ctr ecb ncfb nofb ofb 
saferplus (32): cbc cfb ctr ecb ncfb nofb ofb 
wake (32): stream 
wake (32): stream 
blowfish-compat (56): cbc cfb ctr ecb ncfb nofb ofb 
...

cat > my_secret_key
this is a very secret key
^D

[myhost]
algoritm = rijndael-192

key = /path/to/my/key/my_secret_key

Note:
Be aware that encryption is a local operation. Encrypted remote archives are generated locally and then transmitted to the remote host. A restore works in the opposite manner: it is directly transmitted to the client machine which has to decrypt it while restoring. The rational behind this is that you don't want people on the remote machine to be able to look into your archive. A drawback is that you will have to store your secret key somewhere safe (ie. not on the machine that you are backing up - cause that has just crashed).

Or you could set 'no history = yes' in hdup's config file. This will use a single directory and a uniform archive name for all archives, archives will be called: static/hostname.monthly.static.tar.gz.
As such all new backups overwrite the old ones - saving space on your machine.

But be careful with this option! When a backup fails you don't have the old backup (that was being overwritten) nor the new one (that one failed) leaving you with no backup at all! Look in examples/ for a little postrun script (no-history-post-run.sh) that can be used to copy the archive to a safe place after a backup. Still only use this option when you know what you are doing.

hdup 2> bla

Update: As of version 1.6.14 the overview is sent to stdout again. All error messages are still sent to stderr.

cat hostname.monthly.* | tar tvfz -

/usr/local/sbin/hdup: www: STARTING BACKUP.
/usr/bin/tar: can't add file --files-from : No such file or directory
/usr/bin/tar: Removing leading / from absolute path names in the archive.
/usr/bin/tar: can't add file --listed-incremental : No such file or directory
/usr/bin/tar: can't add file /backup/www/etc/inclist.monthly : No such file or directory
/usr/bin/tar: can't add file --exclude-from : No such file or directory
/usr/bin/tar: can't add file --ignore-failed-read : No such file or directory

A listing of bugs in hdup can be found on: bugfixes

wget http://www.miek.nl/projects/hdup16/previous/hdup-1.6.XX.tar.gz
rpm -tb --clean hdup-1.6.XX.tar.gz
rpm -Uvh /usr/src/redhat/RPMS/i386/hdup-1.6.XX-1.i386.rpm

This still is no guerantee that it will not happen. If weekly starts before the monthly is finished cron should mail you a failed backup attempt.

The same applies when the weekly bites the daily.