Retention defines the rules for retaining your backups (recovery point) within the storage. Use the retention period to define the duration for which you want to retain your historical backups.
The objective of retention is to keep important data for future access, depending on how critical it is. Retention also ensures that backups that are no longer required are cleaned from your storage periodically, resulting in less storage utilization and costs.
The retention period would not be honored for the most recent recovery point when a server or VM or backup set is disabled. This allows you to restore the latest recovery point later if required.
Retention should consider the value of your data and the compliance requirements. The different types of data will be retained for different durations. For example, a bank's retention period for customers' financial records is different from facilities inventory records.
The main factors to consider while defining a retention period are:
- Compliance requirements
- Storage costs
- Type of data
Retention period settings
Druva follows the Grandfather-Father-Son (GFS) retention model wherein, in case of an overlap, the retention setting of the longer period (Son-Father-Grandfather relation) is considered. The recovery point is expired as per the settings of the higher period. For example, in case there is an overlap between the daily and weekly retention period, the weekly retention period is considered. So daily is the smallest unit and weekly overrides daily > monthly overrides weekly > yearly overrides monthly.
Also, Druva follows the Gregorian calendar for tracking days.
While backup schedules are configured on an hourly, daily, or weekly basis the last recovery point created by the backups on that particular day will be retained as per the retention setting.
You can define the following durations to retain recovery points.
| Retention Period |
Description |
| Daily recovery points |
Druva retains all the recovery points that are created for the number of days specified in Daily recovery points.
Druva considers midnight as the end of a day.
If you have configured Druva to back up your server multiple times within a day, Druva retains all the recovery points for the days specified. |
| Weekly recovery points (Son) |
The number of weekly recovery points that Druva should retain. Druva treats the latest recovery point in the week as the weekly recovery point.
Druva considers midnight on Sunday as the end of the week.
|
| Monthly recovery points (Father) |
The number of monthly recovery points that Druva should retain. Druva treats the latest recovery point in the month as the monthly recovery point.
Druva considers midnight of the last day of a month as the end of the month.
|
| Yearly recovery points (Grandfather) |
The number of yearly recovery points that Druva should retain. Druva treats the latest recovery point in the year as the yearly recovery point.
Druva considers the midnight of the last day of the year as the end of the year.
|
The recovery point name displayed on the Hybrid Workloads Management Console is recovery point creation time as per the server time zone, on which the backup occurred. Druva considers the time zone of the server for retaining the recovery points as per the retention setting.
Default retention period settings
If you are registering the server under default organization, Druva provides a default backup policy with the following retention settings:
- Daily recovery points: 14 days
- Weekly revisions: 4 weeks
- Monthly revisions: 3 months
- Yearly revisions: 3 years
Example
The following diagram illustrates the recovery points that will be available on a given day ( Feb 9 in this example) based on the retention settings you have configured. In this example the policy is created and backups start on Dec 30 of the previous year.
On 9 Feb you will have 17 recovery points or recovery points to restore as described in the table.
Note: Daily is the smallest unit and weekly overrides daily and monthly overrides weekly and yearly overrides monthly.
|
Recovery points resulting from
|
Description
|
| Daily retention setting |
You will have 11 ( 14 daily less 2 weekly less 1 monthly) recovery points (starting from 27 Jan) created due to the daily retention settings. |
| Weekly retention setting |
You will have 4 recovery points for 14 Jan, 21 Jan, 28 Jan and 4 Feb created due to the weekly settings.
The weekly recovery points that coincide with the daily recovery points (28 Jan and 4 Feb) will be considered and retained as per the weekly setting. So, even though the daily retention period expires for these dates the recovery points will be retained as per the weekly settings (4 weeks). |
| Monthly retention setting |
You will have 1 monthly recovery point of 31 Jan. This recovery point will be available for the next 3 months as it is a monthly retention point. So even though the 14 days daily retention period expires after 9 Feb, the recovery point will be available for the next 3 months. |
| Yearly retention setting |
You will have one recovery point for 31 Dec due to the yearly retention setting. This recovery point will be available for 3 years. |
Impact of retention period settings on recovery point objective (RPO)
In continuation with the example above, so let us say malware was detected on 9 Feb evening. After investigation, it was discovered that the data till 7 Feb is corrupted. In that case, the recovery point available to you will be of 6 Feb which is available due to the daily recovery point. However, there could be a data loss of data backed between 7 Feb and 9 Feb.
Considerations
- Any changes that you make to the existing retention policies will be applied to all the new as well as the existing recovery points.
- Retention periods are applicable for recovery points that reside on CloudCache and Druva Cloud.
- Druva runs a retention expiration algorithm to delete the recovery points that have crossed the expiration period. This algorithm does not delete thawed recovery points. For more information, see Recovery points.
Business 