❗ Important
The availability of this feature may be limited based on the license type, region, and other criteria. To access this feature, contact Support.
Backup policies are rules that define the schedule for automatic backups. A Backup Policy defines the backup schedule and the tiered retention settings for your AWS data. You can create a backup policy and apply it to one or more backup sets.
Best practices for creating a backup policy
Best practices for creating a backup policy
You can create as many backup policies as you want, depending on the number of Amazon file systems and the frequency at which data changes in these buckets. For example, for Amazon file systems that change frequently, you can create a backup policy, and define a schedule for a weekly backup for a longer duration, along with short-burst backups every second day.
The backup policy defines the backup schedules of Amazon Elastic File Systems. The schedule that you set must be according to the volume and frequency of data change in the Amazon file systems. If you expect a large dataset during backups, you can schedule backups to run during off-peak hours (such as weekends or after a workday).
You can consider the criticality of data and the frequency at which the data changes and is restored while configuring the retention policy. The important factors to consider while configuring retention are:
Storage costs
Type of data
Managing retention period
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.
❗ Important: The retention period would not be honored for the most recent recovery point when File System 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
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. 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.
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 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
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
📝 Note: The above default retention settings are applicable for Warm storage and Long Term Retention (LTR) tiers.
Example
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:
Daily retention setting: You will have 11 recovery points ( 14 daily less 2 weekly less 1 monthly, 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 one 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)
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
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 Druva Cloud.
Druva runs a retention expiration algorithm to delete the recovery points that have crossed the expiration period.
❗ Important
To access Amazon EFS backup policies, navigate to Policies > EFS in the AWS Workloads Management Console. The steps differ from those for EC2 and other workloads.
Create a new backup policy
Log in to the AWS Workloads Management Console.
On the top navigation bar, select Policies.
Click EFS in the left pane to view Amazon File System backup policies.
Click New Backup Policy.
You can also click the Customize Table Columns icon to get a list of all the columns on the page.
Select the checkbox to display the column.
Clear the checkbox to hide a column on the EFS Backup Policies table. Removing unnecessary columns will make the UI more spacious.
Move a column to change the order. The change is reflected in the Backup Policies table.
Step 1: Specify the following policy Setup information:
Add a Name and a brief Description for your policy. Click Next.
Step 2: Backup Schedule
On the Backup Schedule tab, specify the following and click Next.
Field | Description |
Backup Frequency | Select the days on which you want the backups to run. |
Start At (server Timezone) | The time when you want backups to start. |
Backup Window (Hrs) | The duration after which you want backup operations to stop. For example, if you set Start At to 9 AM and you set the Backup Window to 2 hours, backups of your Amazon File Systems start at 9 AM and stop at 11 AM, even if they do not complete. |
Add Schedule | Click this button to create as many schedules as you want. |
Remove icon (X) | The remove icon is enabled if you have added more than one schedule. If you have added only one schedule, it cannot be removed. |
Ignore backup window for first backup | The option to ignore the specified backup duration for the first backup job. You can disable this option to enforce backup duration for the first backup job. |
Timezone | Select the timezone. |
Step 3: Retention
Under Retention, enter the duration for which the daily, monthly, weekly, and yearly recovery points should be retained. Click Finish.
See Manage retention for a visual breakdown and further information on retention period.
Field | Description |
Daily | Enter the duration (in days) you want to retain the archived data. Daily snapshots must be retained for at least 365 days. |
Monthly | Enter the duration (in months) you want to retain the archived data. Monthly retention settings can be defined as per your needs. |
Weekly | Enter the duration (in weeks) you want to retain the archived data. Weekly retention settings can be defined as per your needs. |
Yearly | Enter the duration (in year) you want to retain the archived data. Yearly retention settings can be defined as per your needs. |
Data Lock | Enable the Data Lock for the backup policy. Data Lock prevents your backup recovery points from accidental or malicious deletion or modification. For more information about Data Lock, refer to Data Lock for preventing malicious or accidental deletion of recovery points.
📝 Note: Once you apply Data Lock to the backup policy, you cannot:
|
Edit a backup policy
Log in to your AWS Workloads management console.
On the top navigation bar, select Policies.
Click EFS in the left pane and select the Amazon EFS backup policy to be modified.
On the Summary tab, click Edit to modify any of the following:
Delete a backup policy
You can remove backup policies that are not assigned to Amazon EFS resources. Before you remove a backup policy, ensure that you assign a new backup policy to the Amazon file system.
Log in to your AWS Workloads management console.
On the top navigation bar, select Policies.
Click EFS in the left pane and select the Amazon EFS backup policy. Click Delete.
On the confirmation dialog, click Yes to proceed with the deletion.
📝 Note: You cannot delete the Default backup policy or one that is currently mapped to an active Amazon EFS resource.
Duplicate a backup policy
To create multiple copies of a backup policy without having to create a backup policy each time, you can create a copy of an existing backup policy.
When you create a copy of a backup policy, the newly-created backup policy is identical to the policy that it was copied from. You can modify the properties of this backup policy according to your requirements.
Log in to your AWS Workloads management console.
On the top navigation bar, select Policies.
Click EFS in the left pane and select the Amazon EFS backup policy. Click Duplicate Policy.
On the Duplicate Policy page, modify the name of the new backup policy and description.Click Save.