Issues Using Differential SQL Backup In Azure VM
If you're running SQL Server on an Azure VM and using both Azure VM Backup and SQL-level differential backups, you may find your differential backups start failing. The cause is a conflict between how Azure VM Backup works and how SQL differential backups track their chain.
The Broken Chain
SQL Server differential backups depend on a continuous chain anchored to the last full backup. The problem occurs in this sequence:
- Sunday 8pm — SQL full backup ✅
- Monday 8pm — SQL differential backup ✅
- Monday 9pm — Azure VM backup ✅
- Tuesday 8pm — SQL differential backup ❌
The Azure VM backup uses VSS (Volume Shadow Copy Service) to create a consistent snapshot. By default this creates a VSS full backup, which SQL Server treats as a new base — breaking the differential chain. Any subsequent SQL differential backup fails because it can no longer find the base it was built on.
The Fix
Set a registry key that instructs the Azure VM backup agent to use VSS copy backups instead of full backups. Copy backups don't affect the SQL backup chain:
Registry path:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BcdrAgent
Key to add:
USEVSSCOPYBACKUP = TRUE (String/REG_SZ)
After setting this key, Azure VM backups use VSS copy mode, which doesn't interfere with the SQL differential chain. Both backup strategies can coexist without breaking each other.
No Reboot Required
The registry key takes effect on the next backup job without requiring a reboot or service restart.