Applies to: VisualSVN Server 3.6 and later
VisualSVN Server offers a retention policy for backups created by scheduled jobs, to set how long you want to keep these backups. Such a policy allows you not to accumulate too many backups, as time goes on and new scheduled backups get created on a regular basis.
A backup retention policy can be set individually for each Backup Repository Job. The policy has just one setting called the Retention period, which defines how long each backup made by this job should be kept. By default, it is set to 30 days, meaning that each backup created by the job is stored for at least 30 days. Once the job detects that a backup is older than the job’s retention period, the job considers this backup expired and automatically deletes it, except for the following 2 cases:
- A job that uses the Mixed full/incremental backup scheme will not delete an expired backup that is part of a backup chain, until the last incremental backup in this chain expires. See Ensuring the completeness of a backup chain below.
- Regardless of the job's backup scheme, a job will never delete the most recent backup it made (even if this backup has already expired). See Always preserving the most recent backup below.
A job detects and deletes its expired backups only when the job runs to create a new backup. See At which points in time expired backups are deleted below.
Ensuring the completeness of a backup chain
If you selected the Mixed full/incremental backup scheme in a Backup Repository Job, the job creates so-called chains of backup files.
A backup chain is a sequence of backup files, where the initial backup is a full backup of a repository, and then all the subsequent backups in this chain are incremental backups. This series is called a chain because each incremental backup records only the portion of the repository data that has changed since the previous backup in this chain, meaning that each incremental backup depends on the preceding backups in this chain. One chain continues until the end of this succession of dependent incremental backups. Then the next separate chain will start with a full backup again, and so on.
Since restoring from any incremental backup in a chain actually also requires the preceding part of this chain, starting from the full backup, a mixed full/incremental job will not delete any expired backups that are part of the chain until the last potential incremental backup in this chain expires. After this last incremental backup expires, the job is going to delete the entire chain at once.
Always preserving the most recent backup
Regardless of the job's backup scheme, a repository backup job will not delete the most recent backup it made, even if that most recent backup has already expired. This approach guarantees that you will always have at least one backup to restore from, if the job has made any backups at all.
For mixed full/incremental backup jobs, this means that even if an entire backup chain has expired, this chain will only be deleted if a newer chain exists. This newer chain needs to contain at least the initial full backup.
At which points in time expired backups are deleted
Each Backup Repository Job tracks and deletes only its own backups, i.e. those backups that were created by this particular scheduled backup job.
Once a backup expires, it gets deleted during one of the nearest subsequent runs of its corresponding job: either during the job run that occurs right on the backup's expiration date or during the first run of the job that comes after the backup's expiration date. This job run (that performs the deletion) can be either a normal scheduled run of the job or an on-demand run of the job (manually started by the administrator).
A job run will delete an expired backup only if:
- this current job run succeeds in creating a newer backup of the same repository;
- the expired backup does not fall under any of the two above-mentioned exceptions (i.e. is not part of an unexpired chain and is not the only remaining backup).