This article provides insights into the backup and restore methods used for protecting your Azure SQL resources. Before backing up your SQL resources, you must configure your resources for backup and restore. For more information, see Quick reference guide.
Backup methods
We support the following backup types:
Full + Incremental (Recommended)
After you configure your Azure SQL resources for backup, Druva performs a full backup of the databases on your logical servers (or instances) based on the backup policy.
Druva's Quantum Bridge executes a full scan of all the databases included in the backup. For FULL backups, the complete database is backed up every time, and then deduplication is applied. When the backup job is successful, Druva creates a recovery point in your storage.
The Full + Incremental method is selected by default for all new policies and is the standard configuration for existing policies. It is designed for high-performance recovery and granular data protection. This method utilizes Change Data Capture (CDC).
Important considerations
The Full + Incremental method:
Enables CDC on your database to support incremental tracking, if not already enabled.
Enables Point-in-Time Restore (PITR) with second-level granularity, allowing you to recover data to a specific moment in time.
For more information, see About Full + Incremental backups
Isolated Copy
The Isolated Copy method is recommended for databases that do not support Change Data Capture (CDC) or where CDC cannot be enabled. The periodic full backups are captured via an Azure Database Copy.
Important considerations
This method supports Full backup schedules only; incremental backups are not applicable for this configuration.
About Isolated Copy Protection exclusively supported for Azure SQL Database.
An ephemeral database instance is created during the backup process, which will incur standard Azure resource consumption costs during the backup window.
For more information, see About Isolated Copy Protection.
The following table compares the key features and requirements of the two backup methods:
Key Differentiator | Isolated Copy (Non-CDC) | Full + Incremental (CDC) |
Point-in-Time Restore | Not supported | Supported — Available with seconds-level granularity |
Database modification required | None required | Requires CDC enablement (CDC enabled automatically). |
Supported database tiers | All tiers, including Basic, S0, S1, S2 | Premium, General Purpose, and Business Critical (DTU-based Basic and Standard S0–S2 are not supported) |
Azure charges | Usage-based charges for the temporary copy | Standard backup charges |
Backup Considerations
The backup process first backs up the schema, followed by the corresponding tables. If any tables are deleted during this time, SQL Server will generate an error for those tables, which will result in backup failure. We recommend updating or deleting the tables outside of the scheduled backup window.
We support Transparent Data Encryption (TDE) enabled databases.
TDE will not be enabled by default on the restored databases for Azure SQL on VM Server.
We support Temporal database tables and their corresponding history tables.
Notes
Temporal and history tables are included in FULL backup jobs.
We do not back up CDC data for history tables.
During restore, the Temporal table is fully restored, while the history table data is restored only up to the last FULL backup.
Deduplication is lower for system database backups as compared to user databases.
System database backup supports Full backups. Change Data Capture backups do not apply to system databases. For more information, see error 22989 in the Microsoft documentation.
Do not associate a backup policy with a Change Data Capture backup type for protecting system databases. Any attempt to use CDC functionality will result in the system databases being skipped or the backup failing entirely. For more information, see Unsupported Backup scenarios.
For existing discovered instances of SQL Server on Azure Virtual Machines, perform a one-time manual re-discovery to enable the visibility of system databases for configuration.
If the database, schema, table, or column name contains special characters and backup jobs have already run, create a new backup set to ensure backups work properly for such databases
Database names containing colons ‘;’ are not supported.
During backup, if one of the databases is not in READY state :
The backup job completes with errors
The database will be skipped and it's recovery points will not be available until the next FULL backup.
The recovery points created till the time the database goes down will be available for restore.
If no table exists in the database, backup will fail.
If you have assigned Service Principal for authentication, make sure you map it in the Azure environment, else backup will fail. For more information, see How to map service principal in Azure.
If a backupset has multiple databases and one of them is down:
Full backup on the backupset completes with successful with errors status.
Next CDC also completes with successful with errors status, with error as DBs skipped or down log
Next CDC gets marked as successful
If you have enabled CDC on a managed instance, then make sure you disable CDC before deleting a database on that managed instance.
About system database backups for SQL Server on Azure Virtual Machines
System databases such as master, msdb, and model are backed up for SQL Server on Azure Virtual Machines. System database backups are encrypted at all times during backup and recovery, via SQL Server certificates that our solution automatically creates, manages, rotates, and protects.
The system ensures recoverability by automatically restoring certificates if they are missing during a database restoration.
Unsupported backup scenarios
Consider the following scenarios and the corresponding expected behavior:
Scenario | Behavior |
Backup set includes both user and system databases, and CDC backup is enabled in the policy. | System databases are skipped during the CDC backup. |
Backup set includes only system databases, and CDC backup is enabled in the policy. | Backup fails with AZURE_SQL 1057 error. |
Restore methods
After you back up your databases, you can restore the complete database to a consistent state from a recovery point. Currently, we support recovery point restore only.
Recovery Points
To restore the databases, you select a recovery point.
When you trigger a restore job, you can see the available warm recovery points. A warm recovery point is a point-in-time image of the backup data. Druva directly backs up the data to the warm storage and is referred to as "warm recovery points". For more information, see Enterprise Workloads key concepts and terms.
📝Note:
The account used for SQL backups and restores must also have the CREATE DATABASE permission for successful restores from recovery points. If the account used for SQL backups and restores does not have the CREATE DATABASE permission, the restores may fail.
Related Keywords
cdc backups, non-cdc backup, isolated copy protection, isolated copy backup, isolated copy data protection