Comprehensive data protection for all workloads
Post Reply
glennsantacruz
Enthusiast
Posts: 61
Liked: 10 times
Joined: Mar 01, 2010 5:57 pm
Full Name: Glenn Santa Cruz
Contact:

Replication jobs - single vs. multiple VMs

Post by glennsantacruz »

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?
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Replication jobs - single vs. multiple VMs

Post by Gostev »

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.
Post Reply

Who is online

Users browsing this forum: olafurh and 67 guests