- Veeam Support Knowledge Base
- SQL Transaction Log Backup - Failed to prepare guest for SQL transaction log backup Details: is responsible for SQL transaction logs backup
SQL Transaction Log Backup - Failed to prepare guest for SQL transaction log backup Details: is responsible for SQL transaction logs backup
Cheers for trusting us with the spot in your mailbox!
Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest
Challenge
Failed to prepare guest for SQL transaction log backup Details: <Other Job> is responsible for SQL transaction logs backup
Cause
When backing up an Always On availability group's nodes it is best practice to have all the nodes in the same job.
Veeam Backup & Replication will display the warning related to this KB if it detects that the server being backed up is part of a SQL Always On group and another node in that group is already being processed by SQL Transaction Log Backup.
Further reading on this topic:
- https://helpcenter.veeam.com/docs/backup/vsphere/alwayson_support.html?ver=110
- https://forums.veeam.com/microsoft-hyper-v-f25/backup-logs-options-with-alwayson-ag-t32096.html
- https://forums.veeam.com/vmware-vsphere-f24/best-way-to-backup-always-on-sql-cluster-multi-istance-t71912.html
- https://forums.veeam.com/veeam-backup-replication-f2/sql-alwayson-in-2-datacenters-t37971.html
Solution
If the job displaying this warning is not intended to be the primary SQL log backup job, disable the transaction log backup for that VM within that job.
Else if the job displaying this warning is intended to be backing up the SQL transaction logs, after disabling transaction log backup for the VM in the other job, the following three options are available:
Option 1: Wait
Wait the 7 day timeout. The timer will start from the last day the VM was processed by the old job.
Option 2: Change the timeout
Change the TimeOut to a lower setting with the following registry keys on the server where Veeam Backup & Replication is installed. Reboot is not required, changes are detected instantly.
Location: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
DWORD: SqlBackupLogsAgeDaysToSkipLogBackup
Value: x
Location: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
DWORD: SqlBackupLogsAgeDaysToSkipTruncate
Value: x
Where is x is the number of days.
Log truncate will be skipped for a VM if there are SQL logs of this VM collected last X day (defined in the registry as value SqlBackupLogsAgeDaysToSkipTruncate/default is 7) by another existing job.
SQL log backup will be skipped for a VM if there are SQL logs of this VM collected last X day (defined in the registry as value SqlBackupLogsAgeDaysToSkipLogBackup/default is 7) by another existed job.
Option 3: Force removal of all SQL Transaction Log Backups from the Old Job
As a forceful workaround you Force Veeam to not consider the old job by expanding the old backup set and removing the transaction logs from the job. Doing so will remove all transaction logs for the SQL VMs in that backup set that were collected after the most recent restore point was created. You will still have point-in-time restores for all restore points leading up to the most recent backup.
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
Spelling error in text
Thank you!
Your feedback has been received and will be reviewed.
Oops! Something went wrong.
Please try again later.
You have selected too large block!
Please try select less.
KB Feedback/Suggestion
This form is only for KB Feedback/Suggestions, if you need help with the software open a support case
Thank you!
Your feedback has been received and will be reviewed.