How to perform Replication Failover

[Music] in this video we're going to be discussing replication failover in the veeam interface it's very easy to perform a replication failover because the steps are simply laid out and easy to follow but the logic behind those steps can sometimes be challenging for people to understand we're going to use a light board and do a demonstration that's more like a flow chart to help you better understand how this process works and really better understand what can happen when you select a certain process let's take a look at the demonstration today we're going to look at replication failover as it pertains to veeam now what we're going to do is really cover the logical of this instead of getting into a lot of the details of say the delta files or snapshots because knowing the logic is really going to help you build a strong foundation to be able to answer a lot of other questions so over here we're going to talk about prod which is the original location that's where the original virtual machine resides dr is where the replica is going to reside or where we replicated a copy of that virtual machine now for this discussion this replica is going to be off-site okay so a true dr not something that could be on-prem and that'll make sense in a moment as we go through our examples so let's start here by identifying prod now from here we have had an event where we have realized that we need to fail over to our dr site okay there's going to be different ideas that we can use but for the first example let's just cover generally failover so at this point what we have done is we have failed over to the dr site now with this failover process we are now running over on this dr site and the original has been shut down the next option that we have which is very important to understand and think about is if prod in most cases is no longer available is not an option anymore okay it's down the network is down the entire site's down whatever it is that's where we would make this first possible decision and that first decision would be a permanent failover now the reason why it's so important to define this is because once you do a permanent failover you have broken the replication for that job for that virtual machine because again in the name it says permanent we want it to stay over here at the dr site once that is discussed some people might look at this and say well wait a minute what if i want to fail back to production well the second decision is if you still had prod as an option we do have the possibility of what's called fail back now what this does is allows us to fail back here into production so that's why i'm running the arrow up this way to show you we're going back toward production once we fail back now we're starting to bring some of the data that was collected while we were at the dr site and start bringing it back into the production level if we're happy and we want to stay at production and have that content that was collected at the dr level come with us then we can do something called commit fail back and what that does is now says we are now running on production replication is still there and we continue on and this now will become the last known good and we're back to production but with any changes that happened during that failover period now to better clarify this let's create a situation so at 12 a.m we did let's say our replica okay so we synchronized at 12 a.m a replica down to the dr site now listen carefully in this example we're only doing an example of every 24 hours we're doing a replica some people might do them every hour so for this example i'm trying to make sure that we're very clear that these are 24-hour replica jobs okay so while this is in this state after the replica that original machine is still creating data now let's say we look over and at six am we see that there is a failure okay well if there is a failure that doesn't mean that at exactly 6 a.m it failed it could have been at five or four but there was still content being written up to this point but this content was not copied down to the replica that's a very important thing to consider so at this point we have a meeting and decide at 7 00 a.m that we are going to fail over and from this point forward we are writing data down here to the replica okay now this concept is really important because there are going to be two situations where in almost every case you're going to lose data but you chose to lose that data so the first one is if i say that i just want to do a permanent failover well remember when i failed over i launched that replica from this point and i did it at 7 00 am and if i say i want to permanently fail over this information is not included now that could be because i had malware that's what caused the failure i could have corruption that's what caused that failure and i don't want that information down here so when i permanently failed over i left that bad data behind that was written after 12 am okay so that's a reason why that permanent failover it's not bad to have data lost because the data you lost was maybe data you didn't want okay now with all of this in place there are two more features that we have to discuss but they can create a bit of confusion and i want to make sure that we truly understand as we go back to these processes all right but the next one is fail back now this is where we have a little bit of a difference so when we say fail back now we do that let's say at 10 am when we say fail back we're taking this data and bringing it back up here and trying to do our best to combine those two into the most current data that we can have the only loss would probably be between when this failure happened and when you started the failover so once again a fail back and commit fail back will include this and this data to create the most current and most complete compiling of information between those two time frames now there is another feature or two features i should say that are undo features and this is why i wait to the end to discuss this because if you bring these in too early it can create confusion undo failovers to me they have their purpose but i've always looked at them as safety nets so the first one that we're looking at is undo failover okay now when we talk about undo failover what we're saying is i don't want to fail over anymore okay so i failed over but i want to go back to prod and what undo failover really says is i want to use this data and i don't care about this data so an undo failover means throw this away go back here because there might be some content whether it's email database that's in this that i don't want to lose remember if i permanently failed over i would lose that so if i fail over and i need this more than this i can say undo failover and that could all just be testing data it's not current production value data throws it away but again that could be considered to some people data loss you chose to lose that data when you say undo failover okay the other one is undo fail back and this one is a little more odd and you'll see what i mean in just a moment so undo failback means going back to failover from fail back now the reason why this can become a bit confusing and i actually titled a data confusion is because i have a snapshot now running here and a snapshot running here and i say you know what i want to back out of this fail back now i want to go back this way and i want to undo that process well now we create yet another snapshot down here and now we're trying to really kind of understand where this data resides whether it's here or here and again it's not super complicated but it can create data confusion so these are components that are going to be necessary for certain situations but understand what they do and that's going to be probably the best value if you will to truly understanding what's going to happen in each stage so i tell people all the time stay within the first lines that we talked about these again can be considered safety nets but at the same time undo failover could be something that we just make sure that we wanted this content and don't care about this undo failback somebody failed over failed back and before they committed wanted to go back to failover and and just wanted to stay within that cycle again truly explaining how these pieces of data are positioned can be kind of complicated to some people and that's not what we really want to you know portray when we're showing a product that works as well so i hope this helped you better understand the process i know when you look at it when it's done it looks a bit you know convoluted and confusing but if you watch from the beginning and you see this all lay out in front of you it'll make a lot more sense and all you have to do is follow these arrows and again starting from the root which is in blue all your decisions are based from the root or go back to the root thank you for your time

Channel: Veeam

Views: 20,426

Keywords: Veeam, Veeam Software, Virtualization, Backup, Disaster Recovery, Availability, Recovery, Replication, Data Availability, data protection, Backup and restore, Backup and recovery, Data recovery, Veeam Availability Suite, Veeam Availability Platform, business continuity, digital transformation, business resiliency, Cloud Data management, failover, failover replication

Id: jrSg5oXCmXU

Length: 11min 13sec (673 seconds)

Published: Wed Oct 28 2020