setting up replication

[ejenner]

Hi guys,

I've got all my Hyper-V VMs backed up as standard backups but we've recently lost some redundancy as a consequence of hardware failure in part of our production environment where the VMs are hosted.

For the system in mind we have a brand new environment which is in a pre-production state. Over the course of the next 12 months we had planned to migrate to that new platform but in the meantime I'd like to setup Veeam replication so we can failover to that new environment.

Is it easy to replicate all the VMs on that new environment so we can failover to them if our production environment suffers an additional hardware fault?

What are the basic steps.

I guess I'm thinking most about the networking part of it... would a Veeam server become some sort of bottleneck rerouting traffic away from the original environment to the replicas and if that's what could happen should I plan ahead to avoid that problem?

[foggy]

You can set up replication and perform a planned failover with re-IP when the need comes. Traffic will not be routed via Veeam B&R after the failover is done.

[PetrM]

Hello,

One more suggestion is to deploy Veeam server on DR site so that you are able to orchestrate failover and failback operations even if the primary site is completely down. The infrastructure on the primary site can be managed with the same backup server anyway.

Thanks!

[ejenner]

It'll be on the same site so unless necessary to add another server then the plan is to manage this from the existing one.

If I want the VMs to be stored on a new SAN and not on the backup repository does that mean I'll have to create new backups and use the SAN as a repository? i.e. when I do a failover I want the performance of the SAN and not the performance of the backup repository.

[foggy]

Not sure I understand the question. Are you asking about seeding the replicas from the backup files residing on the SAN where they are supposed to run?

[ejenner]

What I'm saying is that at present the backup files of the VMs I wish to set up replication for are sitting on a backup repository. SATA spinning disk.

If I want to configure the replication to give us some serious alternative to our production environment I don't think SATA spinning disks of the backup repository are going to be performant enough to deliver services at the level expected by end users.

Therefore, my replicas will have to run from a new SAN which is currently empty. In order to have the replicas running from the new SAN I am guessing my best route to getting this working is to leave the existing backups as they are and configure some brand new replication jobs which use the SAN as a repository. Then if I failover to the replicas they will perform as well (if not better) than the existing VMs on the older (currently) compromised hardware.

[foggy]

Do you mean you're going to use replication from backup functionality? Otherwise I still don't understand why do you need backups on the same SAN - replication jobs are independent of backups and don't use the repository (apart from the metadata).

[ejenner]

I'm not that familiar with replication as this will be my first implementation of it. I guess from what you're saying I'm better off creating new jobs which are purely for this new requirement, set up as replication jobs from the outset and using the SAN as the storage? Do I add the SAN as a repository?

[foggy]

I recommend you reviewing the replication basics to better understand what it is and how it works. Basically replica VM is a complete copy of a VM, which is stored on the target Hyper-V host and is ready to start any time you need it. Backup repository is involved in the process as a storage for replica metadata only. So you need to create replication jobs, specify source and target hosts and you're good to go. Provided your SAN is connected to the target Hyper-V host, you will be able to select the datastore residing there as a destination for your replicas.

[ejenner]

I've set up a replication job which is running now. I understand from what I've read above and looking at the interface on the B&R console that you replicate between two clusters. So I've set all that up and it's running the job. It does look a lot like after copying all the data that the tasks are all going to fail. The first two VMs which have finished replicating have ended with a failed status.

I've got: 17/09/2020 13:50:42 :: Failed to process replication task Error: Failed to create VM (ID: fee98ad3-237e-4594-834a-b7ea3c8dc7cd) snapshot. No Decoupled Providers Attached Error code: 0x80041002
Failed to get object '\\destination cluster node\root\virtualization\v2:Msvm_ConcreteJob.InstanceID="76D4B739-D50D-46BE-81CB-E2A720152FCF"'.
Failed to get wmi object by path: '\\destination cluster node\root\virtualization\v2:Msvm_ConcreteJob.InstanceID="76D4B739-D50D-46BE-81CB-E2A720152FCF"'.

And:

17/09/2020 13:50:12 :: Failed to process replication task Error: Failed to call RPC function 'FcWriteFileEx': The system cannot find the path specified. Failed to open file [C:\ClusterStorage\Volume1\Replicas\f8dcae078aaf4ab783774c4ce042ebc9\Virtual Machines\d0f6d521-fbf3-4e7e-8537-81fc37b5b7c4.xml].

[foggy]

That is something that should be addressed to our support team directly.

[ejenner]

Only the first two failed with the above errors. The rest finished with warning:

17/09/2020 14:15:23 :: Failed to create change tracking time stamp for virtual disk file C:\ClusterStorage\Volume1\name of VM\name of VM_disk_1.vhdx

[foggy]

You can find some hints regarding this warning in this existing thread.

[ejenner]

Pretty sure I resolved the errors by turning off CBT but with it being last week I've forgotten exactly what I did.

Got it all working ok after all. We couldn't use the RE-IP or network remapping features as they didn't make things work with our networking setup. But as we're replicating to a test environment it was easy enough to change the settings of the destination system to make it compatible with production.

[foggy]

If disabling CBT was an option... ok. Just thought you'd want to find out the real cause of the issue. Glad it's sorted though, thank for the update.