Immediate Copy job failure due to Backup job merge

[Mark]

I have a setup with two jobs.
One does a backup of the VMware VMs.
This is set for per VM backup, 30 restore points, daily run, forever incremental.
The second job is a Backup Copy job to send the backup offsite.
This is set for immediate copy.

We have a problem where the backup job runs, creates the backup file, the copy job starts sending the backup offiste, the backup job completes and start to run merges to maintain the restore points.
The Backup Copy Job will fail on 2 random VMs because the files are locked, by the merge.
A later rerun of the Copy job also results in warnings because the other "successful" VMs had already copied and there's no new restore points.

Is there a way for the Copy job to understand that the Backup job is currently running a merge and to skip those locked files/VMs and come back and wait, or only start the copy when the merge has finished?
My current workaround is the set schedule exclusions in the Copy job to give the Backup job time to finish.

[PetrM]

Hi Mark,

I'm not sure that this is the expected behavior, backup copy job should wait for merge completion. Do you have a support case number so that we can double check that in your case files were locked by running merge and not by another process?

Thanks!

[Mark]

Logged.
Support ticket# 04692724

[Mark]

I heard back from Support.
Apparently doing a per-VM backup and an Immediate Copy job fails "by design".
The only workaround being to block the Immediate copy with schedule changes or use Periodic Copy.
Since Veeam knows that it is the cause of the lock why can't this be handled better? Like delay the Copy or the Merge of that particular VM depending on which task will generate the lock.

[PetrM]

Hello,

Please let me double check some details, I will update the topic as soon as I have more information.

Thanks!

[PetrM]

Hello,

@Mark looks like a more detailed analysis is required, I requested to escalate the support case.

Thanks!

[FrancWest]

Hi,

case # 04717793. I receive multiple failure emails about immediate copy jobs. The error reported is:

Source restore point is locked by another job. Task was not processed in the current session.

Why isn't immediate copy just waiting to start copying as soon as the source is unlocked? Now I get numerous failure mails which I have to investigate (all success mails go to a different folder using a rule), later on it copies the backups successfully. The lock is caused by the backup merge or health check.

Other jobs like the replication jobs just wait until the restore point is released ('restore point found but is locked' message). Failing the immediate copy job is unnecessary, since it knows the source is locked and thus can wait.

Regards,
Franc.

[PetrM]

Hi Franc,

I've moved your post into the existing topic. The similar case is being researched by our senior support engineers and RnD. I'll ask our support team to check your case as well.

Thanks!

[FrancWest]

Ok thanks, I also got an answer ‘by design’ and the case was closed.

[PetrM]

I'll update the topic as soon as I have more information.

Thanks!

[PetrM]

Hello,

The issue is still being researched, stay tuned.

Thanks!

[restore-helper]

Hello

is this problem with V10 or V11?
I had a simular case with NAS Backup and backup copy kicking in to early. I have bin told that the behaviour might be fixed in v11.

[PetrM]

Hello,

At first sight it looks like you've faced a different issue, nevertheless it's worth sharing the support case ID with us.

Thanks!

[restore-helper]

Hello,
case was 04440339.
Perhaps different in the underlying problem. But from customer point of view the same, backup copy Job starting to soon.

Never the less my question remains wether the problem with the immediate copy job exists in V10 and V11 or only in V11.

[PetrM]

Hello,

It's hard to say without the clear understanding of the root cause. The issue is still under investigation and I suggest to keep working on it with our support team.

Thanks!

[PetrM]

Hello,

The case is still under investigation, I'll update the topic as soon as I have some details.

Thanks!

[PetrM]

Hello,

Our QA could not reproduce the problem on the latest cumulative patch for the version 11. I recommend to check if the issue persists on the latest patch.

Thanks!

[FrancWest]

Unfortunately we are still at V10, since our service provider hasn’t moved to v11 yet.