This article discusses the backup retention policy and its different scenarios.

A Backup Retention Policy determines the retention time of data, archival rules, data formats and the permissible means of storage, access and encryption, while weighing legal and privacy concerns against economics and 'need to know' concerns.

Administrator can store/save ‘n’ number of daily, weekly or monthly restore points for each user.

Druva inSync uses the GFS (Grandfather–Father–Son) retention method for maintaining hierarchical restore points. GFS method describes a rotation scheme whereby a daily backup (the son), a weekly backup (the father) and a monthly backup (the grandfather) are created to maintain a hierarchical backup strategy.

Each week, one full daily backup (latest from that week) is promoted from a son to a father and is deemed the weekly backup. Each month, a father (latest from that month) is promoted to a grandfather and is deemed the monthly backup. For the GFS policy to work we will need a successful sync every day.

In order to put more light on this, let’s consider the following scenarios.

For the above scenario, say User A’s device has been backed up successfully for 8 consecutive days, here total number of restore points created will be 8. On the 9th day the 1st days restore point will get deleted. This is irrespective whether syncs are completed within the span of those 8 days. This means that even if the user’s device isn’t synced for a day or two, these days would be taken into consideration before deletion of a restore point.

However, the next segments (weeks & months) take care of such ‘Missed Sync’ cases.

Moving to weeks, the last successful sync which took place in a week’s duration (Latest restore point of that week) will be made available for restore. For 5 weeks (As defined under policy above), one restore point per week (latest) will be created (i.e. total of 5 restore points will be available).

The above also implies for months, wherein the last successful sync within a month’s period will get stored. Here a total of 2 restore points will be generated (for 2 months).

This kind of restore policy structure helps in maintaining granulated restore points.

Also for any configuration of the restore points, the last successful restore point is always available and it cannot be deleted. Older restore points will be removed as per retention policy defined however, for each user one most recent restore point will be retained and will not be removed no matter what retention policy is set. This will make sure that at least one restore point is available for user if he did not sync for a long time.

All backed up/stored data is encrypted using 256 bit AES encryption and can be accessed only using inSync restore methods available on server and authenticated clients.

Data cannot be browsed or decrypted using any method other than inSync restore options.

📝 Note
​The Maximum Retention limits :

For more details regarding the backup retention policy please refer to below mentioned link:

Configure the backup retention policy