Job configuration guidance

[kubimike]

Hi everyone, I recently got Nimble storage and I've been enjoying the snapshot / backup abilities it brings. I've run into a situation where I have two jobs protecting one VM. One job is configured with the Nimble as the backup repository runs every 2 hours and another job configured with the Veeam backup repository runs once a day. Both jobs have application awareness turned on, and this is where things get tricky. Because the job that goes to the Veeam backup repository has the SQL log backup running ("Backup Logs periodically every 120 mins) the other job configured with ("Truncate logs prevent logs from growing forever") fails "Cannot truncate Microsoft SQL server transaction logs because job Nimble-SQL is active "

Anyone have any good ideas how to get this to all work ? I guess I could turn off application awareness on the first job. However Im not sure if thats a good idea. Any guidance would be appreciated!

[veremin]

The second job should be configured in "Perform copy only" mode to avoid collisions. Thanks.

[kubimike]

Thanks! Actually because im using the Nimble as my repo in the first job the option to backup the transactions every 120 mins isn't available. Im going to instruct this job to Perform the copy only.

[veremin]

The general idea is to let only one job manage log truncation. With copy only mode, you will achieve exactly that.

Should other help be needed, don't hesitate to let us know.

Thanks.

[Cuebid-Fredrik]

Hi,

This customer has a lot of SQL-servers of different generations, flavor and use. And one of them is apparently very sensitive to transaction log backups during office hours, and interferes with the customers application use.
So I moved it to a new job which only backs it 1/day, as opposed to the former job doing T-logs 1/h, and still is for all the other SQL-servers.
But I can't get it to truncate in the new job:
"2019-06-17 18:21:03 :: Cannot truncate Microsoft SQL server transaction logs because job <prior SQL-job> is active"
Not even a warning. Just a green, nice checkmark even though this is quite severe in my eyes!

Is this a "feature", not beeing able to do concurrent SQL-transaction log jobs? Doesn't sound plausible.
Or is it because there still exists old backups of this server in the old job?
Please help me understand how to get this workin. At least the 3-4 months until customer fix his application/SQL-server issue...

Cheers,
/Fredrik

[veremin]

Hi, Fredrik,

Kindly, see the answers provided above.

Thanks!

[Cuebid-Fredrik]

Hi Vladmir,

I saw that post before I posted, and the big difference is that I don't have two jobs running for the same server. If VBR believes I do, because it WAS part of the first job, then I need to remove that history(how?).
My goal is to have one job for the "normal" SQL-servers, and one for the "special". They must be able to run concurrently, and truncate logs, if they handle different servers, right?

Cheers,
/Fredrik

[Cuebid-Fredrik]

So I tried the theory of maybe the job history from the old, but still active, job could interfere and deleted this servers history from that job.
But I still get the same error.
Please let me know if you have any suggestions on how to solve this.

Cheers,
/Fredrik

[Cuebid-Fredrik]

I have opened case#03624677 for this

[veremin]

It think there are stuck entities in configuration database. The entities make backup server that another job takes care already about SQL transaction log backup. Thus, the error.

Anyway, support team will be able to confirm (or not) my guess, so, keep working with them.

Thanks!

[Cuebid-Fredrik]

Yep, this is my case update:

"This happens because we have some default timeout, which doesn't allow another job to truncate the logs for particular server, if it was processed by another job lately. By default it is 7 days. To change it, you can create the following registry key on the Veeam server:

SqlBackupLogsAgeDaysToSkipTruncate

Type: REG_DWORD
Default value: 7
Path: HKLM\SOFTWARE\Veeam\Veeam Backup & Replication\
Description: Log truncate will be skipped for a VM if there are SQL logs of this VM collected last X day by another existed job

So you can change it to 1, for example - after about an hour, Veeam should detect new key value and proceed with the job; if it won't work, please schedule a maintenance window for the Veeam server to reboot it (for changes to take place)."

My problem went away after the 7 day mark.

Cheers,
/Fredrik

[veremin]

Thanks, Fredrik, for coming back and updating the topic with the resolution found; surely, other community members will appreciate your input!