SQL logs truncation is done under the 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". Beneath the line "
Transaction log truncation statistics" you will see information about which account was used, which SQL instances were processes, and a list of each database that was interacted with.
- 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"
Veeam Backup & Replication:
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
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.
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]
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.