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
-
- Influencer
- Posts: 12
- Liked: 1 time
- Joined: Oct 11, 2017 7:46 am
- Full Name: Marco Manfredini
- Contact:
-
- Product Manager
- Posts: 20415
- Liked: 2302 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Proctection of failed-over VM in Hyper V environment
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.What happen to the VM backup when a replicated VM is failed over on another Hyper-V cluster?
-
- Influencer
- Posts: 12
- Liked: 1 time
- Joined: Oct 11, 2017 7:46 am
- Full Name: Marco Manfredini
- Contact:
Re: Proctection of failed-over VM in Hyper V environment
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?
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?
-
- Influencer
- Posts: 12
- Liked: 1 time
- Joined: Oct 11, 2017 7:46 am
- Full Name: Marco Manfredini
- Contact:
Re: Proctection of failed-over VM in Hyper V environment
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...
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...
-
- Product Manager
- Posts: 20415
- Liked: 2302 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Proctection of failed-over VM in Hyper V environment
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).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
That topic talks about live migration which is completely different from replication feature.In this thread (it talks about Hyperv Hosts, not cluster) it seem that scvmm somewhat helps reaching ths source VM
Thanks.
Who is online
Users browsing this forum: Bing [Bot], Google [Bot] and 63 guests