Azure Site Recovery installation breaks Redgate SQL Backup's ability to restore databases

JasonGoble

Our IT System Administrator recently configured our production networked servers to use Azure Site Recovery to set our servers to maintain recoverability off-site in a disaster recovery scenario. The way this plays out on our SQL server is that (in the Redgate SQL Backup tool) a backup for each of our databases shows up precisely one hour after the other as a "Full" backup. This, of course, to the Redgate tool, invalidates all of the preconfigured backups (one nightly and a 15-min transaction log).


When I go to restore a database, only the transaction logs since the last Azure backup is available for restore. What is funny is that, although I see the backups in the Redgate tool, there is no evidence of them on the SQL Server using the native backup/restore functionality (at least in the UI). However, when I examine the msdb.dbo.backupset / msdb.dbo.backupmediafamily tables, it appears that these "fake backups" all show a logical_device_name of NULL, the physical_device_name is a GUID, the backupset_name is NULL, and the description is NULL. Perhaps, the Redgate software tool could ignore values that show up like these.

petey2

If you can restore the backups taken by Azure Site Recovery (ASR) into a non-recovery state, can you restore the transaction log backups taken by SQL Backup?  The ASR shouldn't 'invalidate' the SQL Backup backups, just that you can't use the GUI to restore backups taken by ASR.

ChrisLives

This only affects Azure VMs being replicated to another site and can be fixed by adding the following registry entry on the SQL node(s):

[HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\BCDRAGENT] "USEVSSCOPYBACKUP"="TRUE"