This topic describes the following sections:
Overview of backup policy
Backup policies are rules that define the schedule, bandwidth for scheduled backups, and the retention period for recovery points. In terms of MS-SQL servers, you define the rules for a full backup, differential backup, and transaction log backup jobs for MS-SQL servers.
A backup policy for an MS-SQL server defines the following:
When a backup job is triggered.
The bandwidth available for the agent to execute a backup job.
The period for which a recovery point is retained.
Backup set is enabled or disabled for long term retention. To know more, see About long term retention.
You can create a backup policy and attach it to one or more servers. After you assign servers to backup sets, data from these servers is backed up according to the backup policy. It is possible to create backup policies for File server and MS-SQL server with the same name.
📝 Note
Log backups are not applicable for databases in simple recovery mode.
Best practices for creating a backup policy
You can attach the same backup policy to different backup sets.
You can assign only one backup policy to a backup set.
The backup policy can be of the only type, such as File or MS-SQL, but not both.
You can create as many backup policies as you want, depending on the number of servers and the frequency of data change on these servers. For SQL servers having high volumes of data activity, you can create a backup policy that includes weekly full backups, daily differential backups, and frequent log backups to achieve a tighter point-in-time restore.
📝 Note
The backup schedule that you define in a backup policy depends on your organization's policies.
About retention
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 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 duration 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 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
📝 Note
The above default retention settings are applicable for Warm storage and Long Term Retention (LTR) tiers.
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. |
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.
About log backup retention policy
Transaction logs in SQL servers record updates to a database. A backup of the transaction log provides a lightweight solution to back up and restore for databases that are updated frequently. Druva backs up transaction logs at regular specified intervals after a full or differential backup job is successfully completed. Log backups are retained based on the specified daily retention policy. Since log backups are dependent on recovery points created by full or differential backups, a recovery point is retained if a log backup exists that has a dependency on a recovery point that falls outside of daily retention policy.
For example, the daily retention policy specifies that backups are retained for 30 days. A scheduled differential backup job is executed on Nov 21st, 2020, 12:00: 00 PM which completes on Nov 21st, 2020, 12:30:00 PM, and a recovery point is created. Transaction log backups are triggered every 15 minutes until Nov 22nd, 2020 11:59:59 AM. At this point in time, the latest log backup that exists bears the time stamp Nov 22nd, 2020, 11:45:00 AM. On Nov 22nd, 2020, 12:00:00 PM, the scheduled differential backup job kicks in, and another recovery point is created at Nov 22nd, 2020, 12:30:00 PM.
On Dec 21st, 2020, 12:30:00 PM, based on the daily retention policy, the recovery point created Nov 21st, 2020, 12:30:00 PM is on schedule to be purged. Since the log backup created on Nov 22nd, 2020, 11:45:00 AM exists that is dependent on the recovery point created on Dec 21st, 2020, 12:30:00 PM, the recovery point is retained. This recovery point is purged when the log created on Nov 22nd, 2020, 11:45:00 AM is purged when it expires based on the retention policy.
Log backups are retained based on the daily retention policy. If a log backup falls out of daily retention policy it is truncated. Weekly, monthly, and yearly retention policies are not applicable for log backups.
Create an MS-SQL server backup policy
Before creating a backup policy for MS-SQL servers, ensure that you read Overview of a backup policy.
Step 1 of 3: Enter general information
Log in to the Management Console.
Select the workload from the Protect menu. Note that if the All Organizations menu is enabled, you have to first select an organization that has the MS-SQL server instances and availability groups, and then select the workload.
In the left navigation pane, click Backup Policies.
In the top right corner, click New Backup Policy.
In the General tab, enter the following information:
Name: Enter a name for the backup policy.
Description (Optional):Enter a description for the policy.
Click Next.
Step 2 of 3: Specify the backup schedule
📝 Note
Backup operations follow the time zone of the servers. For example, if you set a schedule for backups to start at 6 AM, backups from servers located in New York and London will start at 6 AM EST and 6 AM UTC, respectively.
In the Backup Schedule tab, perform the following tasks:
Backup Type:
Select the type of SQL server backup from Full, Differential, or Transaction Logs.
❗ Important
This is a Limited Availability draft of the documentation. This documentation is not final, and it will get updated until the General Availability of the feature.
📝 Note
Ensure that you schedule a full and differential backup type in your backup policy. If you do not schedule a full backup, the differential backups will continue using the VSS backup method and not the faster VDI backup method. You must upgrade the SQL agent to version 4.9.4-110537 or later and ensure that the next full backup is successful, after which the differential backups will switch from the VSS to the VDI method.
Backup Frequency:
Select the days of the week when the selected backup type should run. You can specify an interval of 5, 10, 15, 30, 45, 60, or 120 minutes for transaction log backups.
📝 Note
Log backups are not applicable for databases in the simple recovery mode.Start at: Enter the time when you want the backup to start. Select AM or PM after entering the time.
Backup Window (Hrs): Enter the duration after which you want backup operations to stop. For example, if you set Start at to 9 AM and you set Backup Window to 2 hours, backups from your server start at 9 AM and stop at 11 AM even if they do not complete.
Max Bandwidth:
Enter the maximum bandwidth that each MS-SQL server can consume while backing up data to Druva Cloud.If a backup set is mapped to a CloudCache, the bandwidth settings do not apply to the backed-up data sent over the local LAN to the CloudCache. The bandwidth applies only to the backed-up data sent directly to the Cloud.
📝 Notes
For a scheduled backup, the job will consume the assigned bandwidth. However, for manually triggered backup, the job will consume the available bandwidth on your network.
The maximum bandwidth that a backup job can consume is 2 Gbps (2000 Mbps).
Click Add Schedule to add more schedules. You can delete a schedule by clicking the cross icon next to a schedule.
Select Ignore backup window for the first backup to ignore the Backup Window duration for the first backup job. The first backup job may take longer than the specified backup window duration, and selecting this option is recommended. The first backup job is complete when the first recovery point is created. Deselecting this option enforces the backup window duration for the first backup job. To move to the next step, click Next.
📝 Note
For Backup policies created before 21 Dec 2020, the user specified values for Max number of retries and Wait interval before each retry will remain the unchanged. For backup policies created after 21 Dec 2020, Druva will automatically retry a scheduled backup job twice with a wait time of 10 minutes before each retry. Transaction log backups are not automatically retried.
Step 3 of 3: Specify the retention period
In the Retention tab, specify the duration for which the daily, weekly, monthly, and yearly recovery points should be retained. In the Retention tab, specify the duration for which the daily, weekly, monthly and yearly recovery points should be retained.
Once you click Finish you will see the newly created policy on the Backup Policies page.
Daily recovery points for | Duration for which the daily recovery points should be retained. |
Weekly recovery points for | Duration for which the weekly recovery points should be retained. |
Monthly recovery points for | Duration for which the monthly recovery points should be retained. |
Yearly recovery points for | Duration for which the yearly recovery points should be retained. |
Enable Long Term Retention | Toggle to enable or disable LTR for the backup policy. You can enable LTR only if the retention period is greater than or equal to one year. To know more about LTR, refer to About Long Term Retention.
In the Keep recovery points in warm tier drop-down list, specify the duration in days to retain the recovery points in the warm tier. For example, 15, 30, 45, and 60 days. See Impact of changing the threshold on the existing recovery points. |
Enable Data Lock | Toggle to enable the Data Lock for the backup policy. For more information about Data Lock, refer to Data Lock for preventing malicious or accidental deletion of recovery points.
|
📝 Notes
Ensure that you enter a value in at least one of the fields. Druva treats the values in the empty fields as zero.
Any changes that you make to the existing retention policies will be applied to all the new as well as the existing recovery points.
You can also create an MS-SQL backup policy while creating a SQL Backup Set. For more information, see Configure MS-SQL instance or AG for backup.
Copy an MS-SQL server backup policy
You can copy the existing backup policies to create multiple copies of backup policies. When you copy a backup policy, the newly-created backup policy is identical to the policy that it was copied from. You can modify the settings of this policy according to your requirements.
Procedure
Log in to the Management Console.
Select the workload from the Protect menu. Note that if the All Organizations menu is enabled, you have to first select an organization that has the MS-SQL server instances and availability groups, and then select the workload.
In the left navigation pane, click Backup Policies.
In the right pane, select the policy that you want to copy to a new policy, and then click Duplicate Policy.
In the Duplicate Policy dialog box, enter the following information:
New backup policy name: Enter the name for the new backup policy.
Description (optional):Enter a description of the new backup policy.
Click Save.
Edit backup policy
If you are a cloud-derived administrator or a group-derived administrator, you can update the existing backup schedule and retention period. While updating a backup schedule, you can specify the backup type, backup duration, and the bandwidth details. While updating a retention period, you can specify the duration for which you want Druva to retain the daily, weekly, monthly, and yearly recovery points. When you edit the retention period, any changes made in the retention period get applied to all the recovery points whether the recovery points were created before modifying the retention settings or after modifying the retention settings.
Log in to the Management Console.
Select the workload from the Protect menu. Note that if the All Organizations menu is enabled, you have to first select an organization that has the MS-SQL server instances and availability groups, and then select the workload.
In the left navigation pane, click Backup Policies.
In the right pane, click the policy to view policy details.
In the Backup Policies details page, in the Summary tab, you can edit the Overview, Backup Schedule and Retention settings.
Click the Edit button in each section to edit the settings in that section. For detailed field descriptions, see the Create an MS-SQL server backup policy.
View backup sets associated with a backup policy
Log in to the Management Console.
Select the workload from the Protect menu. Note that if the All Organizations menu is enabled, you have to first select an organization that has the MS-SQL server instances and availability groups, and then select the workload.
In the left navigation pane, click Backup Policies.
In the right pane, click the policy whose backup sets you want to view.
In the Backup Policies details page, click the Backup Sets tab to view all the backup sets associated with the backup policy.
Delete MS-SQL server backup policy
If you are a cloud-derived administrator or a group-derived administrator, you can delete backup policies that are not assigned to any servers or are not associated with any backup sets.
❗ Important
Before you delete a backup policy, ensure that you assign a new backup policy to the server.
You cannot delete backup policies that you have assigned to multiple backup sets. Ensure that you associate the backup sets with another policy before deleting the policy.
You can delete a backup policy only after 7 days of the deletion of the last backup set mapped to the policy.
Procedure
Log in to the Management Console.
Select the workload from the Protect menu. Note that if the All Organizations menu is enabled, you have to first select an organization that has the MS-SQL server instances and availability groups, and then select the workload.
In the left navigation pane, click Backup Policies.
In the right pane, click Delete.
📝 Note
You cannot delete backup policies that you have assigned to multiple backup sets.
If you are an LTR customer, you might incur a penalty if you delete a backup policy. To know more, see About long term retention.
If the backup policy has Data Lock enabled, you cannot manually delete this backup policy.