Looking for advice on setting up replication jobs, and I'm hoping you can share your experiences. I'm really debating aggregate jobs versus single jobs and trying to weigh the pros/cons of each. Firstly, we're talking about replication to a DR facility across a WAN with a relatively small pipe ( 10Mbps ); complete refresh from scratch (reseed) is painful due to the time involved -- we would like to avoid reseeds as much as possible.
For illustration, suppose we have the following recovery point objectives (RPO):
4 hours for 3 VMs: ( VM4-A, VM4-B, VM4-C )
2 hours for 3 VMs: ( VM2-A, VM2-B, VM2-C )
10 hours for 2 VMs: ( VM10-A, VM10-B )
I can see at least three strategies:
Strategy 1 : define one job per RPO, placing appropriate VMs directly into the corresponding job. By "directly" I mean that each VM is selected within the replication job creation wizard. This would result in three replication jobs ( rep4, rep2, rep10 )
Strategy 2 : define one job per RPO, define a vCenter folder for each RPO, add the corresponding folder to each job, then move VMs into each folder. This has the advantage (presumably) of allowing for flexible RPO changes -- if I need VM4-A to suddenly have an RPO of 2 hours, I just move it to another vCenter folder.
Strategy 3 : define one job per VM
For both Strategies 1 and 2, does Veeam allow for movement of a VM into another job (either via direct selection or via folder manipulation) and *keep* the state of the replica? Or would we be required to reseed? Any pros/cons to the above? Maybe even other strategies that we've not considered?
Glenn, moving VMs between jobs while keeping the state of the replica is not supported at this time - this would require reseed.
Given the specifics of your scenario (off-site replication via slow link), and the number of VMs to replicate, I would go with one job per VM, as this gives you more granular control.