This shows you the differences between two versions of the page.
internal:gnu-tar-incremental-backups [2010/09/30 16:52] solar corrected "v" to "z" in the options to "tar", although recent GNU tar would autodetect gzip'ed archives anyway |
internal:gnu-tar-incremental-backups [2015/10/12 00:15] (current) abc Fix formatting, because dokuwiki converts double dash into single long dash making gnu options wrong, thus, I quote these options with no-formatting %% tags. |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Incremental backups with GNU tar ====== | ====== Incremental backups with GNU tar ====== | ||
- | 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 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. | + | 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). | 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). |