Retention explained

Retention in Underscore Backup is very flexible but can be somewhat tricky to understand. For each backup set, you can specify different retention. There is also a global setting for retention that is used for all files that are not contained in any current set. A file can end up existing in your backup but not being in a set after you change your definition of a set.

Retention is defined in four parts. First, is the default initial retention which is defined as the maximum number of versions of a file during any given time period. For instance, you could have your default retention be set to 15 minutes which means that even if a file is being changed every 5 minutes the backup would only contain one copy per 15 minutes. You can then progressively move to less and less frequent copies as the version grows older. There is also a setting to indicate how long files should be kept around after they have been deleted. Finally, there is a catch-all setting for how many versions at most to keep of a file.

To explain let's look at this example.

 

In this example, the application would keep one version of the file at most every 15 minutes. Once a version is older than 1 month only a single version per day is kept and all the other potential versions will be discarded. After a version becomes 6 months another culling will take place and only a single copy per month will be retained. Finally, the file will be kept for up to 1 month after it has been deleted from your system.

There is no maximum number of versions kept, if this was enabled at 10 it would be applied on top of the previous options so there would never be more than 10 versions of any single file.

Retention in combination with continuous backups

Continuous backups complicate retention settings because if you have a file that changes very often it would be very inefficient to replace the most recent version of a file every time it changes. To solve this when the continuous backup is enabled the system will only save a new file once during a retention period.

As an example, let's say that we have a file that updates once every minute for 20 minutes while the retention for the file is to keep a version every 15 minutes. What would happen then is that the first version would be saved immediately after the first change. After this, the next version will not be stored until after 15 minutes. The system will then keep track of that the file has changed more after this for another 5 minutes until the changes stop, but the latest version of the file will not be saved until 30 minutes after the beginning of this cycle (15 minutes after the last change).

How retention is applied

Retention is applied at the end of the completion of each set. If a backup is interrupted while still in progress to for instance do a restore this operation could see slightly more versions than what retention specifies since files have been stored, but any potential culling by adding them has not yet happened. If you are looking at the UI while a backup runs you will see a status of Trimming while the retention is happening.