-
- Veteran
- Posts: 600
- Liked: 66 times
- Joined: Jun 13, 2013 10:08 am
- Full Name: Paul Kelly
- Contact:
Feature Request: Quick Replica (from copy)
Unless I'm missing the feature somewhere, it would be quite useful to extend the principle of the "Quick Backup" to be able to do a "Quick Replica from Backup".
So in a scenario where you're replicating from backup copies, if you wanted to do a quick failover of a single VM, it's difficult to do so without kicking off full jobs (and everything that entails).
So, if I can do a Quick Backup, it would be useful to be able to then do a "Quick Copy" to copy JUST that VM to the remote site, and then do a "Quick Replica" from that copy.
Hopefully this makes sense? If anyone has any better/cleaner ways of achieving the same result then I'd love to hear it
Note: I've abandoned any use of "Planned Failover" as it's just so ridiculously slow doing anything, I've no idea what it's thinking! :-/ I already reported previously that it needlessly does a second replication even if you power off the original VM before initiating a planned failover.
So in a scenario where you're replicating from backup copies, if you wanted to do a quick failover of a single VM, it's difficult to do so without kicking off full jobs (and everything that entails).
So, if I can do a Quick Backup, it would be useful to be able to then do a "Quick Copy" to copy JUST that VM to the remote site, and then do a "Quick Replica" from that copy.
Hopefully this makes sense? If anyone has any better/cleaner ways of achieving the same result then I'd love to hear it
Note: I've abandoned any use of "Planned Failover" as it's just so ridiculously slow doing anything, I've no idea what it's thinking! :-/ I already reported previously that it needlessly does a second replication even if you power off the original VM before initiating a planned failover.
-
- Veteran
- Posts: 7328
- Liked: 781 times
- Joined: May 21, 2014 11:03 am
- Full Name: Nikita Shestakov
- Location: Prague
- Contact:
Re: Feature Request: Quick Replica (from copy)
Hello Paul, could you describe the scenario when you need this feature?
In a case the production VM is failed you can perform instant VM recovery or full VM restore.
Thanks!
In a case the production VM is failed you can perform instant VM recovery or full VM restore.
Thanks!
-
- Veteran
- Posts: 600
- Liked: 66 times
- Joined: Jun 13, 2013 10:08 am
- Full Name: Paul Kelly
- Contact:
Re: Feature Request: Quick Replica (from copy)
To be honest I guess I'm talking about a scenario where I *should* be able to use a "Planned failover", but I've found Planned Failover process almost useless as it simply takes too long, and for no apparent reason!
It's the fact that it's so unpredictable when the actual failover steps take place (i.e. the point when the VM goes offline for the final replica).
I've even tested with a straightforward replica job (i.e. not replicating from backup copy) and then doing a manual replication about 30 mins before desired planned failover start time to ensure that I've minimised underlying disk changes, but still, when doing the Planned failover, it always seems to take a minimum of 10 mins to think about it, then at least 10 mins for the first replica, then the VM is powered down, another 10 mins to think about it, then another 10 mins to replicate the final changes, then some more time (I forget how long at this point) to process things prior to powering up the VM at the destination.
So, we're talking probably at least 40mins+ *per VM* (in my experience as the few times I've tested it's always seemed a serial task for multiple VMs so 3 VMs could easily take 2hrs+?)
So, because of this I wanted to do a "manual planned failover" of just 2 VMs, but both of those VMs are in:
A large backup job
A large copy job
A large replica job
So last night I:
Manually about an hour before did a quick backup of the 2 VMs in question (in this instance they're pretty static VMs so no need for up-to-the-second changes to be replicated)
Manually synced the backup copy job which would then (after these VMs) sit there with a load of "pending" copies
Manually started the replica job which did these 2 VMs but obviously couldn't do all the others as they were up to date
Manually started a "Failover Now"
It all went fine doing it this way & I had both VMs up & running in destination within <15 mins, but as I've said, having tried it 3 or 4 times now, I *really* dislike the Planned Failover process & feel like it is about the most inefficient/slowest process in Veeams otherwise awesome arsenal...
It's the fact that it's so unpredictable when the actual failover steps take place (i.e. the point when the VM goes offline for the final replica).
I've even tested with a straightforward replica job (i.e. not replicating from backup copy) and then doing a manual replication about 30 mins before desired planned failover start time to ensure that I've minimised underlying disk changes, but still, when doing the Planned failover, it always seems to take a minimum of 10 mins to think about it, then at least 10 mins for the first replica, then the VM is powered down, another 10 mins to think about it, then another 10 mins to replicate the final changes, then some more time (I forget how long at this point) to process things prior to powering up the VM at the destination.
So, we're talking probably at least 40mins+ *per VM* (in my experience as the few times I've tested it's always seemed a serial task for multiple VMs so 3 VMs could easily take 2hrs+?)
So, because of this I wanted to do a "manual planned failover" of just 2 VMs, but both of those VMs are in:
A large backup job
A large copy job
A large replica job
So last night I:
Manually about an hour before did a quick backup of the 2 VMs in question (in this instance they're pretty static VMs so no need for up-to-the-second changes to be replicated)
Manually synced the backup copy job which would then (after these VMs) sit there with a load of "pending" copies
Manually started the replica job which did these 2 VMs but obviously couldn't do all the others as they were up to date
Manually started a "Failover Now"
It all went fine doing it this way & I had both VMs up & running in destination within <15 mins, but as I've said, having tried it 3 or 4 times now, I *really* dislike the Planned Failover process & feel like it is about the most inefficient/slowest process in Veeams otherwise awesome arsenal...
-
- Novice
- Posts: 8
- Liked: 2 times
- Joined: Mar 17, 2016 11:56 pm
- Full Name: Matt Brown
- Contact:
Re: Feature Request: Quick Replica (from copy)
I have the same observations about Planned Failover. The processing time seems abnormally long and this makes the process restrictive due to unpredictable timing of the source VM shutdown.
I use the same process as pkelly_sts described. Run a live replication job manually about an hour before maintenance window starts. Shut down source VMs at start of maint window. Run replication job with VMs shut down. Trigger "Failover Now" task for relevant VMs. I've found this process to be much more consistent and predictable than Planned Failover (I moved 150 VMs to a new datacenter using this method last year).
I use the same process as pkelly_sts described. Run a live replication job manually about an hour before maintenance window starts. Shut down source VMs at start of maint window. Run replication job with VMs shut down. Trigger "Failover Now" task for relevant VMs. I've found this process to be much more consistent and predictable than Planned Failover (I moved 150 VMs to a new datacenter using this method last year).
-
- Veteran
- Posts: 600
- Liked: 66 times
- Joined: Jun 13, 2013 10:08 am
- Full Name: Paul Kelly
- Contact:
Re: Feature Request: Quick Replica (from copy)
I'm glad it's not just me!
Anyone else find planned fail-over way too slow?
Anyone else find planned fail-over way too slow?
-
- Veteran
- Posts: 7328
- Liked: 781 times
- Joined: May 21, 2014 11:03 am
- Full Name: Nikita Shestakov
- Location: Prague
- Contact:
Re: Feature Request: Quick Replica (from copy)
What if planned failover showed better performance, would it be sufficient?
Your original request was to make a quick replica from backup and that`s something different.
Your original request was to make a quick replica from backup and that`s something different.
-
- Veteran
- Posts: 600
- Liked: 66 times
- Joined: Jun 13, 2013 10:08 am
- Full Name: Paul Kelly
- Contact:
Re: Feature Request: Quick Replica (from copy)
If planned failover showed (significanty) better performance then absolutely it's what I'd use.
The reason my original request was for a quick replica from backup is because the only other alternative is planned failover, so it's either planned failover or manual, no other choice that I'm aware of?
The reason my original request was for a quick replica from backup is because the only other alternative is planned failover, so it's either planned failover or manual, no other choice that I'm aware of?
-
- Veteran
- Posts: 7328
- Liked: 781 times
- Joined: May 21, 2014 11:03 am
- Full Name: Nikita Shestakov
- Location: Prague
- Contact:
Re: Feature Request: Quick Replica (from copy)
I`ll discuss the planned failover performance with R&D team due to your request.
Thanks!
Thanks!
-
- Enthusiast
- Posts: 27
- Liked: 11 times
- Joined: Apr 21, 2015 12:10 pm
- Contact:
Re: Feature Request: Quick Replica (from copy)
+1 for a Quick Replica feature. We are using Veeam replication jobs to do a migration from one vCenter to another (best option for reasons I won't go into). There are 84 jobs and some have up to 30 VMs in the job, because it wasn't viable to create a single job for every VM due to scheduling and loss of dedupe efficiency etc. We found the planned failover feature didn't meet our needs for various reasons. However, we now need to move some VMs over that are part of a larger job, but not some others in the job (sometimes 1 out of 30 VMs). This leaves us having to run the replication job for all for 30 VMs when we only really need to replicate a single VM. This can cause a huge time delay to migrate a single VM. In this instance a "Quick Replica" feature like the "Quick Backup" feature that could replicate a single VM from a larger replication job would be ideal and presumably wouldn't require too much work as the functionality is already there from the planned failover and quick backups features.
-
- Veteran
- Posts: 487
- Liked: 106 times
- Joined: Dec 08, 2014 2:58 pm
- Full Name: Steve Krause
- Contact:
Re: Feature Request: Quick Replica (from copy)
I am in a situation right now where a quick replica feature that would allow me to hit one VM in a job with multiple VMs would be mighty nifty.
+1 for the FR.
+1 for the FR.
Steve Krause
Veeam Certified Architect
Veeam Certified Architect
-
- Service Provider
- Posts: 248
- Liked: 28 times
- Joined: Dec 14, 2015 8:20 pm
- Full Name: Mehmet Istanbullu
- Location: Türkiye
- Contact:
[MERGED] Feature request - Quick replication like quick backup
Hi everyone
Many customer use one backup and one replication job with PerVM backup. If we want to backup one VM, we just use quick backup option. But i couldn't see quick replication option like quick backup feature.
Right now if we want to use this option we clear all vm except want in replication job. And start replication cycle. Then add again But all exclusion and application aware settings will be removed.
Could you add this feature upcoming releases?
Many customer use one backup and one replication job with PerVM backup. If we want to backup one VM, we just use quick backup option. But i couldn't see quick replication option like quick backup feature.
Right now if we want to use this option we clear all vm except want in replication job. And start replication cycle. Then add again But all exclusion and application aware settings will be removed.
Could you add this feature upcoming releases?
VMCA v12
-
- Veeam Software
- Posts: 712
- Liked: 168 times
- Joined: Nov 30, 2010 3:19 pm
- Full Name: Rick Vanover
- Location: Columbus, Ohio USA
- Contact:
Re: Feature request - Quick replication like quick backup
That's cool. I wanted the same for a storage snapshot (namely to automatically delete it after specified days).
Who is online
Users browsing this forum: Stabz and 48 guests