Deletion of old Backups

The more standard Approach

StoreBackup gives you a lot of possibilities to delete or not delete your old backups. If you have a backup which should never be deleted, the simplest way to achieve this is to rename it by appending a dash followed by your desired text string to the existing date_time filename. For example:

$ mv 2003.07.28_06.12.41 2003.07.28_06.12.41-archive

Renamed backups must match this naming pattern exactly:

IMPORTANT: If you use the option lateLinks of, only do this after a successful run of!
Renamed backups are not hard linked by new backups, so please do not rename them until they are not the newest ones any more.

To archive with a simple renaming is possible because and only delete directories which match exactly the pattern .

The most simple way to delete a specific directory is to use rm -rf. Do not do this if you use the option lateLinks of! If you want to delete backups which are too old depending on rules, there are several options you can choose. You can specify the time to keep old backups on the basis of weekdays (with a default value for all weekdays in keepAll which can be overwritten with keepWeekday). You can also specify to keep them with keepFirstOfYear, keepLastOfYear, keepFirstOfMonth and keepLastOfMonth, or with keepFirstOfWeek and keepLastOfWeek where you can define the first weekday of your definition of a week. In all of these cases, you have to specify a time period. How to specify a time period is described with the options of

Now imagine you are making your backups on an irregular basis, perhaps from a laptop to a server or you make your backups when you think you have finished an important step of your work. In such cases, it is useful to say ``only keep the last backup of a day in a long time range'' (with keepDuplicate). If you were in holidays for a month and have set keepAll to 30d (30 days), then you probably do not want that storeBackup deletes all of your old backups when you start it for the first time when you're back. You can avoid this with the option keepMinNumber. On the other hand, if you have limited space on your backup disk, you want to limit the total number of backups, for this, you can use keepMaxNumber.

With keepDuplicate you specify a time period in which storeBackup keeps duplicate backups of a day. After this time period only the last backup of a day will survive.

With keepMinNumber you specify the minimal number of backups storeBackup (or storeBackupDel) will not delete. The logic is as follows:

With keepMaxNumber you specify the maximal number of backups. StoreBackup will then delete the oldest backups if necessary. To prevent special backups from deletion, you can specify an ``archive flag'' with keepAll$*$ options. Backups matching an archive flag will never be deleted by keepMaxNumber. In this way it is possible that more backups will remain than specified with this parameter, but the archive flag is useful to prevent special backups like ``last backup of a month'' or ``last backup of a year'' to be deleted.

Using keepRelative as a Deletion Strategy

This option activates an alternative backup deletion scheme that allows you to specify the relative age of the backups you would like to have rather then the period over which a backup should be kept.

Imagine that you always want to have the following backups available:

Note that this is most likely not what you really want to have, because it simply means that you have to do daily backups and have to keep every backup for exactly 3 months. Otherwise you wouldn't always have a backup that is of exactly the requested age.

What you really want to have is therefore probably something like this:

This is now a very common backup strategy, but you would have difficulties to achieve this with the usual keepFirstOf* options, especially if you do not do backups with perfect regularity. However, you can implement it very easily using keepRelative. All you need to write is:

keepRelative = 1h 1d 7d 14d 31d 80d 100d

i.e. you list all the intervals for which you want to have backups. storeBackup will delete backups in such a way that you come as close as possible (if you do not do backups often enough, there is of course nothing that storeBackup can do) to your requested backup scheme.

Note that this may mean that storeBackup keeps more backups that you think it has to, i.e. it may keep two backups in the same period. In this case storeBackup ``looks into the future'' and determines that both backups will later be necessary in order to have a backup for all periods. This is also the reason why in the above example you have somehow implicitly specified the period 7 days to 14 days, although you didn't really want to have a backup in this period - in order to have backups in the next period (14 days to 31 days) you always need to have a backup in the period 7 days to 14 days as well. Therefore the syntax doesn't allow you to exclude some periods.

Finally you should be aware that storeBackup shifts all the intervals if it cannot find a recent enough backup: If your first interval is from 10 days to 20 days, but your most recent backup is actually 25 days old, all subsequent periods will be extended by 5 days. This ensures that if you haven't made any backups over a large period, this period is not taken into account for your backup scheme. To give an example why this is useful: If you wanted to have backups 1, 3, 7 and 10 days old and then went on vacation for 14 days, it is pretty unlikely that you want all your backups deleted when you come back, hence storeBackup ignores these 14 days and keeps the backups appropriately longer.

Heinz-Josef Claes 2014-04-20