Comments
Sort by recent activity
I'm running Azure IaaS with SQL Server. I'm using the https://ola.hallengren.com backup maint solution in an Agent job. When running the agent job, the physical_device_name will populate with the ex: '.\path\filename.bak'. During unexpected non-sql-agent scheduled times, a random GUID would appear within the physical_device_name field. After opening a premier support case with Microsoft, I was advised that this was caused by VSS (Rob you were very close). Here is the link Microsoft shared with me: https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-introduction What happening is the Azure IaaS backup/snapshot will by default backup everything on the OS and as well SQL databases. The 'SQL database' backups were being backed up in a logical form to the OS/snapshot only. On top of that, it would also by default run these what I call 'rogue/ghost' backups with the parameter as 'copy-only = 0' what that means it no copy-only enabled.. Which means break the log chain. So you can't run diff backups. The fix was to add a registry key to the OS that explicitly tells VSS to not run these SQL backups with 'copy-only = 0': REG ADD "HKLM\SOFTWARE\Microsoft\BcdrAgent" /v USEVSSCOPYBACKUP /t REG_SZ /d TRUE /f (The MSFT engineer advised that no restart was required for adding this regkey. I later confirmed that to be true). After making this regkey change, I stopped seeing the GUID in the physical_device_name field and finally my SQL instance was back to normal. / comments
I'm running Azure IaaS with SQL Server. I'm using the https://ola.hallengren.com backup maint solution in an Agent job. When running the agent job, the physical_device_name will populate with the...
I'm running Azure IaaS with SQL Server. I'm using the https://ola.hallengren.com backup maint solution in an Agent job. When running the agent job, the physical_device_name will populate with the ex: '.\path\filename.bak'. During unexpected non-sql-agent scheduled times, a random GUID would appear within the physical_device_name field. After opening a premier support case with Microsoft, I was advised that this was caused by VSS (Rob you were very close). Here is the link Microsoft shared with me: https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-introduction What happening is the Azure IaaS backup/snapshot will by default backup everything on the OS and as well SQL databases. The 'SQL database' backups were being backed up in a logical form to the OS/snapshot only. On top of that, it would also by default run these what I call 'rogue/ghost' backups with the parameter as 'copy-only = 0' what that means it no copy-only enabled.. Which means break the log chain. So you can't run diff backups. The fix was to add a registry key to the OS that explicitly tells VSS to not run these SQL backups with 'copy-only = 0': REG ADD "HKLM\SOFTWARE\Microsoft\BcdrAgent" /v USEVSSCOPYBACKUP /t REG_SZ /d TRUE /f (The MSFT engineer advised that no restart was required for adding this regkey. I later confirmed that to be true). After making this regkey change, I stopped seeing the GUID in the physical_device_name field and finally my SQL instance was back to normal. / comments
I'm running Azure IaaS with SQL Server. I'm using the https://ola.hallengren.com backup maint solution in an Agent job. When running the agent job, the physical_device_name will populate with the...