Job reports warning "Failed to truncate transaction logs for SQL instances: Possible reasons: lack of permissions, or transaction log corruption."

Challenge

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."

Solution

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 higher
  \\GUESTVM\c$\ProgramData\Veeam\Backup\VeeamGuestHelper_%date%.log
• Windows 2003
  \\GUESTVM\c$\Documents and Settings\All Users\Application Data\Veeam\Backup\VeeamGuestHelper_%date%.log

Known Errors and Solutions

1. 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.
    
2. 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.
    
3. 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
    
4. 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.
    
5. "Query timeout expired" If you see this entry in VeeamGuestHelper log, it usually means that we couldn't truncate SQL logs in allotted time (by default timeout is only 60 seconds). Usually you might experience such issues with rather large databases, and with large amount of transaction logs
   Solution: Implement the following registry value in affected VMs in [KLM\SOFTWARE\Veeam\Veeam Backup and Replication\] and [ HKLM\SOFTWARE\Wow6432Node\VeeaM\Veeam Backup and Replication] (if either location does not exist, create it):
   • SqlExecTimeout
   • Type: REG_DWORD
   • Default value: 60 (in seconds, decimal)
   Try to expand that value and run a backup afterwards, safe guess here is to set it for 600 seconds.

More Information

If you observe the following warning "Failed to truncate transaction logs for SQL instances: MICROSOFT WID" on Veeam B&R version 8.0.0.2084, please contact Veeam Support for the hot-fix.