Introduction
This article will go into further detail on retention options when creating a backup copy job to our cloud connect repo.
GFS
On creating your backup copy job you may have noticed "Keep certain full backups longer for archival purposes" This will utilise GFS (Grandfather-Father-Son) retention strategy. Once selecting this option you can define when to create full backups for archiving and how long to keep these. These can be kept for weeks (sons), months (Fathers) or years (Grandfathers) giving you several backup chains.
It is recommended you use GFS if you are using immutable backups. This way, if there was for instance a malicious attack involving reduction of retention policy then some incrementals run to clear the backed up data from the backup chain
This has advantages over the standard short term retention which can have a large number of incrementals which can increase recovery time. It will also increase resiliency as one corrupted incremental in short term retention policy can disrupt the whole chain and affect restorability. A schedule using GFS can be seen below
Short Term Retention
If GFS is not used the copy job will utilise the short-term retention policy. This allows restore points for a specified number of days to be kept. During the first copy session a full backup copy will be carried out. The next copy sessions will add incrementals to the chain. As a result this will produce a chain of a full backup and a set of incrementals in the target repository. When the retention policy is exceeded the earliest restore points from the chains will be removed from the repository.
You can either specify the number of restore points or specify the number of days when setting this retention method. The minimum number of retained restore points is 3 no matter the retention policy .i.e if the retention policy is 5 days but the backup has not run for ten days it will still keep the last 3 restore points.