NAME¶
expire_backups - Intelligently expire old backups
SYNOPSIS¶
expire_backups [options] <age> [<age> ...]
DESCRIPTION¶
The
expire_backups command intelligently remove old backups that are no
longer needed.
To define what backups you want to keep for how long, you define a number of
age ranges.
expire_backups ensures that you will have at least
one backup in each age range at all times. It will keep exactly as many
backups as are required for that and delete any backups that become redundant.
Age ranges are specified by giving a list of range boundaries in terms of backup
cycles. Every time you create a new backup, the existing backups age by one
cycle.
Example: when
expire_backups is called with the age range definition
1
3 7 14 31, it will guarantee that you always have the following backups
available:
- 1.
- A backup that is 0 to 1 cycles old (i.e, the most recent
backup)
- 2.
- A backup that is 1 to 3 cycles old
- 3.
- A backup that is 3 to 7 cycles old
- 4.
- A backup that is 7 to 14 cycles old
- 5.
- A backup that is 14 to 31 cycles old
- Note
- If you do backups in fixed intervals, then one cycle will
be equivalent to the backup interval. The advantage of specifying the age
ranges in terms of backup cycles rather than days or weeks is that it
allows you to gracefully handle irregular backup intervals. Imagine that
for some reason you do not turn on your computer for one month. Now all
your backups are at least a month old, and if you had specified the above
backup strategy in terms of absolute ages, they would all be deleted!
Specifying age ranges in terms of backup cycles avoids these sort of
problems.
expire_backups usage is simple. It requires backups to have names of the
forms
year-month-day_hour:minute:seconds (
YYYY-MM-DD_HH:mm:ss)
and works on all backups in the current directory. So for the above backup
strategy, the correct invocation would be:
expire_backups.py 1 3 7 14 31
When storing your backups on an S3QL file system, you probably want to specify
the
--use-s3qlrm option as well. This tells
expire_backups to
use the
s3qlrm command to delete directories.
expire_backups uses a "state file" to keep track which backups
are how many cycles old (since this cannot be inferred from the dates
contained in the directory names). The standard name for this state file is
.expire_backups.dat. If this file gets damaged or deleted,
expire_backups no longer knows the ages of the backups and refuses to
work. In this case you can use the
--reconstruct-state option to try to
reconstruct the state from the backup dates. However, the accuracy of this
reconstruction depends strongly on how rigorous you have been with making
backups (it is only completely correct if the time between subsequent backups
has always been exactly the same), so it's generally a good idea not to tamper
with the state file.
OPTIONS¶
The
expire_backups command accepts the following options:
- --quiet
- be really quiet
- --debug
- activate debugging output
- --version
- just print program version and exit
- --state <file>
- File to save state information in (default:
".expire_backups.dat")
- -n
- Dry run. Just show which backups would be deleted.
- --reconstruct-state
- Try to reconstruct a missing state file from backup
dates.
- --use-s3qlrm
- Use s3qlrm command to delete backups.
EXIT STATUS¶
expire_backups returns exit code 0 if the operation succeeded and 1 if
some error occured.
SEE ALSO¶
expire_backups is shipped as part of S3QL,
http://code.google.com/p/s3ql/.
COPYRIGHT¶
2008-2011, Nikolaus Rath
