Is your Disaster Recovery as a Service provider REALLY providing you with the data resilience you need? Do you understand the difference between DRaaS and high availability?
Probax is one of the few service providers for MSPs delivering TRUE DRaaS, leveraging their Hive storage, powered by Wasabi, for long-term retention and deep archiving for system images and database backups.
In this webinar held on 20 January 2023, our Chief Architect Brad Jervis discusses all things DRaaS with Drew Schlussel, Sr. Director, Technical Marketing at Wasabi.
In this engaging discussion, Brad and Drew cover:
- Why you need to implement DRaaS in the cloud age
- The difference between BaaS and DRaaS
- The difference between REAL DRaaS and the imposters
- How leveraging hot cloud storage amplifies the resilience of your data protection operation.
- How to get started with Probax DRaaS today and sleep better tonight…
The Q&A session is facilitated by Isabel Freedman, Partner Marketing Specialist at Wasabi.
You can watch the webinar at Wasabi Webinars, or simply click below. Scroll down for the full webinar transcript.
How to Accomplish Real Disaster Recovery - In Conversation with Draw and Brad
Drew Schlussel: Welcome everyone. I'm Drew Schlussel, your host for today's webinar "How to Accomplish Real Disaster Recovery Readiness in the Cloud". With me today is Brad Jervis, Chief Architect at Probax. Say hi, Brad.
Brad Jervis: Hey Drew. Thanks for having me.
Drew: Pleasure. Great to see you, hear you again. All right, so let's get rolling here.
Today we've got, an incredible topic to cover. We're gonna talk about the difference between DRaaS, disaster recovery as a service and high availability. There's a lot of misunderstanding out there. Brad's gonna set us straight and in the process, I think we're gonna help people really, truly understand the advantages to using disaster recovery in the cloud.
We'll talk a little bit about how Wasabi supports Probax and that effort. A word from our sponsor, of course.
Today's presentation is brought to you by Wasabi, the world's hottest cloud storage. Wasabi provides simple, predictable, and affordable hot cloud storage for businesses all over the world.
We enable organizations to store and instantly access an unlimited amount of data at a fifth, the price of the competition with no complex tiers or unpredictable egress fees. Wasabi is trusted by tens of thousands of customers around the world and has been recognized as one of technology's fastest growing and most visionary companies.
Wasabi is thrilled to have Brad Jervis from Probax with us today. And Brad, why don't you tell the folks a little bit about yourself and then we can dive into who Probax is and what the story is with DRaaS.
Brad: Awesome. Sounds good, Drew. My background is mostly in cloud backup and predominantly disaster recovery.
I've done hundreds of disaster recovery tests with various different customers in my tenure and overall, it has been a very phenomenal career, but it's been eye-opening. It's been absolutely eye-opening.
If you would've asked me a few years ago: "Brad, what are you gonna do? Concentrate on disaster recovery?"
I'd be like, oh no, probably security, or something like that. But as I entered the space, I found that disaster recovery is just, people don't quite comprehend it. And there's so many folks out there who really just are giving bad advice, and not everyone is thinking disaster recovery. So that's a little bit about me, but let's talk about Probax.
So I joined Probax around two years ago. It was founded in 2005 over in Australia. Probax actually started as an MSP.
Our founder went ahead and was developing cloud backups way back, I wanna say it was around 2008, and built his own and was saying, wow, this is great. Another MSP started reaching out to him saying, hey, this is awesome what you've built. Can we have this? So we quickly shifted the company from being an actual Managed Service Prover to being more of a Service Provider directed towards MSPs.
Now as time has gone on, we have used various different products, we still use and help a lot of folks with StorageCraft. But over the years we've really found that Veeam is the market leader when it comes to backup and especially disaster recovery.
So we've been very heavily partnered with Veeam trying to get MSPs involved in the Veeam ecosystem. So what our platform Hive effectively does is, it enables MSPs to use Veeam in a way that typically isn't provided by Veeam out of the box.
So you can think of us as something that just gets added onto Veeam to make it more easily for MSPs to consume.
Drew: Like a supercharger?
Brad: Pretty much like a supercharger. Exactly.
Drew: And I think you chose wisely because, this is I don't know, should we call this guy Kevin? Yeah, let's call this guy Kevin, because Karen's coming up next. This is Kevin. He's worried, right? And he's thinking about how he's gonna protect his data and how he's gonna keep his business running, if there's any kind of interruption.
The stat we're pulling these days, right? 81% of organizations expect to use backup as a service and or disaster recovery as a service by 2023 and beyond.
And there's good reason, right? Number one, people steal, right? This is my typical Karen slide, right? Karen's a hacker. She works for a global ransomware syndicate. She finds vulnerable corporate systems and goes in and steals data and ransoms that data and or encrypts it. The users, not a very good person, but there's also the fact that people make mistakes, right?
I think the number one reason backup is because of human error, right? Somebody hits the wrong key. There's also the fact that people leave. And when they leave, a lot of knowledge goes with them. Sometimes some data goes with them. But usually, it's more about the knowledge and the experience. And of course, we're talking about disaster recovery.
Disasters do happen which is unfortunate. It seems like it's happening more these days. We won't segue into the causes, but suffice it to say, it’s good to be prepared.
You and I talked about this at length, I think when we were together just a few months ago, right? There's a number of different solutions out there, but not all of them really, truly are disaster recovery, they pose as disaster recovery. And you're gonna take us through what's the difference, right? How does this really work?
So, you let me know when to click ahead here for you and I'll start you off with the first one.
Brad: Awesome. Great. So, the imposter in this case is disaster recovery from backups.
So why is it an imposter? In order to determine that, we need to figure out how it works. So instead of having a live replica, and in this case, we're talking about a replica of a VM, so you have a virtual machine onsite, and then you have a live replica of that VM inside of your disaster recovery site, ready to be powered on.
Instead, they just grab the data that's inside that backup and they do an instant recovery into the DR environment.
Okay, next. So, we're able to failover to DR. With similar recovery point objectives or RPOs or recovery time objectives, RTOs, because at the end of the day, that recovery is instantaneous, so sounds good, right?
You get to have disaster recovery and backups, and from that point of reference it sounds wonderful. But there's a problem with this that not a lot of folks really consider.
Since the replica is built from a backup, there's no easy way to failback. Only the incremental changes. So, what does this mean? This means that if I fail over my environment, let's say I've got a terabyte of data and I fail over to my DR site, and maybe I've only failed over for two hours until the disaster, it's maybe a power outage or, because I don't have a one-to-one relationship between a replica VM and a local VM, in order to failback those changes, I either need to copy all of that data somehow manually by going into the replica VM, identifying what's changed manually and move it over, which is a huge pain.
This implies that in order to failback, I need to recover a full amount of data. This could be hours in our case of a terabyte, but larger environments, it might even be days of downtime when the failback occurs.
At some point you have to wonder, should I even fail over because my failback time is already gonna be in the hours or days.
Drew: All right, Brad, that seems like a huge problem. What are the implications here? How do you solve this?
Brad: The thing is I've, as I mentioned, I've been in the DR space for a very long time. And as a result, I've worked with many customers, not only on DR tests, but actual DR incidents.
I was looking around for some statistics on what folks actually use, or when folks actually failover in a DR, when they actually use their DR environment. I couldn't find anything just as a general number that I could reference, but I can say from my own experience, a very large portion of folks that use disaster recovery, it’s for minor incidents.
It's not for major disaster recovery incidents. So, we're talking about power outages.
I'm in New York City and I used to work for an MSP. For every single high rise in New York City, they do it either once or twice a year. The entire building goes down for eight hours. And when you're dealing with someone who might be hosting an email server, I know I'm jading myself a little bit. Most people use online email now.
But when you're hosting something internally and nowadays it's, you just can't be down for those nine hours, right?
So, they say, hey, I have this stuff in the cloud. I can just fail over to my disaster recovery environment. Why don't we just do that? And when you're doing disaster recovery from backups, and you're talking about, okay, the building's gonna be out of power for six hours, but it's gonna take us three days to actually recover all the data. You might as well just not even have it.
So, disaster recovery from backups. I'm not saying it doesn't have a place. It absolutely does, but the place is, it is literally just disaster recovery. So, I'm talking buildings burned down, the server room is destroyed, everything is gone because for the small little incidents, whether it be a power outage, a storm, some other item that might only implicate the business for a day or something.
At the end of the day, it becomes not really worth it to spin up that disaster recovery from backup just because it's gonna take so much longer to failback.
Drew: Working with Veeam, right? We both know that they've got some fairly strong recovery capabilities, especially for their backup for Microsoft 365, right? Easy to recover a file, a directory, a conversation. At a certain scale, right?
Brad: It does with Veeam, that's one of the reasons why that we're partnered with them because they do true disaster recovery. And that's a great segue into the next thing that we'll talk about and that's gonna be, what does good disaster recovery look like?
What is that good that everyone is chasing, that everyone wants for their organization? Because a lot of times people just say, oh, we've got disaster recovery. Don't worry about it. But it's going to sleep knowing that you don't have any backups. And they say, oh it might be fine, but let's just hope something doesn't happen to our local servers because we don't have any backups.
That's what I consider people who haven't really thought about their disaster recovery and don't have a good DR plan.
What I wanted to do is just talk a little bit and go through point by point what good disaster recovery looks like.
Drew: Yeah. Hope is not a strategy. That's one of my fairly standard things. All right, so let me tee you up here.
Brad: All right, so good disaster recovery. We want to have replication VMs waiting to be powered on as of the last restore point. So as of the last replication date, right? So that's gonna be your recovery point objective. How far back can I go with my data?
Most of the time with Disaster Recovery, we're talking about an incident whether it be power outages, storms, building burned down, whatever it might be, and we want to recover from the latest point. So, we want to have that VM waiting and ready to turn on. Now, as I mentioned before, there's nothing really wrong about doing the recovery point from the backup.
However, we're adding an extra layer of complexity into that. When we do a replication, we're landing that data into a VM. The VM is ready to be turned on, and all we have to do when we kick off that disaster recovery is to turn on the VM, so while the backup recovery for DR has gotten a lot better.
Honestly it works a fair amount of the time now, I'd say most of the time, 90% if not more, that's still an extra layer of complexity that we're relying on that conversion of backup into a virtual machine in order for this to work. And there's a chance, and I've seen a lot of people have the same thing happen to them, that backup file to virtual machine conversion doesn't work as expected.
Now we need to go back to plan B. So that's why I'm very adamant on saying that a good DR is you have those replication VMs waiting to be turned on and ready to go with the click of the button.
Alrighty. So, this is a big one and is one that is often overlooked, especially in larger organizations, but as production changes, so too must DR. If you change your production application and now you're making it available over this port versus this port, and you have to change your firewall, to redirect it to a different NAT rule, whatever it might be, you need to do the same thing in your DR side.
It's very important to make sure that your DR side is up to date with production. I can't tell you how many times we've, I've done DR tests with customers and thank God it's never happened during an actual DR event.
But we do DR tests with customers, and this is why you do tests. And we found something and they say, oh yeah, I guess we added this new application and we need to make this available over a public IP address then, huh?
Drew: Yeah, so the, you're touching on two of my favorite things here, right? It's not just about the databases and the virtual machines, right?
There's a whole set of configuration information, right? That has to be... that the state or the settings have to be also considered as part of your backup, as part of your DR planning and execution. And then second most and most importantly, practice, practice, practice.
Brad: That's it. And, people just think that DR is, oh it's as easy as backup.
You gotta remember, you are effectively replicating your entire local environment inside of a cloud platform. And the thing's as complex as your environment is, it's gonna be at least that complex in the cloud.
So, you have to make sure that go through and review your DR but not only that, you test it.
Drew: Hang on just one second. I just want to add a quick story there.
In my time at one of the big three letter companies. I had a customer come into the briefing center and they told me the best story, and that was not only did they do a quarterly DR practice, but they would select, it was like a lottery for who had to participate in the exercise.
It almost always excluded all of the management team. It was completely on the individual contributors to execute their runbook.
This was incredible, right? Because the one person who knew how it was built and designed and implemented, couldn't participate, had to make sure that the documentation was absolutely correct, and it was such a great way of testing out their process and procedure.
Never really heard that kind of a story from many other customers. And I can tell you, had I lived in that part of the country, I would've put my money in that bank in a New York minute. Knowing, how well, they worked right to keep their systems up.
Brad: I just shed a tiny little tear for how that made me feel. That's wonderful. If many more folks followed that.
Drew: Hey, look at the next bullet point.
Brad: So actually, the next two bullet points are pretty much what we're talking about, but, again, you can't just come up with your DR plan and just assume that it's gonna be fine. It needs to be tested.
It needs to be verified, and to your point, and your old customer's point, it can't just be the IT guys going in. Okay, cool, everything is working because they know how to keep things up, but they don't know how to do the user's job.
The second point I have there, user access is simple. This is something that so many people overlook with disaster recovery. User access is the most important part of disaster recovery. I don't care what anyone else tells you outside of the fact, getting the VMs up and everything like that. But that's, that that's a no-brainer.
But outside of that, user access is the most important part. And it needs to be simple because let's say you're a customer or you're a company of, I don't know, a thousand employees. And not even a thousand, let's say a hundred employees, or mid-size business, and you kick off a disaster recovery, maybe the building burned down, whatever it might be, and now all your use users need to work from the cloud if you need to go to every single one of those users' workstations.
After the disaster event has occurred, log in, install some VPN software, make them new credentials. Let's say it takes maybe 20 minutes per user to get them access, at a hundred users. We are talking about a lot of time until all of your users are able to access that environment. So, what I've been saying for a long time is we have this concept of recovery time objective, right? So how quickly am I able to get that environment?
In my opinion, we need to include user access as part of that recovery time objective conversation because if my stuff is up and everything is quote unquote working, but my users aren't able to work, then I'm not really up. Things aren't working right, so this is something I've been trying to get out there for a very long time, is user access.
It needs to be simple; it needs to be well documented, and obviously that documentation is not stored in the location where we're doing DR from hopefully. But we need to make sure that our users know what they're doing. They know how to do it. And if they don't, they have some documentation that most of them will be able to go through and read and be able to get connection into the environment.
Obviously, there's always gonna be some folks who, you know, hey, I use Linux at home, so this doesn't apply to me. Hey, I don't have access to this or I can't do this because my, my wife put this permission on my computer to, restrict my teenage son from downloading stuff or something. There's always gonna be edge cases like that.
But for most people, as long as you have it documented, as long as you have everything put in place and accessible to them, then that is going to be the biggest part. And again, I just wanted to touch on, I really do think this is the most important part of disaster recovery, is that user access.
Drew: Yeah, I'll add to that. Make sure you have everybody's phone number. Make sure you have an alternate form of communication that is not dependent right upon the systems that you are trying to reconstitute. Because the last thing you want is somebody standing over your head, smacking you with a ruler saying, are you done yet? And you don't know how to get hold of the rest of the team.
We're living in a highly disaggregated environment these days, you better have those. And I don't mean like an email that goes out once a month or a week. Hey, here's everybody's phone number because you're not gonna be able to get access to it, right? Plug it all into your personal address book. Make sure you have correct information. All right? Moving on.
Brad: Excellent. So, this goes back to our previous point, in order for us to have what I consider to be good DR, we need to be able to do a quick failback of only the incremental change data that's happened post DR event.
This basically means if I am encountering a power outage and I want to fail over to DR because I have mission critical systems and folks need to, work or purchase things for my company, whatever it might be, I want the ability to failover into my DR, use it as it's intended, and then failback without having to encounter any lengthy wait times to restore my data.
As I mentioned, most of the time that people use DR, it's not because the building's burned down. It's not because, the crater landed whatever, most of the time that people use DR, it's because of trivial things that are measured in hours, maybe a day. It's not measured in days or weeks.
If you wanna have DR from backups, that's fine, but understand that the only time that you'll actually want to use it and you wanna make sure that both you and your customer are aware of this, the only time that you're going to use this is in a true disaster type event.
The building's gone. Whatever it might be, because otherwise it just doesn't make sense for folks that need to have something that's available on the fly, whether it be because of a power outage, a storm, maybe we wanna failover preemptively because there's a hurricane coming to Florida and we say we'll probably be fine, but just in case, maybe we're a little bit inland, the eye of the storm's moved over a little bit, we might be fine, but there's some predictions that are saying it might cross over us.
Let's just failover preemptively. Folks can work. We don't have to worry about it, and then when it's done, we can just failback for that sort of thing.
You need the true DR, and that's what the power of Veeam and Probax can offer through Veeam because it doesn't like some other of these other folks, it doesn't just spin up from a backup. It's a one-to-one replica. So, we're effectively taking backup and DR. And as in my opinion, we're splitting them off into two different categories.
Backup is not DR. DR is not backup. They're two separate things. And this is one of the things that DR looks like.
So the final one is, and, I added this as a sort of an aside because I have encountered this a number of times. I talk to some customers and say, okay what's your DR plan? What do you guys have? And they say, okay yeah. So, let's say something happens and the building burns down so we have this remote office, so we'll just make this change to this VPN and then we need to change this DNS record, and then we need to change this and then make these changes and spin this up, and then we're able to turn things on. Listen, that's fine. I get it. Some things, some environments are complex.
You need to make changes in order for DR to function, but the goal of disaster recovery should be to make as minimal changes in production in order to have that failover failback. So, the ideal DR scenario, and again, this is unrealistic for most due to complexity, but the ideal is you press a button to failover, you press a button to failback. Everything is working as expected. You don't have to do much. Again, completely unrealistic for most companies.
However, the main point is to reduce the amount of additional complexity that you're adding. An example of this is previously, prior to cloud disaster recovery. It used to be that, especially in the Veeam world, you would house your Veeam server in your DR site. No cloud, it's just a separate data center that you have. That Veeam server would sit there and then you would do a re-IP address of all of the VMs because you can't have a direct connection between the sites using the same IP scheme. So, all the IP addresses on the replicas would change when you spin up.
Now that was fine. Good idea. It was the only way to do it at the time. But if you can recover in the cloud and you can keep your same local IP scheme, you are just removing so much complexity. You're removing so much potential for things to break for hard-coded IP addresses. So much potential for DNS not to update properly, so much potential for active directory, not to work properly.
There's just so many benefits from just taking that little extra step to remove that complexity, and I feel like that should be the pervasive message going through folks who are designing their disaster recovery plan, remove as much complexity as you can. Easier is always better, even if it takes a little bit more work initially to make it work easier or a little bit more architecture.
Maybe you need to be a little bit creative with something, but it's always worth it in the end because the worst DR plan is when you open it up and it's a 10-page novel on everything that you need to do in order to make everything work inside of the disaster recovery environment. If I'm getting woken up at two o'clock in the morning because there's a building burnt down and now I need to go through and I open up a 10-page document of steps I need to take to get the DR up and running. It's just a, ugh.
So, you really want to make sure that you basically keep it simple. That's the old adage that we learned in tech is KISS. Keep it simple, stupid.
Drew: Absolutely. You're saying what I'm thinking. All right, Brad, a lot of great advice here. You guys definitely differentiate yourselves from other, service providers to the MSP market.
In terms of, like you said, supercharging, right? The tech that Veeam has today. Could you just take us through at a high level what is it that Probax does with, customer X, Y, Z.
Or actually let me back up. MSP comes see you guys and says, hey, we love what we heard on the webinar. You and Drew did an awesome job. Help us. We want to offer this service to our customers. How would they engage with you? What do they need to bring to the table for you guys to get started? And what kind of service and support do you bring to them to extend to their customer base?
Brad: Great question. And it's as easy as reaching out to our sales staff, and the main thing that we offer is we take the best of breed technologies and put them under a single pane of glass portal so that customers specifically MSPs, we work solely with MSPs, so MSPs can create accounts for their customers. They can provision services. They can do restores everything that you would expect from a fully-fledged backup disaster recovery solution under a single pane of glass.
However, we're not dedicated to a single vendor. So, we support Veeam, we support StorageCraft, we do Dropbox backup, we do Office 365 backup.
We have Wasabi that you can provision directly from our portal. So, we look at what's out there and we, and we integrate that into our platform so that way our customers don't have to choose and don't have to manage, different technologies with all their different customers and five different portals or everything.
Anything could be managed within our environment. And specifically, as I mentioned, we're talking about Veeam backup. We do Veeam Cloud Connect; we do Veeam Disaster Recovery via Cloud Connect everything like that. So, it's really a powerful tool for customers who take all their customers and all of their backups and put it under that single portal where they can view everything and get full understanding of their entire customer environments as far as what's working, what's not, what's, what needs to be done and where we're getting protected.
So I could talk about all of those products at length, and I know we don't have all the time to do that. But I will just say that one of the things that we've actually developed is, and this is something that Veeam has actually recognized us for, is we have agents that sit on top of Veeam.
One of the things that Veeam has, historically not been the best at, is the Managed Service Provider space. And there's other companies out there that do backup for MSPs a little bit better in the sense that they have a single pane of glass portal. They have their own storage. Veeam doesn't have that because Veeam is built for enterprise and they're not getting into having their own cloud-hosted storage or anything.
But that's what makes it so good because our customers have so many different ways that they can protect all of their customers, and they might have one customer that needs to full disaster recovery and all of this functionality and all these capabilities, and they need 100% full uptime.
Awesome. Great. Here you go. Here's full comprehensive disaster recovery. Here's your backup. Office 365, we've got your Dropbox all under that single paned glass. and then they might have another customer that's a nonprofit. Maybe they say, listen, if I'm down for three days, it doesn't really matter for me. Budget's tight and we just need to do our regular backups. You can do that through the portal as well.
So, it's a very pick and choose. Choose your own recovery kind of environment and being able to customize the solution for your customers rather than having to fit them into a cookie cutter, self-designed way of how companies think that you should do backup and disaster recovery.
Drew: I love it. I love it. I love it that you guys’ right-size the solution, right? You are consulting with your MSPs, right? To make sure that they are delivering right. An affordable, comprehensive solution based upon the customer need. That's the way it should be done, right? The one size fit, all those days are gone.
Brad: And one of the things that I'm really proud about is we have directly on our site, and when you log into our hive portal, hive.probax.io, we have right there. Here's how you submit a bug request and a feature request, and on every single call with an MSP, I always wanna highlight that because at the end of the day, if you need something, if you think our portal is missing something, if you need some additional functionality, guess what? Odds are, there's other MSPs that need it as well.
So, what we do is we take that those feature requests, and if it's already been requested, it gets added, or joined to the feature request and then that moves up our roadmap. So, we want our MSPs to directly influence what's on our roadmap, what gets developed, and a lot of our MSPs that we'd work with when we're creating new products, new features, new integrations. The ones that request it, we'll reach out to and say, hey guys we were actually developed a beta for this. Would you like to work with us and test it?
And it's actually, I, having worked at an MSP, I know how busy it can get and you're always putting out fire after fire. But I can't tell you how many of our customers have said, hey, we're more than willing to help you test this if this is gonna get us this feature, this function. By all means, and we work directly with them to deliver the solutions. And as a result, a lot of other MSPs benefit as well.
So that's one thing that, you know, not only me but also all of Probax is really proud about is we really try to work with our MSPs to determine what's gonna work for them. We're not telling them how to do anything, we're asking them how they do it, and then we design a product.
Drew: Nice. And by the same token, Brad, I mean as Chief Architect for Probax, you stay very close to Veeam and their technology roadmap. I believe you are a Veeam Vanguard. So, you get some insider information every now and then.
Brad: Correct. Both myself and our CTO / founder Kevin Allan are Veeam Vanguards. And as a result of that, we have a direct line of communication into the Veeam product development team. So, we get a little bit of inside information about what's coming down the pike for Veeam release dates. We get access to beta software.
It's funny, a lot of the folks at Veeam actually joke that oftentimes we get it before they even do. So it's nice actually, and it's just great because it gives us at Probax a glimpse into what's coming down the pipe with the technology, so that way we can develop our platform based around what's coming so we're not playing catch up, we're going above and beyond to make sure that we're gonna have it ready, come, release date on the next version of Veeam that might introduce X, Y, Z feature.
Drew: Yep. I know there's a lot coming out, so we'll have to save that for another conversation. There you have it, folks. Another fantastic conversation with Brad Jervis from Probax. We've got up on the screen the contact information here to learn more about Probax at probax.io or hive.probax.io.
What we're gonna do now is we're gonna go ahead and take your questions live. And once we're done with that, we'll have any final thoughts from Brad, and we'll close it out. Bring it on. We're ready.
Isabel Freedman: Hi everyone. Thank you for joining us. I'm Isabel Freedman here with Wasabi, and I'll be moderating the Q&A with Drew.
One of the first questions I see that we can cover is will there be a recording of this webinar. So once this webinar is finished, you can actually access the recording immediately after, from the same link that you guys’ access to enter the webinar and register. You can share that out with your teams.
And then to go into some of the other questions the first one we have is one of the attendees is currently using Datto's complete turnkey system for hardware, software, and cloud storage for backing up servers. One of the features that they like is being able to automatically boot backup image and receiving an email with a picture of the login screen.
So how can we accomplish the same functionality with Veeam and Wasabi? And as a follow up in the case of a facility problem, they have the ability to spin up a VM in the cloud. Is that also possible with Wasabi?
Brad: Yeah, so I can answer that a little bit. And Datto is one of the folks that they do DR from backup. So, a lot of the things that we were talking about in this webinar potentially applies to them. I'm not gonna call them out on anything specific, but I'd encourage you to reach out to your Datto rep and maybe ask them what failback from spinning up in the cloud would look like and see, exactly what that's going to entail.
As far as they do have this wonderful feature where they spin up the VM and you can see a nice image of it. Veeam doesn't currently offer anything like that because Veeam is typically, they wanna see more of a restore than just showing an image of that Operating System screen booting because that doesn't always mean that everything is okay.
However, we do have a lot of MSPs that have come from Datto and others who do something similar. So, what we offer is actually a fully-fledged MDPS solution. So managed data protection services. And what we'll do is we'll actually perform those restores for you, show you the same thing as you get with Datto, and it's given to you in a monthly data protection report.
So, if you're looking for that functionality then that's absolutely available via Probax. It's not by default with Veeam outside of doing, restores and validating that the restore worked itself. But I would definitely make sure that you ask Datto about what the failback would look like once you're up in the cloud.
Think about when you're gonna be using that failover and just take a look and make sure that your customer's aware of the limitations that may or may not exist with that.
Isabel: Thanks, Brad. The next question that maybe you couldn't cover is Probax only available for MSPs?
Brad: Probax is a MSP-only business. We like to make sure that we do right by our partners and the portal that we've built is built around MSPs.
So a standard user, while they would find it useful, it wouldn't be as useful as it is for MSPs.
However, if you are not an MSP and you're an end user and you would like to use our services and you found some of this intriguing, if you don't have an MSP partner you can reach out to our team and we have many MSP partners all over the country and all over the world, depending on where you're located.
And what we like to do is just refer you to them and you can consume the product. We, in our portal, we have the full ability for you to log in as an end user and not an MSP to log into your specific user provisioned services, run reports, take a look at any error messages, anything like that so you get the full functionality.
But we would just refer you to one of our MSP partners because that's our business model.
Isabel: Next question that I see is, will it ever integrate with Haiku?
Brad: This is something that I've only heard a few times and I would encourage you to reach out because we have heard of them as I mentioned a few times from customers, and they seem to be interesting.
We don't have any immediate plans, but as I mention, our business is driven by what MSPs want and what MSPs need.
I'm already adding this as a plus one to the Haiku integration. And the more of those we get, the more chance it will happen in the near future.
I can tell you that it's not currently on our roadmap. It may be at some point in the future. It, we basically prioritize what we're developing based on what the market is asking for. So, you're asking for it, so I'm giving it a plus one, but it depends on how other, how many other MSPs are looking at it and how well it's doing. As far as just market capitalization and everything else and we'll take it from there, but no immediate plans, but that doesn't mean it's not gonna happen.
Isabel: And then just to add that Wasabi and Haiku do have alliance partnership and work together currently, if that's something that would interest you as well. And then next question I see is can we take incremental DB backups?
Brad: So by DB backups you mean database backups? There's two different ways that you can perform these, and obviously it depends on the database platform that you're using slash working with.
If we're talking about standard Microsoft SQL backups, you can do it in two different ways. You can do a crash consistent which is effectively as if the VM just crashed and you're taking the backup from there. When you restore it, you'll have to rerun transaction logs. And then you can also do transaction level database backups as well, where we actually truncate or VM actually truncates those transaction logs. And then, basically you just rerun the new ones after you restore from the server.
So yes, you can do incremental database backups. It depends on your platform. What you're using whether or not it's gonna be transaction level or regular crash consistent. But we certainly can do that. And it also depends a little bit on the type.
Basically, the type of database and how it's being implemented. So, the reason why I say that is Veeam works on snapshots, right? So a lot of times there's some database vendors that I won't mention who do snapshot-based backups, they have a real problem with (databases). So depending on your vendor, you might have to talk to them about that because, it was originally designed to work on physical servers with using their own backup scripts. So, when that snapshot happens, there's no way to effectively pause the I/O, which can effectively, ruin some things on the backup.
So it's gonna be on a case by case basis, but for 99% of the databases that are out there, especially with small to mid-size businesses, Veeam is more than capable of handling those database and incremental backup.
Isabel: Great. That looks like to be the last question we have from the audience, but I'll give people just one more minute. I know we're about to hit the end of the webinar, but see if any other questions trickle in. Drew and Brad, do you guys have any last comments you wanna add while we wait to see if any other questions pop up?
Drew: I'm just thankful that Brad joined us for this webinar. We're really proud to be working with Probax and appreciate the insights that Brad could provide us on real DR in the cloud.
Brad: And I'll just say Drew and also you, Isabel, thank you so much for inviting me on this webinar.
It's been an absolute. Drew, you and I have known each other for a while and we've been talking about doing a webinar like this for a while so happy to see that it happened and to anyone out there listening, if you have any questions on DR. And you want to talk about it, I am the biggest disaster recovery nerd in the world.
I love talking about this stuff. If you have some problems that you need to solve, please reach out to us and I am more than happy to hop on a call and just discuss some of the certain situations, some of the requirements that you might have, and how we can help you accomplish those goals. So, thank you.
Isabel: Looks like we didn't have any other questions trickle in, so just say thank you everyone for joining us. Like I said, the recording of this webinar is available at the same link as soon as this webinar ends. So feel free to share that out with anyone else you think might be interested and thanks for joining us today.
You need DRaaS in your MSP toolkit
Traditional backup only protects a segment of data. That's why our practical and free white paper Most MSPs Have Inadequate Disaster Recovery Solutions outlines everything your MSP needs to know about the importance of DRaaS.
Simply click below to download your copy today!
