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
Full
After you configure your Azure SQL resources for backup, Druva performs a full backup of the databases on your server hosts based on the backup policy.
The 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 everytime and then deduplication is applied. When the backup job is successful, Druva creates a recovery point in your storage.
Change Data Capture (CDC)
Change Data Capture (CDC)
When we take a FULL backup, the backed-up data might not be transactionally consistent. This means that if any transactions happen on the database during the backup, those changes will not get captured in the backup and we might lose out on that data.
To overcome this issue, our data protection solution utilizes Microsoft’s Change Data Capture (CDC) feature to track changes made to the database without modifying the original schema. CDC records changes made to the database such as inserts, updates, and deletes, and stores this information in special CDC tables, making it easily consumable for further use. You can use this information for taking incremental backups and syncing data across systems. Using CDC, you can have transactionally consistent copies of data for backup. For more information, see What is change data capture (CDC)?
Important:
Before taking CDC backups, configure the settings mentioned here. Failure to do so might result in the database being skipped from backups or failed backups.
CDC backup scenarios
This section describes different scenarios that might occur for CDC backups, the action Druva takes, and recommended actions required if any:
First backup scenarios
Scenario | Action taken | Recommended action |
CDC is disabled on the database. | Druva enables CDC on the database. For more information, see Backup Prerequisites. | Make sure you have the |
CDC is enabled on the database but there is a mismatch due to the following reasons:
| Druva skips that database from the backup and the backup completes with errors. | Configure the recommended settings for CDC backups and try again. For more information, see Backup Prerequisites. |
CDC is enabled manually | The database is considered for backup. However, Druva does not perform cleanup of CDC data post backup. | Cleanup the database by configuring recommended cleanup job settings. Set the retention parameter to minimum 1 day. For more information, see Backup Prerequisites. |
Subsequent backup scenarios
Scenario | Action taken |
CDC is disabled between backups. |
|
CDC is enabled on the database by Druva but does not match the required configuration. |
|
To enable CDC on database and tables, see Enable CDC on database and tables.
Isolated Copy Data Protection
Isolated Copy Data Protection
❗Important
To sign up for this feature, contact Support.
Druva’s Isolated Copy Protection provides a high-integrity, cloud-native backup framework designed for the modern Azure SQL ecosystem. By utilizing an ephemeral, agentless architecture, Druva orchestrates a transient "Copy-and-Export" workflow that ensures zero impact on your primary production workloads. Unlike traditional methods that may require invasive database-level configurations, this feature leverages native Azure COPY and bcp utilities to create transactionally consistent, air-gapped backups in the Cloud.
This approach offers universal compatibility across the Azure SQL family—including General Purpose, Business Critical, and Hyperscale—ensuring that organizations can maintain a unified security posture even in environments where Change Data Capture (CDC) is restricted by policy, performance overhead concerns, or specific service-tier limitation.
Key Benefits
Zero-Impact Data Extraction: By offloading the heavy lifting to an ephemeral, isolated copy, Druva ensures that the resource-intensive backup process never competes with your primary application’s IOPS or memory.
Universal Azure SQL Coverage: Provides a unified protection standard across the entire Azure SQL spectrum. This extends enterprise-grade backup capabilities to environments—such as Basic and Standard tiers—that are often left vulnerable due to a lack of support for log-based movement.
Zero-Friction Deployment: Deployment is completely non-invasive. Because this method requires no database-level configuration changes (like enabling CDC), no custom scripts, and reduced permission sets, it bypasses the typical "Red Tape" associated with DBA and Security reviews.
Full-Spectrum Consistency: Beyond just data, this method captures a transactionally consistent "point-in-time" snapshot of the entire database environment—including schema, metadata, triggers, views, and security roles—ensuring a "ready-to-run" state upon recovery.
How It Works
The Isolated Copy workflow is fully automated and ephemeral:
1. Copy Database: Druva triggers a native command to create a temporary copy of your source database on the same logical server (or within the same Elastic Pool).
2. Orchestration: A temporary compute instance (Druva Quantum Bridge) is spun up within your Azure environment.
3. Secure Transfer: The Quantum Bridge reads the temporary database copy and securely transfers the data to the Cloud. The data is deduplicated and stored in an air-gapped vault.
4. Cleanup: Once the data transfer is verified, Druva immediately deletes the temporary database copy and terminates the Quantum Bridge VM. This ensures no orphaned resources remain in your subscription.
To ensure data integrity, Druva orchestrates the creation of a temporary DB copy and a Quantum Bridge VM. This allows for a side-channel backup that doesn't impact your production instance's performance.
What is protected using Isolated Copy Protection
Isolated Copy Protection protects database-level objects, including data, schemas, views, and triggers. It does not capture instance-level metadata or configurations, such as:
SQL Agent Jobs
Server-level Logins
Linked Server Definitions
System Databases.
For limitations and considerations for Isolated Copy Protection, see Limitations and Considerations.
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.
NotesTemporal 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