-
- Service Provider
- Posts: 453
- Liked: 30 times
- Joined: Dec 28, 2014 11:48 am
- Location: The Netherlands
- Contact:
Expected failover behaviour
Hi,
Is the following failover behaviour as expexted doing a failover of a replica ? :
- planned failover -> source vm is shutted down automatically
- failover -> source vm will stay online
Is the following failover behaviour as expexted doing a failover of a replica ? :
- planned failover -> source vm is shutted down automatically
- failover -> source vm will stay online
-
- Veteran
- Posts: 7328
- Liked: 781 times
- Joined: May 21, 2014 11:03 am
- Full Name: Nikita Shestakov
- Location: Prague
- Contact:
Re: Expected failover behaviour
HI,
Failover is performed in the following way: VBR rolls back the VM replica to the required restore point, powers on the VM replica, temporarily puts replication activities for the original VM on hold (until the VM replica is returned to the Normal state) and as the last step all changes made to the VM replica while it is running in the Failover state are written to the delta file of the snapshot, or restore point, to which you have selected to roll back.
When you start the planned failover, VBR performs the following steps:
1. The failover process triggers the replication job to perform an incremental backup and copy the un-replicated changes to the replica.
2. The VM is powered off.
3. The failover process triggers the replication job to perform another incremental backup run and copy the portion of last-minute changes to the replica. The replica becomes fully synchronized with the source VM.
4. The VM is failed over to its replica.
5. The VM replica is powered on.
Note that it is recommended that you always use Veeam Backup & Replication to perform failover operations. Avoid powering on a replica manually — this may disrupt further replication operations or cause loss of important data.
Thanks.
Failover is performed in the following way: VBR rolls back the VM replica to the required restore point, powers on the VM replica, temporarily puts replication activities for the original VM on hold (until the VM replica is returned to the Normal state) and as the last step all changes made to the VM replica while it is running in the Failover state are written to the delta file of the snapshot, or restore point, to which you have selected to roll back.
When you start the planned failover, VBR performs the following steps:
1. The failover process triggers the replication job to perform an incremental backup and copy the un-replicated changes to the replica.
2. The VM is powered off.
3. The failover process triggers the replication job to perform another incremental backup run and copy the portion of last-minute changes to the replica. The replica becomes fully synchronized with the source VM.
4. The VM is failed over to its replica.
5. The VM replica is powered on.
Note that it is recommended that you always use Veeam Backup & Replication to perform failover operations. Avoid powering on a replica manually — this may disrupt further replication operations or cause loss of important data.
Thanks.
-
- Service Provider
- Posts: 453
- Liked: 30 times
- Joined: Dec 28, 2014 11:48 am
- Location: The Netherlands
- Contact:
Re: Expected failover behaviour
Thanks !
how about the normal failover ? Will the source VM be powered off automatically ?
how about the normal failover ? Will the source VM be powered off automatically ?
-
- Veteran
- Posts: 7328
- Liked: 781 times
- Joined: May 21, 2014 11:03 am
- Full Name: Nikita Shestakov
- Location: Prague
- Contact:
Re: Expected failover behaviour
No, in a case of basic failover source VM will remained powered-on.
Thanks.
Thanks.
-
- Veeam Software
- Posts: 21139
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Expected failover behaviour
Unlike planned failover, ordinary failover operation is meant to be performed in case of disaster, i.e. when the source VM is already down.
-
- Service Provider
- Posts: 35
- Liked: 3 times
- Joined: Sep 26, 2011 2:28 pm
- Full Name: Ken Wilson
- Location: Toronto, Canda
- Contact:
Re: Expected failover behaviour
Do we have a way today to skip step 1 and go right to step 2?Shestakov wrote:HI,
Failover is performed in the following way: VBR rolls back the VM replica to the required restore point, powers on the VM replica, temporarily puts replication activities for the original VM on hold (until the VM replica is returned to the Normal state) and as the last step all changes made to the VM replica while it is running in the Failover state are written to the delta file of the snapshot, or restore point, to which you have selected to roll back.
When you start the planned failover, VBR performs the following steps:
1. The failover process triggers the replication job to perform an incremental backup and copy the un-replicated changes to the replica.
2. The VM is powered off.
3. The failover process triggers the replication job to perform another incremental backup run and copy the portion of last-minute changes to the replica. The replica becomes fully synchronized with the source VM.
4. The VM is failed over to its replica.
5. The VM replica is powered on.
Note that it is recommended that you always use Veeam Backup & Replication to perform failover operations. Avoid powering on a replica manually — this may disrupt further replication operations or cause loss of important data.
Thanks.
The issue I have when moving replicas is the jobs have been running each night and on many of my smaller machines don't have a lot of changed data anyway. Being able to pick to power the machine down right away to avoid the time it takes to do two replica passes would be a great advantage to me since it's a planned failover anyway.
Thanks.
-
- Veteran
- Posts: 7328
- Liked: 781 times
- Joined: May 21, 2014 11:03 am
- Full Name: Nikita Shestakov
- Location: Prague
- Contact:
Re: Expected failover behaviour
Hello Ken,
I believe there is no way to skip the first step. Could you specify what kind of problem do you have with the planned failover starting a replication job twice?
Thanks!
I believe there is no way to skip the first step. Could you specify what kind of problem do you have with the planned failover starting a replication job twice?
Thanks!
-
- Service Provider
- Posts: 35
- Liked: 3 times
- Joined: Sep 26, 2011 2:28 pm
- Full Name: Ken Wilson
- Location: Toronto, Canda
- Contact:
Re: Expected failover behaviour
Hello,
I don't have a problem with it as the failover works great the only issue I have is for smaller machines.
For example we use replica jobs to move machines between data centres. Most of these machines are small and don't have a lot of daily changes. When I have to move 50+ machines I like to use planned fail over to move them in case I have to move them back or something goes wrong.
The issue I have is each vm gets processed twice even when the first job has a small amount of changes. I was hoping or would like the ability to skip the first online pass (an option) so it shuts down the vm first then proceeds to the replica job then brings it online.
This is just to speed up the processing time of getting the virtual machines powered on at the replica site.
I have read over the documentation and tested out the fail over options and don't see a way to get this done. I even shutdown the vm first then ran the planned fail over but it still runs the replication twice.
I realize this is probably by design I just wanted to check (and make a feature request if possible) as I have to move a hundred or so machines next weekend and uptime is not an issue but waiting for all them to finish is [emoji3]
Thanks.
I don't have a problem with it as the failover works great the only issue I have is for smaller machines.
For example we use replica jobs to move machines between data centres. Most of these machines are small and don't have a lot of daily changes. When I have to move 50+ machines I like to use planned fail over to move them in case I have to move them back or something goes wrong.
The issue I have is each vm gets processed twice even when the first job has a small amount of changes. I was hoping or would like the ability to skip the first online pass (an option) so it shuts down the vm first then proceeds to the replica job then brings it online.
This is just to speed up the processing time of getting the virtual machines powered on at the replica site.
I have read over the documentation and tested out the fail over options and don't see a way to get this done. I even shutdown the vm first then ran the planned fail over but it still runs the replication twice.
I realize this is probably by design I just wanted to check (and make a feature request if possible) as I have to move a hundred or so machines next weekend and uptime is not an issue but waiting for all them to finish is [emoji3]
Thanks.
-
- VeeaMVP
- Posts: 6166
- Liked: 1971 times
- Joined: Jul 26, 2009 3:39 pm
- Full Name: Luca Dell'Oca
- Location: Varese, Italy
- Contact:
Re: Expected failover behaviour
I personally think it makes sense since the second replication when the VM is powered down will catch anyway the latest changes, but I guess the first online pass is needed for VSS-aware machines like domain controllers so we can then trigger during restore the AD restore mode. Maybe an option to exclude the online pass for certain machines would help.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
-
- Service Provider
- Posts: 35
- Liked: 3 times
- Joined: Sep 26, 2011 2:28 pm
- Full Name: Ken Wilson
- Location: Toronto, Canda
- Contact:
Re: Expected failover behaviour
Thanks for the reply and I didn't fully think about the DC/VSS apps but that does make sense from a restore preservative so I get why it's done by default. Having an option to move smaller / non VSS machines without the double pass would be nice to speed things up when using a replica to move a vm but at least I know now it's be design for a good reason.
Thanks!
Thanks!
Who is online
Users browsing this forum: Semrush [Bot] and 33 guests