Veeam Backup & Replication - What Is Data Replication?

when you think about the term business continuity one of the things that comes to mind first is how to successfully get your data off-site to a remote location to protect against a large-scale outage such as a natural disaster or a data center failure one of the things that veeam has built in with our product is backup and replication replication does much more than simply replicating backup data to another storage target our replication functionality will actually take a source work load and generate a fully hydrated fully functioning copy at a remote location standing by ready to go at a moment's notice should you find yourself in one of these large-scale issues within the data center let's take a look on the light board at exactly how this works and what options you've got available now that we're at the light board let's take a deeper look into exactly how veem does replication and how it differs from a typical backup copy job the first thing you'll see here on the light board is we've got two geographies drilling out we've got our production site with a basic VMware environment on this side we also have a disaster recovery site with a similar basic diagram drawn out in the middle we also have some sort of connection between these sites whether it's a win MPLS network or VPN tunnel now the first thing to make sure we draw the difference between is using a backup copy job we're simply taking a backup that we've already compressed we've already deduplicated and we're simply going to transfer it from site a to site B but it will remain d duped and compressed in the form of a veem backup file type not a VMDK not of VHDX not anything that a native hypervisor would recognize and it's also simply going to live on repository storage now in contrast when you go into the software you build a replication job that's entirely different in this case what we're going to be doing is looking at a source virtual machine and creating a fully hydrated fully functioning copy at the remote location that's registered in inventory simply powered off when it's not in use so the idea behind replication is to enable a failover and a fail back scenario so if you have a large site wide issue as a datacenter failure an isp outage or maybe a natural disaster that's inbound you actually have the ability to failover proactively to avoid any such catastrophes now the way the process works is actually quite similar to the backup process when you first kick off a job a replication job we're still going to send a VSS command to the actual virtual machine if you've enabled application aware image processing now once that has completed we're going to take a snapshot of the virtual machine just like we would do with a backup so once the snap has been completed then we start processing the data now here's the thing the backup job and the replication job process is the same way it actually will compress and D duplicate and the reason it does this is because of this connection so think about if we were to just process the data but not compress it not D duplicate it we're now sending over that bulk data size over this connection to the D our site instead the initial process is exactly the same we do the snapshot after VSS quiescing is done we compress and D dupe the source data we send it over the wire in that compressed D dupe state however once you get over to this side we decompress it and we rehydrate it and we write it as a native fully hydrated virtual machine ready to go at a moment's notice already registered in inventory and that's one of the key differentiators because you may notice that we've got the storage arrays drawn here at the very bottom as part of a sand network so storage level replication does have some benefits over host level replication which is what we're doing essentially communicating with the hosts doing snapshots of virtual machines when you replicate it the storage layer you bypass all this and you're simply replicating a LUN now the benefit is generally speaking you can replicate quicker because you're doing storage native replication of a line from array to array some of the cons though is generally you have to have matching arrays or at least matching vendors before their technology will communicate with each other the other thing is with our storage technology alliance partners beam does actually have the ability to orchestrate storage level replication case in point with net APIs snapmirror we can actually orchestrate that from within our console but what we're talking about specifically is our replication job now on top of this you do have the ability to use a win accelerator so if you have a limited connection here let's say that's a limited circuit where maybe it's 20 megabit connection and you don't even have all of that to do the replication you can implement a way an accelerator during transit now let's say all this is complete all this is done everything's ready to go if we move back over to the dr site one of the other nice things about the replication job is we do have a retention now here's the thing this is not the traditional retention that you're accustomed to with a backup job with a backup job we're talking about points in time that are going to be incrementals that can be recovered from in the event of needing to go back and grab a different version of said data remember over on this side with replication we're not storing the data in a Veen format right we're going to be storing it as a native virtual machine so the only way that we can hold retention is with snapshots okay so on the target side in a VMware environment you can actually set up 228 snapshots hyper-v you've got 47 right at current versions as far as capacities go now do you need to store 28 snapshots on VM probably not but it gives you a nice buffer if you want to create a few restore points with your replicas so that if something happens at production and you don't quite catch it in time and you still need to failover you can failover to a previous point in that replication chain now the other thing that we need to talk about is job schedules you have the same replication frequency options that you do backup options meaning that you can coordinate the job based on hourly daily you can do it monthly if you wanted to do it that far out or you can set it much more granular and get into the minutes or even leave it on a continuous replicating job now there's also a misconception with this if you set the job on continuous that does not mean continuous data protection remember everything that we talked about over here we still have to send the VSS call we still have to do a snap on the VM we still have to process the data which means compressing and deduplicating we then have to send the data over and write it on the target side once all that is complete then we finally delete the snapshot and the job is over now if you set it on continuous all that means in the software is as soon as that process is able to conclude we simply start it over again so does that mean five minutes 20 minutes 30 minutes an hour it absolutely depends on environmental variables with regards to how fast that process can conclude now the last thing that I wanted to make sure that we're clear on is we talked about the maximum snapshot retention so for those of you who are familiar with vmware you know that 28 isn't the max it's actually 32 at current versioning the reason why we don't allow you to go all the way up to the max is we need to reserve a few snapshots for protective reasons when we actually do the failover and before we do the committing of the failover States so the way that this works when you get ready to do a failover before we turn on these VMs at the DR site we'll take a protective snap okay and the reason why this is done is if anything were to go wrong we can undo the failover bring everything back over here to the production side and remove that protective snap on the DR side that way all the data is discarded if it didn't need to be captured right or if something went wrong during the failover we have the ability to issue that undo command now the other thing that we'll look at a little bit deeper in the console is replication and failover is an intermediate step much like our instant vm recovery feature it's not a one stop click and you're done you failover but then you need to finalize it you need to decide as a business what do you do now so once you have failed over you have the ability to do a permanent failover now if you do a permanent failover that assumes that production is gone generally speaking the permanent failover is reserved for when the data center suffered a major issue and you're going to need to run at the DR site for an extended period of time you know let's say for an example the production data center was flooded you know that you're going to rebuild and repair it but you're going to need to run production at the DR site for a while as well as continue backing up those VMs so you don't put your data at risk that's when you do a permanent failover and everything runs at the disaster recovery site now fast forward to when production is rebuilt you'll need to do a reverse replication so now take these production machines that are technically running at the DR site replicate back to the real production site and then you've got everything running back at the location that you intended for okay now the other option other than undo right because we've already talked about undo you failover you can undo and go back to production you can failover issue a permanent failover those are one you know one click and done permanent failover you're running here permanently undo failover you go back here permanently the other thing that you'll need to plan for is the fail back right now the fail back assumes that you've failed over you're running from here for a short period let's say a day to even hours and now production is ready to take that data so all the changes that have been tracked over here we now need to resync to the production side now if the original V are still here but they're outdated now because all the changes are tracked over here the failback will sync those changes back over and update the source I'd virtual machine with only the Delta changes now what happens if the VMS are gone but the production side is still there will fail back the entire VM as it exists at the dr site rebuild it at the production location right worst-case scenario production is gone you've rebuilt but now you need to fail back let's say this was a short outage and you had to rebuild everything wasn't the flood example where we're talking weeks this might have been a day or two so rather than do the permanent failover you can stay in the failover state get everything running back over here and then fail back to a new location so in that design veeam will actually rebuild all the VMS over at this site another option you may have is actually do a seed where if that scenario happened you can take backups of the VMS over here physically transport them to this site so you circumvent having to resync all that data over the connection once those physical backups are here you can use those as a seed to rebuild the replicas VMs then we do just a delta sync failing back just to change data okay now here's the thing once you issue the fill back and you get back to this location you can still undo the fail back so if anything happened while you were syncing the change data back and you found yourself needing to go back to the dr site to either try again or make some modifications over here you can undo the fail back now the one thing that's critical to understand though is when we do a fail back there's no protective snapshot that's taken on this side so if you do the fail back then you undo we've already made changes to these VMs that can't be undone right so when you try to fill back again you can find yourself in a loop where you're just overwriting data so be careful with the fail back all right remember once you issue the fail back we can't undo the changes that were rigged to these VMs now if you don't need to undo the fill vac let's say everything went according to plan you're now running at production everything is smooth you've checked everything you've made sure services are starting and running properly the final step is to commit the fail back now this is crucial because if you don't commit the fail back you're still running in one of those limbo states right there's still protective snaps over here beam still thinks that you're running in an either intermediate phase so it's important that once you have failed back and you verify it everything is running make sure you commit the fail back which will remove all the protective snapshots that you have on your replicas and bring you back to an operational state at the production location let's take a look at some of these settings in the software so you know exactly what options you've got available for replication as well as failing over and failing back ok now that we're in the software let's explore just a few areas that I want to highlight around the replication functionality the first thing is if we look at an existing replication job I want to show you a few of the things that we were talking about at the lightboard with regards to what options you've got so the first thing is when you look at the destination one of the things you're going to notice right away is we're no longer targeting a repository instead we are in fact actually targeting another host or environment to build the copy of this virtual machine on including a production data store now if you look further down in job settings you do have the ability to give the replicas a suffix if necessary that isn't a requirement however and here's the restore points to keep that we were talking about on the board if you need to keep a little bit of extra buffer so that you have that ability to failover to a previous point in time you can enter this here now notice above where it talks about repository for replica metadata this is actually where it keeps the metadata for this particular repository job this repository needs to be at the same site as the source data and it also can't live on a scale out backup repository it has to be a traditional veem repository when you look at data transfer this goes into how we send data from the source location to the target location one of the things you may notice right away is there's actually two proxies if you look at the backup job the backup job only has a single proxy selection so the reason we use a source and a target proxy is so when we process the data at the source side using the source proxy that's what handles the reading from the source data store actually doing compression and deduplication and sending over whatever connection you have to the remote site the target proxy is going to be responsible for receiving that inbound data transfer rehydrating the data decompressing it and actually writing it out to a target data store and registering it in inventory now if you are doing on-site replication which a lot of customers will do if you're looking for high availability and you just want to replicate certain data from host 1 to host 2 you can actually use the same proxy for both the source and the target to cut down on network hops generally speaking with replication we're talking to different geographies so you want to be sure that the source proxy is actually pulled from the source site and the target proxy is selected from the target site if you do leave it on automatic selection just one of the things to double-check when you're looking at job statistics now right below this you can see the way an accelerator option we talked about if you leave it on direct that's simply going to go from source proxy to target proxy if you go through an accelerators then we're going to leverage a source ID wayne accelerator and a target side to try to further locate duplicate blocks of data that exists already in the cache of the target side wayne accelerator so we can locate duplicate data blocks there's no point of sending those over the wire they're stripped from the packets on the source side and reinserted at the target side when you get to writing the target VM at the remote location now guest processing we briefly mentioned if you need application we're processing make sure you enable this in the job and this is definitely recommended for any highly transactional workload you may be trying to replicate and finally like I mentioned earlier you have all the same scheduling options that you would otherwise have for backup jobs including very granular choices such as in the hours minutes or continuous now the one thing we didn't mention on the whiteboard that's absolutely worth noting here is on the very first tab notice you have the ability for network remapping so if the source location has a different IP scheme than the target location you can't actually change up the IP information when you replicate so that when the replicas come online will actually inject the new IP data into the registry during boot up so they will come on with different IP schemes now you also have the ability to do network remapping and the differences REI P is actually changing the IP addresses whether it's the IP of the machine the mask the Gateway the DNS the winds but when you talk about network remapping we're now looking at virtual networks so if your VMware environment let's say is different from source to target where you've got different network names as you probably know if you fail over and you try to boot up a VM at the remote site but there isn't the same network name the NIC will not connect to any network so otherwise it would be inaccessible so it's important that if you do have different network naming conventions and settings you'll want to map the source NIC to a target network so that when you failover and it comes online it'll natively be accessible now one of the things we did talk about is replica seeding so if you check this box notice how you get the seating option now if we skim through this job and get down to the seating options this is what I was referring to earlier so if you find yourself in a scenario where let's say you've done a permanent failover you have to run at the DR site for quite a while and now it's time to bring everything back to reduction what you can do is get a backup while you're at the dr site save it on some sort of removable storage physically ship it or drive it to the production site back to the original location and once it's registered in veeam inventory you can actually get the seed from that repository and essentially what this will do is build the replica vm from that backup and then when you get ready to fail back you're only going to be failing back the Delta changes versus the entire virtual machine data set size save you a ton of time and a ton of bandwidth going over that connection now the other thing while we're on this screen to mention is replica mapping big difference between seeding and mapping seeding is building the VM from scratch mapping assumes that the VM is still there but let's say you deleted the job and you had to rebuild the job since it's already there in inventory this is simply reestablishing the link between what the source VM is and what the target replica VM is that way moving forward the job will pick up with Delta changes only being transmitted over the wire so those are your settings when you build the job now what happens when you get ready to failover so if we look at this one of the things I wanted to show you we're not gonna demonstrate all the options such as failing over and undoing and permanent fail overs and failing back and committing the fail back but I did want to walk you through briefly how easy it is to failover the first thing you can do is a right-click and failover now if you've got a specific VM that you want to failover the other option if you notice right below if we zoom in a bit you can see that we have what's called a planned failover now this is very beneficial if you have the luxury to plan because if it's a real disaster you probably didn't get a heads up on the disaster so in that case you would just need to failover now but I used the example of a natural disaster let's say your data centers on the East Coast you know a hurricane is inbound but you have a dr site on the west coast this is a scenario where typically you're gonna get few days heads up so that you can plan accordingly do a failover now if you do that planned failover what veem will actually do is will initiate that replication job so that we run a typical replication update all the Delta changes that have occurred since the last job run then we will shut down the source virtual machine at production once it's powered off we'll run that replication job a second time and that will capture much smaller amount of change but there were still changes happening while that first run was concluding so this way you don't get any data loss we replicate all the Delta changes and then we will fail over to the target side so this way you have no data loss you're planning for the outage you'll move the workload to the Colo and resume operations as normal now the one other construct to talk about is the failover plan the failover plan allows you to set a priority at which you want virtual machines to come online so if you had something like domain services DNS DHCP and all that needed to be powered up first before anything else would work right then you would want to set that as a top priority moving down then you can set the order at which the VMS will come online even the ability to set boot delays in between if you know for an example one of these virtual machines just takes a little bit longer to initialize fully you may have to increase the boot delay now the other thing you've got the ability to do is run pre and post failover scripts now this can be very very beneficial if you need to run something that a script can handle before you even start to failover and lastly if you want to run a script after the failover is completed such as a DNS update or something to this extent you can actually create a script to do that for you now if we do a basic failover we right-click and do failover now the first thing it's going to ask us is which point now by default it's going to grab the latest possible point that you have but just like with backups you can choose any of those other restore points if and Cerie and when you hit next the last thing is to give it a reason and then you're done now the reason why I've gotten the vSphere client here on the left is I want you to watch what happens as the log window starts progressing and you see I've got that VM highlighted that we're modifying it's the ATL OSE east replica one which is the one that's highlighted so you can see some tasks happening in the Event Viewer here below and you've also got the V m-- log which shows you we're actually powering on the VM the failover completed successfully and you can actually see it's this VM here that powered on it's the OS e I had the ISE selected so there's the OSC vm coming online now once the VM is running notice over in the vein console if we zoom in you'll see that we have an active replica now you'll only see the active with a bold if you've got a replica in that intermediate step that we talked about on the light board so it's important to remember that if you've going to do a failover you need to finalize the failover generally speaking if you look in veem anywhere over here on the left and you've got something bold with a number beside it in parentheses that means whatever that object is it's in an intermediate step so you need to finalize it now just like we talked about at the board you've got all these options and what you can see is we could do a permanent failover which is like what we talked about earlier we'll make the D our site in the new production facility and that's where business operations will carry on you can also undo the failover or fail back to production now we're not going to fail back since this was a basic demo test so what we're gonna do is undo the failover now notice the tooltip that pops up it's talking about any of the changes that have occurred at the D our site will be lost because remember the protective snapshots we talked about all that's going to happen is that snapshot will be deleted and the replicas will get reverted to the state that it was in before we issued this failover command so that's the way replication works within beam that's the way to failover options operate is what you can do intermediate phases remember you need to finalize the failover when you initiate it thanks so much for watching this video and enjoy the rest of your day

Channel: Veeam

Views: 47,671

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

Id: 8htLDzVvsig

Length: 26min 55sec (1615 seconds)

Published: Wed Dec 18 2019