Best way to seed replication?

[zoltank]

My company has offices in two separate locations (HQ and DC) separate by several miles. They are connected by a 100mbit EPL circuit. I have a ESXi5.5 environment at each location along with a Veeam Enterprise Plus server. The HQ location houses our main server room.

We've decided to leverage the situation for our DR solution and replicate our business critical VMs from HQ to the DC location. To that end I have I have 3TB of data that I want to replicate. For testing purposes I seeded DC with a 50GB VM from a backup on an external hard drive that I restored in the DC ESXi host and mapped the original VM to. I then setup WAN accelerators at each end, and created a replication job. However, the digest calculation rate is only about 50GB/hour, at which rate it'll take me 60 hours to calculate digests for all my data.

Is there a better way for me to seed the replicas at the DC location, or do I just need to suck it up and wait 60 hours for the digest calculation?

[foggy]

Basically, when you do replica mapping/seeding, replication jobs has to calculate the VM digests to detect what blocks have changed after seeding and need to be transferred. Do you have replica metadata stored on the repository that is in HQ location? Do you have proxy servers on both sides?

[csinetops]

I did the same between our two offices, one in MN and one in TX. I had ~75 VM's and 12TB worth of data to seed down to TX. I created the seed backups on a NAS and shipped that down there. Then I copied the jobs to the target repositories and mapped the jobs accordingly. It took about a week and a half for everything to get back in sync. I did have 2 WAN accelerators on both sides as well as multiple jobs running at once, we have a 100mbit between sites. I think you'll just have to wait it out. My jobs have been running smooth for 7-8 months now.

[zoltank]

Do you have replica metadata stored on the repository that is in HQ location?

I don't know. How can I tell?

Do you have proxy servers on both sides?

I just realized I never added the destination proxy to the source Veeam server.

Should I be using the WAN Accelerators with a 100mbit link?

[zoltank]

I did the same between our two offices, one in MN and one in TX. I had ~75 VM's and 12TB worth of data to seed down to TX. I created the seed backups on a NAS and shipped that down there. Then I copied the jobs to the target repositories and mapped the jobs accordingly. It took about a week and a half for everything to get back in sync. I did have 2 WAN accelerators on both sides as well as multiple jobs running at once, we have a 100mbit between sites. I think you'll just have to wait it out. My jobs have been running smooth for 7-8 months now.

Normally that's what I'd do and I'd just wait it out, but I'm not trilled about having snapshots on our file servers for that long.

[csinetops]

I don't believe ( someone from Veeam correct me if i'm wrong) the snapshot stays open for the digest calc. The snap is taken and backup file updated. Then I believe the digest is taken from that backup vs the replica VM and the replica image is updated.

[Vitaliy S.]

I don't know. How can I tell?

Please take a look at this job settings and check where the specified repository is located.

I don't believe ( someone from Veeam correct me if i'm wrong) the snapshot stays open for the digest calc. The snap is taken and backup file updated. Then I believe the digest is taken from that backup vs the replica VM and the replica image is updated.

This is happens only when you're replicating from backups. In the OP's case replica is already mapped to the restored VM, so no backup file is used at all. Seeding a replication job basically means that you need to restore a VM from that backup first and then use the restored VM as a target for the replication job.

Digest calculation is performed as a part of the replication job run (after VM snapshot is taken). Keep in mind that digest calculation process searches for differences between source and target VMs. So in order to preserve VMs state and find blocks that have to be transferred, the VM snapshot has to be taken.

[zoltank]

Related question.

Since I already have a Veeam server installed at the DC site, should I just use that? Or would it be better to create a new VM at that site to be the proxy and WAN accelerator?

[foggy]

You can use existing server as well, provided both of them are at the same patch level. And keep in mind the load aspect, since one instance will not be aware of the tasks assigned by another.

[zoltank]

New questions then:

My backups at HQ run nightly. If I use the backup as the source and the initial replication job isn't finished yet when we hit the backup job's scheduled time to run, what happens?

Can I perform the initial replication using my backup job as the source, and then move it to the live VM for subsequent replications?

Should the replica metadata be stored in the HQ repository or the DC repository?

[foggy]

Replication job will be interrupted to allow the backup to be performed.

Yes, you can. However to avoid jobs overlapping, you'd better do the opposite: use the original VM for initial replication cycle and then switch to backup as source.

[zoltank]

Will the replication job pick back up once the backup job is done?

Should the replica metadata be stored in the HQ repository or the DC repository?

[foggy]

Replication job will be triggered according to its schedule.

Replica metadata should be stored closer to the source.

[starnetlou]

The best bet is to do it as geographically close as possible, them move it to the remote, especially if the backups are large and the wan is small..