Proctection of failed-over VM in Hyper V environment

[manfri]

While, with replica, it' quite clear hov to recover from disaster, what happen next is not so clear.
Right after the disaster strike and the recovery is done, the question is how we can restore rto/rpo objective and what we have to plan for this in time and resource utilization.

In Layman term the question is: What happen to the VM backup when a replicated VM is failed over on another Hyper-V cluster?

We have to restart the backup creating new jobs (and have adequate storage in the backup repository) or it's smart enough to detect this and protect automatically the failed-over machine, hopefully without have to utilizeadditional storage (Even in my wildest dream i assume that the first job is not CBT enabled )))

Best regards

[v.eremin]

What happen to the VM backup when a replicated VM is failed over on another Hyper-V cluster?

Backup jobs will fail, since it won't be able to reach source VMs, and you will need to re-configure backups job, starting everything anew (full backup, no initial cbt, etc.). Thanks.

[manfri]

So, when

Vm FILESERVER1 with backup AND replica cluster PRODUCTION vs CLUSTER DISASTERRECOVERY

vm FILESERVER1 is in cluster PRODUCTION, backup job with name FILESERVER1-PRODUCTION run as usual

Disaster strike, and the vm FILESERVER1 restart from replica in cluster DISASTERRECOVERY, we must go with another backup job (that for example we name FILESERVER1-DISASTERRECOVERY ) and restart

At this point we have used, in the backup repository store, the space for a new full backup.

The cluster PRODUCTION is now ok and we replicate the vm, and failover to cluster PRODUCTION so the vm FILESERVER1 is running in clusterPRODUCTION, and the original backup job FILESERVER1-PRODUCTION restart from where it left, with a job without CBT but otherwise normally, so we do not have a third allocation of space in backup repository.

I've understood correctly?

[manfri]

In this thread (it talks about Hyperv Hosts, not cluster) it seem that scvmm somewhat helps reaching ths source VM

but it' unclear if it's applicable only in scvmm managed vm migration or also in replica failover/failback.

In any case this would be a feature with an appeal...

[v.eremin]

Disaster strike, and the vm FILESERVER1 restart from replica in cluster DISASTERRECOVERY, we must go with another backup job (that for example we name FILESERVER1-DISASTERRECOVERY ) and restart

You can still utilize existing job, instead of creating new one. You will need to re-add VMs (to backup replica VMs, not production ones), though. Once everything is back to life, you will then re-add VMs again (to backup production VMs, not replica ones).

In this thread (it talks about Hyperv Hosts, not cluster) it seem that scvmm somewhat helps reaching ths source VM

That topic talks about live migration which is completely different from replication feature.

Thanks.