Deleted DB causes Transaction Log errors AFTER next backup

[fcoa]

In Veeam 9.0 U2, I encountered the following scenario that I thought was goofy. Wanted to share for the good of the order, and Veeam's future consideration. The fix to this issue is to disable the parent Veeam backup job, wait for the transaction log backup job to stop and then re-enable the parent job.

Here's the scenario in question for an active transaction log backup (TLB) job:

* Delete a SQL database that runs SIMPLE recovery model, and thus, is reported as "Excluded" by the TLB

* The TLB job continues without issue and continues to report "Success" on this deleted database

(NOTES: I get why there's no error at this juncture happening, but this raises the point that perhaps labeling inaction / ignored objects a "success" is not the best option. I haven't checked what happens to "Protected" DBs in this scenario, but assume they begin to fail immediately.)

* Now, as soon as the next parent job backup initiates (i.e. VM-level job), a new TLB job is spawned

* At this juncture, the new TLB job still doesn't realize that the SQL DB has been deleted --possibly because the SQL server has not yet been backed up again by the parent job-- and the TLB still reports "success" on this deleted database.

* Finally, on all TLB's that occur after the SQL server is backed up begin to report errors with the formerly deleted DB.

You now either need to be subjected to error alerts for all TLB occurrences until the next parent job, or you need to temporarily disable the parent job as mentioned above.

[Vitaliy S.]

Hi Eric,

Hmm... just to make sure I understand the scenario - with a simple recovery model set, why would you like to see job failure for the transaction log backup job which only cares about the logs?

P.S. thanks for the detailed description, I will pass this to our QC team.

Thanks!

[fcoa]

That's a great question, and I'm wondering the same thing.

It does seem the TLB process has a gap here. Rather than restart the TLB at the start of the VM backup job, perhaps it should wait to restart until after the SQL server VM backs up?