Replica on the same vCenter but different datastore

[maxxer]

Hi.
One of our customer would like to have a ready to go recovery solution for its VMs in case of SAN failure, and we thought about B&R but we have a doubt.

A little background:
they will deploy a VMWare virtualization cluster with two physical servers and a fc/iscsi connected SAN in the middle. They want to be safe with the storage, so even if the SAN will have all the raid and double controller, they want to have a ready to go backup if it elsewhere.

The idea is to use Backup&Replication to daily (or twice a day) clone the VMs on a middle-range storage, less powerful than the SAN, but capable of running all the virtualized servers.

From what I could read, B&R is intended for cloning VMs on a different host. Can this work in a single vCenter environment? Can I clone a VM from Host1 to Host2 (and/or vice-versa) on a different datastore, so that in case of SAN failure I can run _cloned versions of the VMs?

Given the incremental capabilities, can I expect to be able to run it twice a day, without impacting on users?

Thanks

[Vitaliy S.]

Lorenzo,

Can this work in a single vCenter environment?

Yes, absolutely. You can use replication jobs to create VM copies within the same vCenter Server. The replicated VM will have a new moref ID (vCenter Server identification), but please do NOT power on VM replica while the production VM is still running, otherwise there might be data routing conflicts etc.

Can I clone a VM from Host1 to Host2 (and/or vice-versa) on a different datastore, so that in case of SAN failure I can run _cloned versions of the VMs?

Yes, you can do that.

Given the incremental capabilities, can I expect to be able to run it twice a day, without impacting on users?

Yes, it should be possible as well.

On a side note, how do you protect the vCenter Server? Do you also host is on that very SAN and plan to replicate it to another storage?

Thanks!

[maxxer]

Thank you very much for your replies Vitaliy.

On a side note, how do you protect the vCenter Server? Do you also host is on that very SAN and plan to replicate it to another storage?

Yes, the vCenter is on the same SAN. My colleague is looking into that, do you have suggestions?

Another question: is it possible to estimate timing for the cloning process, both for full and incremental? I know it's kind of a guess... But for example estimating the time for a 1TB Windows 2012 file server (thus with limited file changes during the day), running on a SAN with a FC/iSCSI connection, Gigabit interface to the backup hi-end NAS?

thanks again

[Vitaliy S.]

Yes, the vCenter is on the same SAN. My colleague is looking into that, do you have suggestions?

Yes Please take a look at this topic for more info > replication and failover from vcenter to esx host

is it possible to estimate timing for the cloning process, both for full and incremental? I know it's kind of a guess... But for example estimating the time for a 1TB Windows 2012 file server (thus with limited file changes during the day), running on a SAN with a FC/iSCSI connection, Gigabit interface to the backup hi-end NAS?

It's hard to estimate, but you can safely assume that it will be more or less in-sync with the time required to the backup job (if you're already doing it), and incremental runs will be much quicker than full passes (assuming CBT is going to used).

[maxxer]

It's hard to estimate, but you can safely assume that it will be more or less in-sync with the time required to the backup job (if you're already doing it), and incremental runs will be much quicker than full passes (assuming CBT is going to used).

Not yet, we're still proposing the solution to the customer. We have yet to deploy it.

No way to estimate, then?

thanks

[Vitaliy S.]

There is a way, but data in this report (look at VM Change Rate Estimation report) does not account compression, deduplication and your hardware performance, because all of this is individual to every infrastructure. On the other hand, all our consultants use these reports to analyze and prepare virtual infrastructure for backups, so I would recommend to take a look at them.