SQL Transaction Log backup not working

[jonboy]

I recently discovered a number of large files which had not been deleted by the Veeam SQL Log backup process. These files are generated by the Veeam agent running a SQL Log backup job to a local folder on the SQL server and are then copied to the Veeam repository before being deleted. In some cases these files were not deleted and consumed space which was the starting point for my opening a case with Veeam.

Investigation has revealed that these orphaned log files occur following a developer taking their own SQL backup without setting the copy only flag. Clearly this is something which needs to be fixed (be educating the developers concerned) however what I also notice is that Veeam does not notify any error in this situation in spite of the SQL backup chain it is supposedly backing up having been broken.

Has anyone else seen similar behaviour? I am hoping that I have missed something rather than Veeam SQL log backups being silently broken in these circumstances.

[ID# 03483271]

[HannesK]

Hello,
thanks for bringing it up. I will investigate with support because I could not reproduce the issue. I started a manual log backup on SQL and the Veeam log shipping broke as expected. Error message:

Collected SQL Server transaction logs do not match any existing database backup: INSTANCE01\datagenerator

I also could not find orphaned log-shipping data on the SQL VM.

Best regards,
Hannes

[jonboy]

I suspect this is environment specific in some way. The server is Windows 2008R2 with SQL 2008R2. All fully patched and running on VMware 6.5 (patched as of February 2019).

I expected to see the error message you mention and have seen that in other cases. But there seems to be a clear case last week where the SQL backup ID changes and Veeam continues without reporting any error.