SQL 2012 + Log Truncation

[lightsout]

This was covered in support case 00669710.

In short, I had this issue - http://www.veeam.com/kb1746

The issue was in the Veeam backup, the truncating of the logs was marked as green, but not occurring due to the permissions. The tech said it was green as the VSS log successfully sends the command successfully to truncate the logs as per this:

11/3/2014 10:39:06 AM 1352 Notifying writers about the 'BACKUP FINISH' event.
11/3/2014 10:39:06 AM 1352 Truncate logs: [true].

However, the same log also showed a lot of errors truncating the logs:

11/3/2014 10:39:08 AM 1352 Executing command: [BACKUP LOG [model] TO DISK = 'NUL']
11/3/2014 10:39:08 AM 1352 WARN Cannot truncate SQL logs for database:'model'
11/3/2014 10:39:08 AM 1352 WARN . Code = 0x80040e14
11/3/2014 10:39:08 AM 1352 WARN Code meaning = IDispatch error #3092
11/3/2014 10:39:08 AM 1352 WARN Source =
11/3/2014 10:39:08 AM 1352 WARN Description =
11/3/2014 10:39:08 AM 1352 WARN OLEDB Error: 'BACKUP LOG is terminating abnormally.'
11/3/2014 10:39:08 AM 1352 WARN OLEDB Error: 'The server principal "NT AUTHORITY\SYSTEM" is not able to access the database "model" under the current security context.'

So, could I request a change so it reports this? I'd like the job to go into a warning state to indicate log truncation as failed, as just sending the command is not enough, it really should also check the return code too!

[veremin]

I've passed this information to the QA team. We'll see what can be done in this regard. Thank you for raising this issue; much appreciated.

[lightsout]

Veeam Update 2 seems to have some much improved logic on this front. It already gave us a warning for a DB which wasn't truncating correctly, which Update 1 didn't do.

[Gostev]

Wow! Thanks so much for coming back to update your own topic! Wish more people did that
Indeed, Update 2 covers some holes in log truncation failure reporting.
Keep the feedback coming on these forums! We do listen to it.