Job may report warning: "Failed to finalize guest processing. Details: Failed to process 'TruncateSQLLog' command. Failed to truncate transaction logs for SQL instances: <instance name>. Possible reasons: lack of permissions, or transaction log corruption."
SQL logs truncation is done under user account specified in AAIP in Job settings, if it fails then GuestHelper tries to truncate transaction logs under LocalSystem account.
In order to understand why SQL logs truncation failed you will need to open the GuestHelper log on the Guest VM, and search for "Truncation Statistics".
- Windows 2008 or later
- Windows 2003
\\GUESTVM\c$\Documents and Settings\All Users\Application Data\Veeam\Backup\VeeamGuestHelper_%date%.log
Known Errors and Solutions
- Error: OpenFromInitializationString failed. [Login failed for 'DOMAIN\user'.]
Solution: give DOMAIN\user permissions on SQL instance and add db_backupoperator role for all FULL and BULK databases, or give it a sysadmin role.
- OLEDB Error: 'The server principal "DOMAIN\user" is not able to access the database "DATABASE" under the current security context.', HelpCtx: '0'
Solution: give DOMAIN\user db_backupoperator role for all FULL and BULK databases, or give it a sysadmin role.
- OLEDB Error: 'BACKUP detected corruption in the database log. Check the error log for more information.', HelpCtx: '0'
Solution: error points to possible corruption and issues with SQL server
- OLEDB Error: 'BACKUP LOG cannot be performed because there is no current database backup.'
As a rule this is an issue with the secondary node of the SQL always on cluster. You can solve this by making a backup of the DB in question via SQL Management Studio. Otherwise, you can set the secondary node as primary for just one run of your backup job. As a result all its DBs will be backed up without "copy only" flag and the error will disappear.
The issue occurs when the secondary node has always been backed up with "copy only" flag and its standalone DBs do not have any full backup. Thus during the truncation of the standalone DB logs we get the above-mentioned message.
The same solution applies if you get this message with regard to the excluded vCenter database / Veeam database.
- "Query timeout expired"
Solution: Implement the following registry value in affected VMs in [HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\] and [ HKLM\SOFTWARE\Wow6432Node\VeeaM\Veeam Backup and Replication] (if either location does not exist, create it): Try to expand that value and run a backup afterwards, safe guess here is to set it for 600 seconds.
SqlExecTimeout Type: REG_DWORD Default value: 60 (in seconds, decimal)Veeam Agent for Microsoft Windows: If you see this entry in Job log, it usually means that we couldn't truncate SQL logs in allotted time (by default timeout is 300 seconds). Usually you might experience such issues with rather large databases, and with large amount of transaction logs.
Implement the following registry value on affected machines in [HKLM\SOFTWARE\Veeam\Veeam Endpoint Backup]
SqlExecTimeout Type: REG_DWORD Default value: 300 (in seconds, decimal)Try to expand that value and run a backup afterwards, safe guess here is to set it for 1800 seconds.
If you observe the following warning "Failed to truncate transaction logs for SQL instances: MICROSOFT WID" on Veeam B&R version 22.214.171.1244, please contact Veeam Support for the hot-fix.
Please be aware that we’re making changes which will restrict access to product updates for users without an active contract.