One of my colleague ask if we changed all the databases to simple, and we did not only change the "master" system database. The log files look like this after the change.ġ7-09-2016 11:43:44 2792 Using account DOMAIN\Veeam_Serviceġ7-09-2016 11:43:44 2792 Database master: skipped transaction log truncation.ġ7-09-2016 11:43:44 2792 Database tempdb: skipped transaction log truncation.ġ7-09-2016 11:43:44 2792 Database model: skipped transaction log truncation.ġ7-09-2016 11:43:44 2792 Database msdb: skipped transaction log truncation.ġ7-09-2016 11:43:44 2792 Database BI-PRODUCTION: transation logs have been truncated. So it look like Veeam does not support changing that. Then i looked at the "master" system database on the instance and found the the customers SQL DBA had change the "Recovery model" for that system database to "Full".Īfter changing the Recovery model to Simple, with also is the Microsoft default, the warning disappeared. Use BACKUP DATABASE instead.ġ6-09-2016 22:19:08 3528 Database tempdb: skipped transaction log truncation.ġ6-09-2016 22:19:08 3528 Database model: skipped transaction log truncation.ġ6-09-2016 22:19:08 3528 Database msdb: skipped transaction log truncation.ġ6-09-2016 22:19:08 3528 Database BI-PRODUCTION: transation logs have been truncated. So i looked at the log files on the machine that has the SQL database instance, C:\ProgramData\Veeam\Backup\VeeamGuestHelper_XXXXXXXXX.txt and found this:ġ6-09-2016 22:19:08 3528 Using account DOMAIN\Veeam_Serviceġ6-09-2016 22:19:08 3528 Database master: failed to truncate transaction logs. This normally means that the account used for Application Aware backup is not a member of the role "sysadmin" on the instance, but I check and it was "sysadmin".
#VEEAM BACKUP LOGS SOFTWARE#
VLB files.I had a customer that contacted me to day because he got a warning that Veeam Backup was "Unable to truncate Microsoft SQL Server transaction logs.Details: Failed to process 'TruncateSQLLog' command.įailed to truncate SQL server transaction logs for instances: BI See guest helper log." Veeam backup software writes a lot of logs and they are stored by default on drive C at the following location C:ProgramDataVeeamBackup.
These should show up in the repository as. I would recommend making sure that is set appropriately and the system is actually backing up the transaction log and shipping it to the repository. Veeam does have a setting to perform transaction log backups and how often to perform them. Essentially throwing away the transaction log backup. The other option would be that Veeam is actually running the transaction log backup - but writing the results to the null device.
#VEEAM BACKUP LOGS FULL#
That would eliminate any value of having a database in the full or bulk-logged recovery models since you could never perform a point in time recovery of that database. If Veeam is performing a truncate - then the only way that could occur would be to switch the recovery model to simple - then back to full. If that command is executed against a database instance greater than 2008 it will fail with a statement that TRUNCATE_ONLY is not a valid backup option. The TRUNCATE_ONLY option of the backup log command is no longer available. Looking for any advice or experiences that anyone is willing to share. Veeam's documentation is not fantastic, but some of what I read sort of, kind of, can imply that backing up in this fashion could cause a break in the LSN chain.
0 kommentar(er)
