 So backups and disaster recovery planning hugely important obviously because computers fail things break things go wrong We're gonna talk about how to do really simple Not ha fail over as in having a lot of whole cluster of these things ha is nice There's plenty of documentation on it But it does require three or more servers to be done properly and I know someone's screened But did you hear about ha lizard? Yes, I don't really like this as a solution myself. I played around a little bit with it It just overly complicates things and I'm leaving a link and showing this Discussion, which I'll leave a link below as well People come up with some very more complicated ways to do it. This is something that Oliver Lambert He is one of the developers at both xcp and g and zenn orchestra you can do Zenn orchestra disaster recovery or continuous verification featured a copy of em every xx minutes To another server and that's what we're gonna show is how it's really simple to do this without getting overly complex Now I know this is not an automated method where as soon as one server readily grabs and picks up over there But if your budget doesn't allow for a really nice high availability setup rigging one together is more likely to cause you an Overcomplicated mess of trouble doesn't mean you shouldn't be playing with it I do saying you maybe shouldn't rely on it Because it can be very Messy trying to do ha with some of the other tools But this is a nice solution and generally speaking if a server goes down one if it's your server You're usually aware to if it's a client server They will let you know and make you aware and with this solution other than having to click a button It is a good solution that is easy to deploy So we're gonna cover real quick the setup But we have two servers center for one center for two both of them have their own local storage and so we're gonna be using a VM we refer to as YouTube demo running on Xenifer we're gonna replicate it over here to center for two the idea of replication is it will replicate only the differential changes between The replication times so whatever changed on it It'll go over here and we have a copy that is only that old on there If we set it to hourly will never lose more than one hour of data on that particular VM So pretty simple system and if this goes down completely no worries. It's gonna be backed up on to here Now for people who know yes, I know I have more on my network This isn't necessarily a schema that we use this is schema. We have stuff even for some of the clients It's simply just have two Zen servers and we just replicate the VMs over to another Zen server So there's two copies at the backup, but yes, I do know I use things like solar winds for file and incremental backup Which are much better at doing Differentials than trying to back up an entire virtual machine because virtual machines look at things at the hard drive level So it's backing up everything not necessarily one little tiny file change that may have occurred on there So just something to consider when you're doing that, but we're gonna talk through the scenarios and how it works So once again, this is a Zen Orchestra 5 through 3 community edition if you're doing this in production Please consider purchasing the full version of Zen Orchestra, but the backup NG is supported not in the free edition but in the one you compile yourself and Zen server 7.6. So both of these are current as of January at 2019 So we go over here and we make a backup work I just called this one demo you choose continuous replication now I have an entire more in-depth video on backup NG and all of its amazing features We're only gonna cover the continuous replication today, but yes It supports a lot of different disaster recovery options Delta backups and everything else I have another explainer video that spends some time talking about that But when you do continuous replication It will allow it to easily replicate to any other server that Zen Orchestra has in the server list They do not have to be in a pool together They can be two independent servers with their own separate passwords and things like that Zen Orchestra is orchestrating the communication between them and allowing the continuous replication to happen So we have demo continuous replication We're gonna choose the YouTube demo VM and YouTube demo VM. It's currently living on Zenifer The destination is Jennifer to local storage. So Jennifer to local storage currently it lives on Jennifer's local storage Like I said, there's not a prerequisite that these have any shared storage. They do but this that's out of scope of this talk So we get create and we did we didn't have this Backup demo created and then you have to add a schedule to it You wanted to do it like every day Maybe every hour or maybe just business hours for whenever the client or open or whenever you know the most changes are happening Because if there's fewer changes happening not a big deal You don't need to back it up as often because it's not much to back up now how fast will that backup occur? This is going to be greatly dependent on your hardware and the amount of change in that VM between the backup schedules So I've been running this manually a few times. So there was some data so we can look at it So last time it ran was 10 21 43. It's currently 10 42 So we had a 74 megs of data So this is what it looks like when it does it's kind of and do a snapshot Start and then it copies it over to Xenover to start and duration a few seconds size copy it over 74 megs We'll go ahead and just run this again And see what it copies over And you can see this goes Relatively fast and these servers are a couple Dell R7 10 older servers Nothing really high-end here So if you do have some higher end hardware It is going to go a lot faster if you have 10 gig links between them or faster It's going to go faster again as opposed to this is just working over the one gig links Successful um, there was apparently only 18 megs of data between the changes Fair enough, so it doesn't take long and how does that look so let's go over here to back to the VMs and This is over on Center for two so we look at the disc we have a shared system That's why it says it's here and it's not running so it's not showing what it's on But you can see that right here is that for two local storage Here's the YouTube backup demo and it puts a little date in there for each of the replications Back to here demo snapshot, and here's the snapshot. It takes that it copies over So first thing it does takes a snapshot next thing it does it sends the data over an across there So pretty straightforward. What if we wanted to start this? Well, first problem is if we start you can force it to start, but it's going to warn you forbidden operation Operation for this BM is blocked. Why is it blocked? Because we don't want it to automatically start While the other one's running and it's not aware that the other one's running. So let's go ahead and shut the other one off We'll shut it down So if we're over here and we started again still once again We can do that but we really want to do is start a copy of it And the reason you start a copy is because you want to test it I want to see if that's you know actually working properly So we can say start a copy and it will quickly clone and copy it and we can say yep I can verify that my backups are working And everything's good now, especially if you have these set to static IP address This is why you don't want them running both at the same time and this is kind of the manual process of it But in the case of let's say Xenifer dies completely We'd know that this is the last time stamp that we have a backup and we can either for start this one or we can clone this one again But if you go through the start Processing you do a for start you will break the ability if center for was still online to do the continuous replication You'll have to start up basically a new one because it won't understand how to sync it because you've now changed The backup and it does rely on the backup not being changed So once you do this it would have to build a new one for the continuous replication No big deal there now Let's go back over to the overview and show what happens when there's a little bit more data It's in there But when we ran this it was only a few seconds because well the VM is not doing much We're gonna go ahead and pull that over here. All right We started the VM back up and we're logged into it. So let's go ahead and create a file. So one touch I'm not We just added some link file, which obviously doesn't add much data. So we got this file on here We'll do a speed test real quick Now I'll show you what the speed test says and just a second here now The speed test just went and created so we can't speed test a Simple two gigabyte file and then deletes it So it just goes ahead and dumps some zeros into a file creates it and deletes the file So we actually didn't truly add anything but from the block storage standpoint There are two gigs worth of changes that have occurred and I added that little file called tom.txt Go back over here to backup ng And we've seen last one was at 1042. It's been five minutes So it should run again and I say should one of the things that you need to know When this is running is this can happen and it's gonna have to wait a second job canceled to protect VDI chain There's an excellent article here because in case you're testing you run into this I'm glad they linked it right into the error message. So you don't have to go hunting down with the weird Message means but essentially it's all about coalescence and making sure that the merge happened after the snapshot because we When we do a snapshot it deletes one and creates the other so we did run it too fast, which will cause that I'll go ahead and kick it off again It seems on my system or this particular system at the speed it coalesces It takes about five minutes before it gets a full coalescence happening So you do have to plan these so it's not like the revocations can happen absolutely constantly, but They can happen and we'll just go ahead and run it again alright, so the backup was successful and Now we can see that it transferred about 1.9 gig That's because it's looking at the block level so it's seen even though we created and deleted a file It sees two gigs worth of changes at the block level, but still you know on this scenario two gigs Maybe that's how much you have dumping but to that VM on an hourly basis So it still only takes a minute to back it up. Now, let's do that worst-case scenario thing where we are What we're doing here RM dash RF slash Like that be no Okay, we got to use no preserve to do that failsafe so we'll dash dash So now we're gonna really break it. We're gonna go ahead and do this RM RF no preserve and just you know, whoops We kind of broke this. Oh, no can't remove can't remove All right, what happens if we try to let's reboot this to see if we shut down. Oh, I don't complete doesn't work Let's go ahead and hmm. That's bad, right? Back over to the VM We'll go ahead and Issue a restart for it. Let's go ahead and reboot it. Oh Fail to create it won't even do that properly Well, it looks like we're just gonna have to For shut down this VM. So we'll go ahead and get rid of it and it's shut down It's we know this VM is now quite well broken. So this is our poof. We broke that Take it or VMs now. How do we start at the other one? Go back over here to VMs And real oops rely on our continuous replication here In fact, we'll just go ahead and do this. We're gonna remove it all together. So it's gone You don't have it anymore So then you get the call like hey, we have a problem now Here's where you can either a just for start it because well that other one's not coming back It is it is not just kind of gone. It's really really gone. So we're gonna hand for start this one We don't need to clone or anything like that and this is now our new main VM because well The other one we are MRF done, you know Deliberate accident here and while we're at it. We'll also Set a calling it replication Well on we go Let's go ahead and get rid of this because now it's our primary and we'll delete that aspect of it So it's now just called you to demo VM So all right and also by the way Even though it started on another VM and because it's a duplicate with the same MAC address and everything Which is also why the reasons you don't want to necessarily clone or anything like that You want to start it and for start that is when we go into it It got the same IP address even though it's set to be dhcp And the reason why is because when you do these replications it does clone the MAC address as well LS hey, look, there's that tom.txt file that we touched before We are back up and running that quickly just by saying for start it and then we can then build the next Replication back to the other server after Care it or however you want to do it. So hopefully this gives you an idea of just easy ways you can do this go ahead and Cover one last little piece of it When you do these continuous replications, which by the way it is going to have an error because it can't find those You can select multiple VMs to do this So if you have the things that you think are critical that you want backed up on like an hourly schedule to another server You can do this and The only consideration we have is whether or not your hardware can handle it And what kind of load will this put on your server doing that those are definitely concerned But continuous replication is a great way to keep that hot spare availability on a second server Or maybe if the client wants them all normally backed up except for wonder like yeah, we can't live without this And for example, even for us our phone system is really critical and it runs in here So we have that You know set up easily and at the ready to be fired back up So hopefully this is helpful and gives you an idea for Simple ways to set it up back up in high availability with continuous replication and how it works Go ahead and play with it. It's it's a great tool it's built into Zen orchestra and as long as the two servers can talk to zen orchestra Zen orchestra can Orchestrate this happening in the continuous replication Thanks for watching if you enjoyed this video Go ahead and hit the thumbs up if you want to see more content for my channel Go ahead and hit subscribe and the bell icon and hopefully youtube will send you a notice If you're interested in contracting launch systems for any type of it services work or consulting work Go ahead and head over to laurance systems.com and fill out our contact and get in touch with us If you would like to help the channel out in other ways You can use our affiliate links below in the description or we have a link directly to our laurance systems page We have a list of different affiliate offers And it's very appreciated if you use any of those for signing up any of the services and many of them offer You discounts if you want to head over to our forums, there'll be a link in the description for our forums Wherever they may be because we've been looking at different forum platforms But they'll always be relevantly linked right there. All right. Once again Thanks, leave some feedback and comments below on this video. If you loved it. If you hated it I try to reply to everyone the people who hate and the people who love them. So thank you very much and see you next time