After discovering databases and assigning authentication type, you must configure the databases for backup. For more information about how the backups are taken, see Azure SQL backup workflow.
The following sections provide details of manual configuration settings.
Get started with configuring for backup
To protect your SQL resources, you must first set up your SQL resources for backup.
As a part of the configuration, you must do the following:
Create and/or assign a backup policy
Add or edit backup settings
Add or edit retention settings
About backup policy
Backup policies are rules that define a schedule, bandwidth for scheduled backups, and retention period for recovery points. By defining backup policies, you can define the rules for backing up Azure SQL resources.
A backup policy defines the following:
When a backup job is triggered.
The backup frequency.
The period for which a recovery point is retained.
Druva provides a default backup policy. Druva backs up the SQL resources based on the backup schedule defined in a backup policy.
Considerations
You can attach the same backup policy to different backup sets.
The backup policy defines the backup schedules for your SQL resources. The schedules that you set depends on the volume and frequency of changes. If you expect a large chunk of data for backup, you can schedule backups to run during off-peak hours, such as weekends or after a workday.
Create backup policy
You can create a backup policy using three easy steps as shown in the following diagram:
No. | Step | Action |
1. | Backup Policy Overview | Provide the policy name, description, and select the backup method. For more information, see Step 1: Provide Backup Policy Overview. |
2. | Backup Schedule | Provide the schedule at which you want to run your backups. For more information, Step 2: Provide Backup Schedule. |
3. | Backup Retention | Provide retention settings for your backups. For more information, see Step 3: Provide Backup Retention Settings |
Step 1: Provide Backup Policy Overview
Log in to the Management Console.
On the console, from the top menu, select Organization.
Select Protect > Go to Azure.
In the left navigation pane, click Backup Policies.
On the Back Policies listing page, click New Backup Policy > Azure SQL.
On the New Backup Policy > Overview tab, enter the following details:
In the Overview section, provide
Policy name: Name of the backup policy
Description: A summary of the backup policy. This is an optional field.
In the Backup method, select one of the following:
Full + Incremental (Recommended): This is the default configuration for all new and existing policies. It leverages Change Data Capture (CDC) to provide high-performance backups and enables second-level granularity via Point-in-Time Restore (PITR). This method is supported for Standard S3 tiers and above. For Basic or lower Standard tiers (S0–S2), use the Isolated Copy method.
Isolated Copy: This method uses Azure Database Copy to take periodic full backups and does not require Change Data Capture (CDC) configuration. This method is ideal for environments where CDC is restricted or where a zero-modification approach to the database is required.
Note:
This method follows a Full backup schedule; incremental backups are not supported for this configuration. For information, see Isolated Copy.
This method is designed specifically for Azure SQL Databases. For Managed Instances or SQL Servers on Azure Virtual Machines, use Full + Incremental method.
For more information, see Limitations and Considerations.
7. Click Next.
Next Steps
Proceed to the Schedule tab, to configure your backup frequency, ensuring the interval aligns with your organization's Recovery Point Objective (RPO).
Step 2: Provide Backup Schedule
You can either retain the default schedule or add your own schedule to back up SQL resources. You can add more than one schedule to backup your SQL resources. To add a new schedule:
On the New Backup Policy > Backup Schedule tab, click Add Schedule.
Provide the following details and click Next:
Field | Description |
Backup Type | Backup Type: The backup type options are available depending on the Backup Method that you chose on the Overview tab.
|
Backup Frequency | Select the days on which the automatic backups should occur at the specified time. For FULL backups, you can schedule the frequency as daily or weekly. For Incremental backups, you can schedule the frequency in hours. |
Start at | Select the off-peak time, in a 12-hour format, when you want backups to start.
Backup operations follow the server Timezone.
|
Backup Window | Set the duration for how long the backup should run. Type the number of hours.
Example
If you set Start at to 01:00 AM and you set the duration to 6 hours, backups from your server start at 01:00 AM and stop at 07:00 AM, even if they do not complete. |
Ignore backup window for first backup | The Ignore backup window for the first backup option is enabled by default. When this option is enabled, it ignores the specified backup duration until the first backup job is complete. The first backup job is complete when the first recovery point is created. You can disable this option to enforce backup duration for the first backup job. |
Next Steps
Once your schedules are defined, move to the Retention tab to specify how long these backups should be stored.
Step 3: Provide Backup Retention Settings
You can retain the default retention settings or provide custom retention settings to determine the duration for which you want to retain your backups.
Field | Description |
Daily Recovery points for | Specify the number of days, for which you want to retain all the daily recovery points. The default value is 14. |
Weekly Recovery points for | Specify the number of weeks for which you want to retain the latest weekly recovery point. The default value is 4. |
Monthly Recovery points for | Specify the number of months for which you want to retain the latest monthly recovery point. The default value is 3. |
Yearly Recovery points for | Specify the number of years, for which you want to retain the latest yearly recovery point. The default value is 3. |
Enable Long Term Retention (LTR) (and) Keep recovery points in the warm tier
| Enable to retain your data for a longer duration (one year or more) and select the number of days to retain recovery points in the warm tier (threshold). 📝 Notes
For more information, refer to Long Term Retention for Enterprise Workloads.
|
Enable Data Lock | Set the Enable Data Lock toggle to protect recovery points from accidental and malicious deletion. For more information, see Enable Data Lock. |
Edit a backup policy
You can edit an existing backup policy. When you change the backup policy settings, then from that time onwards, the backups will be taken as per the new schedule and retention settings. You can edit the following information in a backup policy:
Overview
Backup Method
Backup schedule
Retention settings
Procedure
Before editing the backup methods, see Impact of Changing Backup Methods or Backup Policy.
Log in to the Management Console.
On the console, from the top menu, select Organization.
Select Protect > Go to Azure.
In the left navigation pane, click Backup Policies.
On the Back Policies listing page, click the backup policy that you want to edit.
To edit the backup policy, on the Summary tab, click the Edit button of the section that you want to edit, such as Overview, Backup Method, Backup Schedule, and Retention, as shown in the following screenshot:
Make the required changes and click Save.
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.
📝 Note
The retention period would not be honored for the most recent recovery point when a 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 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 11 ( 14 daily less 2 weekly less 1 monthly) recovery points (starting from 27 Jan) created due to the daily retention 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 TurboTier and 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.
Related Keywords: Azure SQL backup configurations, Azure SQL backup settings,
azure SQL backup policy