Our backup scripts use GNU tar's --listed-incremental (or -g) option. Each Sunday, we remove the “snar” files prior to invoking tar. Then we make 6 levels of incrementals for Monday through Saturday.
Our backup scripts also use --no-check-device (available in recent versions of GNU tar only) in order to avoid unintended effectively-full backup dumps after reboots of OpenVZ containers (which result in changed “device” number on simfs inodes). Yes, we backup the containers from the inside, each one individually.
The backup dumps are stored on separate “backup servers”, which initiate SSH connections to servers and containers to be backed up. We have command=… (forcing a proper tar invocation) and lots of no-* options specified in the authorized_keys files on the systems to be backed up. On a Sunday, all of the previous week's backup dumps are moved to another directory. It is important that we neither remove the previous week's dumps yet nor replace the previous Sunday's full backup dumps yet (doing so would invalidate the previous week's incremental dumps, making them nearly useless).
To restore from our incremental dumps, commands like the following may be used:
cd /target/directory/to/restore/to # make sure the above has succeeded (if put in a script, use ''set -e'' first or add ''|| exit'') tar xzpSf /path/to/backups/host/root.full.tar.gz --numeric-owner tar xzpSf /path/to/backups/host/root.mon.tar.gz --numeric-owner -g /dev/null tar xzpSf /path/to/backups/host/root.tue.tar.gz --numeric-owner -g /dev/null # ...and so on till the desired week day