Two Backup Copy Jobs – How does VRO decide

Hi everyone,

I am delighted to present my first blog post and my first contribution to the Veeam community today. I would be very grateful for any feedback 😊

When working with Veeam Recovery Orchestrator (VRO), you might occasionally run into situations where the system makes decisions that aren’t immediately intuitive. Recently, a partner approached us with a scenario that raised exactly that kind of question:

How does VRO choose which backup copy to use when multiple copies exist?

Let’s walk through the use case, the unexpected behavior, and what we learned from digging into it.

The Scenario

In this environment, VRO is running at the disaster recovery site and orchestrating a vSphere-to-vSphere restore plan. The plan uses the following steps:

1. A backup-to-disk job writes backups to a local backup repository.

2. Immediately afterward, two backup copy jobs run in parallel to copy the backup data to two additional repositories — let’s call them Repository A and Repository B.

3. The restore plan is configured to use backup copies, as described in the VRO documentation.

(The image is a highly simplified representation.)

The goal is to use the restore points created by the backup copy jobs as the source for the recovery process. But something strange happens: VRO correctly uses a backup copy restore point, but it always selects the restore point stored on Repository A — even though the customer wants VRO to use the copies on Repository B.

So the question is:

How does VRO decide which backup copy to use when multiple equally valid copies exist?

Testing the Behavior

To better understand the selection logic, I replicated the scenario in a lab:

• Two backup copy jobs were created.

• One copy job ran first, followed by the second job so that the second job would create the “most recent” backup chain.

• Initially, this worked as expected: the repository with the newer chain (Repository A in this test) was used.

• After reversing the job order, I expected VRO to pick Repository B instead — but surprisingly, VRO still selected Repository A.

   

This suggests that VRO does not make its decision solely based on job execution order or chain timestamps.

So How Does VRO Choose?

That's why I asked Alec King directly:

VRO does not consider the timestamp of the backup copy job. It selects based on the timestamp of the restore point itself.

This is the key detail. All backup copies created from the same source backup job share the same restore point timestamp, even if they were copied at different times. Because of that, when multiple identical restore points exist across several repositories, VRO sees them as equally valid, and its selection may not reflect the user’s preference. In other words, the system has no inherent logic today to prioritize Repository A over Repository B or vice versa.

This explains the “strange behavior” — VRO isn’t doing anything wrong; it simply has no mechanism yet to choose between duplicate restore points from different locations.

The Good News: Repository Selection Is Coming

Alec also shared that repository selection logic already exists for Azure recovery locations, but not yet for VMware-to-VMware scenarios.

https://helpcenter.veeam.com/docs/vro/userguide/cloud_location_backup_servers.html?ver=13

The Veeam team is actively working on adding repository selection for VMware environments in an upcoming VRO release. While not fully confirmed, it’s on their roadmap and will directly address this use case.

Is There a Workaround?

Unfortunately, no reliable workaround exists today.

Copying the backup again (e.g., a backup copy of a backup copy) won’t help because:

VRO still checks the restore point timestamp — and that remains identical across all copies.

The only long-term fix will be the upcoming repository selection feature.

Conclusion

If you’re running multiple backup copy jobs in VRO and relying on the “Use backup copies” option, be aware that:

• VRO selects restore points based on restore point timestamp, not on backup copy job details.

• Multiple identical restore points across repositories are considered equal.

• You currently cannot force VRO to prefer a specific repository.

• Veeam is actively working to add repository selection for VMware restore plans in a future release.

   

Once available, this enhancement will give users precise control and eliminate the ambiguity seen in scenarios like this.

Thanks to ​@AlecKing  for your support!

The original post can be found on my blog: https://www.marvinski.com/post/veeam-recovery-orchestrator-two-backup-copy-jobs-how-does-vro-decide