 While I do enjoy customers who have the budget to build out a very thorough HA recovery system with multiple servers and automatic failover and a wonderfully well-built sand that's not always the budget everybody has so I want to talk about a reasonably priced as in you just need two servers and nothing too special here using xcp-ng to Have a fast disaster recovery plan that doesn't break the bank and doesn't require a bunch of crazy software or anything like that So what we're going to be using for this is Xcp-ng on two servers that happen to be identical They don't have to be identical one server can be faster than the other if you have an older server You want to use but it should be able to run whatever VMs you want on this disaster recovery solution Now the way this is going to work is we're going to be replicating the data from the servers that are Center for one center for two each of these servers just have local storage. That's what we're basing it on My lab obviously has a lot more in it But we're basing this on like a scenario where you want to put two servers in at a client Or at least maybe take their old server and use it a backup so you can back up whatever their critical Machines that are running on a schedule the other tool ring using is then orchestra or the purpose of the demo I'm using the free version, but yes, you can get a paid support version That is beautiful in auto updates from the Zen Orchestra people but like I said for purposes of being open source and A lot of people are probably gonna be testing out and their home lab You can just go grab all this software and download it and compile it and get it configured Now these servers happen to be in a pool, but that's not a requirement. You can send this to another server Not in the same pool I just don't feel like breaking my pool in my lab for this But pool is not a requirement and what I mean by pool is these are in a common pool Read up on it. I have videos about what a pool is and the Zen server Nomenclature when you cluster things together essentially All right, so let's get started in Zen Orchestra and I have a Debian machine running and show you actually how this works The basics are these two devices only have to be on the same shared network That's the only requirement and they both have to be running the same. I recommend the same version of XC PNG It would probably work with different versions, but it's free to update to the latest So always make sure both machines are running the latest just so you don't have any issues So here is my Debian 9 replication demo. I just turned it on boot it up here So it'll start up and we're gonna replicate it live now I do have the Zen tools installed on this and this could have been a Windows machine or anything else So the nice thing is this is lighter weight because it's not a Windows machine So the backup will go faster for purpose of the demo, but yes, I've tested this. Yes, this works No problem with Windows or whatever VM you want running BSD etc etc But we have backup NG now the other requirement of course is that Zen Orchestra is able to talk to both servers And that's really easy do have done reviews on Zen Orchestra Great to set up, but it does have to be able to talk to both servers But like I said, they don't have to be in the same pool because these are in the same pool They don't it automatically does that and we're gonna go to backup NG. We're gonna go here to new VM backup and we're gonna find our replication box now currently We'll jump back real quick here to see, you know the replication demo happens to be running and has the hard drive on Xenifer local storage. So it's on server Xenifer. That's our main server. It's running on local stores back over to here We're gonna do the new backup replication new to Replication demo if I can spell that Continuous replication And the destination is Xenifer 2's local storage and what we're doing here is we're going to continuously on a Basis of however, you know, you want to choose or however long you think you can go without the server They have it backing up. What I mean by that is this is where the scheduling comes in Keep two Every 30 minutes to two copies Every 30 minutes is what we're gonna do here And this is the scheduling system. How many replication retention will have two copies of this entire VM? You can go with one if you want really just comes down to how far back in case you want multiple snapshots of this You can keep more but obviously it comes down to how much storage is available so keep two copies every 30 minutes and we'll run this at like zero and thirty and You could run it more frequently and what we're saying is how often do we want to do that snapshot and You can probably say what if I want to do it every minute you'll run into an interesting problem If you try to constantly replicate it every minute one You'll tax the machines quite a bit to you'll run into what they call VDI chain protection That's because you can only snapshot so fast and get data over there How the distance between The chains coalescing is going to be based on how fast these machines are so it gets complicated. There's not like a simple calculation but doing Disaster recovery every minute is probably a little bit unreasonable And obviously you're starting out with the fact that we don't have the budget for a giant ha system Which would be automated so probably you don't have the fastest servers to be able to do this So let's say every 30 minutes and what this means is if the server dies within You have only ever lost 30 minutes of that server by doing this we're going to hit okay And then we're going to head and hit create All right now we have the jobs created And here's this one here and it's been a while. I've actually done this demo before obviously There's some logs in here for this but let's go ahead and we're going to replicate this now We're going from zennifer to zennifer to both using their local storage And I'll fast forward because the very first time we do this because we just created this job The very first time you do this takes a little bit longer Because it's got to get all the data over there now with continuous replication once the job has run And all the data gets over there each subsequent Change is going to go very very quick and that's what we're going to demonstrate here Now you can go over to tasks and you can see it exporting and copying the data over right now Like I said, I'll fast forward through this so it's you know, pain's taking me wait for this to happen So the youtube replication demo has completed so we started with debi 9 replication demo We've copied it over here to the zennifer 2 local so it starts at zennifer's local storage and moved to the local storage on zennifer 2 took four minutes 11.19 gigs 52 meg a second here likes it pretty quick done and Technically, this was a full backup because this is the first one we did now. Where does it live? How does this work? So let's talk about that So it does not show up in the backup is like every store process It is a actual machine with this date It'll update the date each time and this is the machine living on the other server now Well, not actually living setting in silence would be a better way to describe it If I were to start this up I'm going to get an error because it's flagged as a continuous replication It'll say hey, don't start this unless you know you're ready to start this because the other one may be running So I'll get a warning So if I I won't hit it now, we'll walk through it after we Do the disaster recovery demo? So here we are we have it it also creates a snapshot of this Don't delete or mess with this map snapshot because this snapshot is part of how it knows how the replication worked So use basically that this machine live on And then we'll simulate where I didn't Enable the schedule, but we'll simulate one by just running this again It should be long enough for the vdi to coalesce so you can run this again. If not, we'll get a chain error But it really said every 30 minutes should be fine started Got to figure out what the differences are so we'll look at the tasks now. We didn't even get to the task Back to overview Successful because there was all the four megs changed from the first time to the last time we did it So it only does the differential. It's only Creating a differential between here. So depending on how busy the server is will exactly depend on how long this takes to do So let's do something to the server that's a little bit more substantial so we can Show the different data transfers. So four megs last time 11 gigs is the full size of the server only four megs Because the change let's make a bigger change to the server. Um, I think this will actually create a big file real quick speed test It's not a real speed test. It's a pseudo speed test But it creates a big file and deletes a big file. So that'll be enough change That's something happened on the server. So we'll run the replication again after this and You know, they will have some more data to transfer and then we'll do the disaster test and how this happens All right, that completed and all this does is Create a big file and delete that big file real quick It's not a true speed test, but it does create some A few gigs of data that it then deletes. So that would be since there's a change. Let's go ahead and run the backup again Okay job cancel to protect vdi chain. This is that demos we got to do is Wait briefly and run this again. So I'll just pause for a second here Okay, so I kicked off a new backup I had to wait a few minutes because you can see skipped skipped skipped. I ran out of patience, but Took three minutes and it still hadn't quite coalesced because like I said the vdi chain And now it started working here. So let's look at the transfers and it's done And how fast was that transfer? So we like I said You've seen the speed demo 1.9 gigs where the data was created in that demo with that little basic script So it needed 1.9 gigs. So he doesn't understand that I Created data because I created it was essentially random noise for the data So there's ends up with a 1.9 gig difference between the two virtual machines Even though I created the data or raced the data, it still occurred. So it sees a difference in it. Therefore, there's 1.9 gigs of change but either way this took from See we started at 939 and finished at 940. So about a minute to do the entire backup. So When you're doing these delta type backups on here They go very fast and like I said, if you're running it every 30 minutes You shouldn't run into any of the vdi chain issues Now what makes this different from a backup and what makes it more of a disaster recovery is the restoration process So now we can we've got a couple copies. We can go here and look at our replication vm's And we have two of them here and you can see they're marked now if I create one more It'll delete the oldest one. So I always have two to pull from but like I said, this isn't really a backup This is a dr plan. So if we um Had to do a backup we'd have to restore these these are ready to run If this stops, so we're just going to go ahead and force shut down this. This is kill it And go, oh no, our server's offline now granted You will have to monitor this because this is not an automated process This is a manual process to start and stop these servers But if you have a client with a server down, they generally let you know and if you have any type of monitoring system Um, it will let you know as well go. Hey, I don't see the server anymore. So now we're going to go back over And we can start our latest one And when we fire this server up You can force start but it says start operation is Blocked no problem. We'll go ahead and force start this And we are back up and running and well, however, it takes the server to boot, which is relatively quick now Everything is duplicated. So in just a minute, this server will be back up and running The customer is back to being happy your servers are, you know, radar rock and roll It's a simple dr plan It does require some manual intervention But I don't think that's too big of a deal because the manual intervention Is not that difficult and that quick you're able to replicate this from the last backup And if you're running it every 30 minutes, you've only lost 30 minutes worth of data Your server is saved backed up and running now you can work on the other server and figure out why it's not running at all And then you start the process over you actually you do have to I do recommend I mean there's ways around it, but um Because this job I would actually recommend deleting this job and starting over so you don't try to Synchronize these things or have a problem trying to restore the backup. So you just go here. You can either just edit the job And because this is all done by IDs you choose the one Server here and we'll go Choose this one here and we set up a new replication. It's gonna set new snapshots up, etc, etc So you're back up and running. It's a really simple process It's one of the ways that we keep our servers just kind of at the ready We do backups of them and that way you can take the entire vm and back it up off site but a backup takes time to restore and This takes no time. That's just a matter of oh main server failed. Go ahead and turn it on there I think there's some ways I've seen people talk about ways to automate this uh and turn it into Well, it's all scriptable So technically you could set it so if you don't find the other server you can write a script to say Hey, the server's down to do that But you don't have to be careful as well if you shut down the server maintenance and it tries to fire up your old server And you create new problems But this is a pretty simple way to do it with two servers And I just wanted to point out when people ask about disaster recovery playing it does not have to be Super complex. This kind of fits a lot of people's budgets. We have a few clients that have this setup You know, we took their old server. We have it. We know it's not going to run fast But they have a couple core things they want backed up You can set it up that way. We have all the other backups set up. This is another way of another layer On site that you can have that you can go. All right, if I need to I can instantly have this person back up and running Based on a 30 minute or one hour schedule depending on how taxing the machines are And like I said, it's only doing a delta backup of the changes So the replication happens and really very fast even two gigs here of change Took all of one minute. So even a reasonably busy server You can have it up and running Pretty quick and you can just put this on a schedule and have it exit run every half hour. All right. Thanks Thanks for watching. If you like this video, give it a thumbs up If you want to subscribe to this channel to see more content hit that subscribe button and the bell icon And maybe youtube will send you a notice when we post If you want to hire us for a project that you've seen or discussed in this video head over to launch systems.com Where we offer both business it services and consulting services and are excited to help you with whatever project you Want to throw at us? Also, if you want to carry on the discussion further head over to forums.laurancesystems.com where we can keep the conversation going And if you want to help the channel out in other ways we offer affiliate links below Which offer discounts for you and a small cut for us that does help fund this channel And once again, thanks again for watching this video and see you next time