SQL log chain broken issue when the same VM is backed up using VMware/HyperV policy on Druva.
There is a validation check from Phoenix side which checks whether any log backups were executed after the last full/diff backup. At that time it validates last_lsn(log sequence number) from MS SQL server (from the msdb.dbo.backupset table) entries with Phoenix metadata last_lsn. If there is any mismatch then it reports a log chain broken issue.
After SQL backup, if any VM backup runs then it breaks the log chain sequence because app consistent backup calls all the VSS writers present on to the system to take a backup.
If SQL backups are enabled with VMware/Hyper-V backups (without appaware)
- Please check whether you can configure appaware backups.
- If only SQL application is on VM (no other applications which require app consistent backups) then disable VMware/ Hyper-V tools quiescing on Vmware/Hyper-V backup policy on Druva console. After this, run a discovery of VMs on the console by clicking the refresh button. Please check the screenshot below:
- If other applications exist which require app consistent backups, a workaround is to have a policy such that always schedule a SQL full/diff backups immediately after VMware backups.
- (Not applicable to Hyper-V) If option a & b could not help, in that case there is a setting to exclude specific VSS writers from VMware-
- If you add the specific SqlServerWriter to the vmbackup.conf file then it should exclude that VSS writer being called at the time of snapshot backup.
- Reference article VMware Knowledge Base
- Please restart the VMware tools service after making the changes.
- (Not applicable to Hyper-V) Try the quiescing setting on VMware tools level and disable the vss.disableAppQuiescing = True. To disable VSS application quiescing using VMware Tools, refer to the following articles: