Transcript
In the heart of a lush ancient forest where the trees whispered secrets of old. There lived two sisters, Myra and Tessa. Myra, with her curious spirit, loved to explore the mysteries of the forest, while Tessa, wise and grounded, sought the truth behind every tale. One day, they stumbled upon a hidden grove where a crystal clear spring promised eternal youth to those who drank from it. The legend was known far and wide, and many had ventured into the forest, never to return. Myra, enchanted by the myth, was eager to drink the water. Tessa, however, hesitated, sensing the too good to be true nature of the legend. Determined to find the truth, Tessa examined the surroundings and discovered a series of ancient carvings that told the real story. The spring did not grant eternal youth, but was a natural source of minerals that healed the sick. Many who sought the spring were lost not because of its magic, but because they ventured into the forest unprepared. Tessa shared her findings with Myra, who was initially disappointed but soon saw the wisdom and seeking truth over fantasy. Together, they marked the path to the spring, making it accessible to those in need, and debunked the myth by spreading the true story. The sisters discovery reminded their village and all who heard the tale, that while myths might draw us with their allure, the truth holds the power to enlighten and heal. The spring, once a source of fruitless quests, became a symbol of the sisters journey from myth to truth, teaching future generations the value of discernment and the beauty of truth. Hi, Dave Littman Truth in IT. Welcome to today's webcast. Today we are debunking the top five cloud backup myths. Today's webcast is sponsored by Druva. And in just a second I am going to be bringing out Chris Evans. Chris is principal analyst with architecting it, and Chris and I will be joined by Matt Tyrer. Matt is director of Competitive Intelligence with Druva, and we expect today's event to probably go about 30, 35, maybe 40, 45 minutes, depending upon how the conversation goes. And of course, we will be taking your questions and comments in the chat room. We have staff standing by from Druva to answer any questions you've got about today's content. We've got staff standing by from Truth in IT to answer any questions you might have about the video feed or the audio or anything like that. But without further ado, let's say hi to Chris and Matt. Welcome, guys. Thanks, Dave. How are you doing? So far, so good. We are doing okay today. Matt. How's it going? Going good there, Dave. Good to see you, Chris. Yeah you too. Matt. All right, so hey, we are talking today about myths. I think we've got like five of them queued up, but we may get to some others. So let's start with the first one. Chris. The cloud based backups or backup as a service are really not as secure and reliable as what I can build myself. Let's start with you, Chris. What you've seen, and then we'll turn it over to Matt. Yeah, it's a great question. I think at the end of the day, you know, you have to look at it and think, if you're a vendor that builds these sort of solutions in the cloud, you know, you're not going to build something that isn't going to be secure. You're not going to build something that isn't going to deliver what the client wants, because it's your bread and butter. So, you know, you're going to you're going to know how to build this sort of solution. You're going to make it work. Um, the cloud providers who who build these sort of backup services, people like Druva and other, um, similar companies, security is going to be one of their main focuses, because clearly they're dealing with many customers. They have to handle things like multi-tenancy, and they have to have that ability to make sure all of that data is securely separated from any other client that they're dealing with. So, you know, there's just no way they're not going to be good at doing this. I agree. I think that the key point that, uh, that Chris is making here is kind of where the lines of responsibility are, is, you know, if you're building it yourself and then you're responsible for securing it, you need to keep it up to date, you need to maintain it. And ultimately, it's your level of risk that you're kind of putting out there in terms of how well you do that. Um, when it's turned around, where it's the vendor providing this, you know, there's a lot more, uh, guarantee behind it in terms of, you know, as a business, as the provider. You know, there are SLAs there, uh, you know, um, certain guarantees and warranties that need to be provided for that service that, uh, that they are providing out to everybody else. And so as such, kind of the bar is set a little bit higher because, you know, as if you're consuming it from, uh, another vendor, you know, now they're responsible for all of this. And so if there's a problem, you know, you could seek some sort of compensation there. Whereas if you're doing it yourself, uh, you know, there's nobody to blame but yourself. Uh, and, uh, the consequences are different. So I think, you know, because of where the responsibility falls and the fact that there are various consequences that can stem from not achieving and delivering a proper and secure environment. Uh, you know, to to that point, I'd say that the cloud based vendor solutions are much more secure because they have to be. Yeah, let's just dig into that in a bit more detail. I think that there, you know, you think about what it's like when you're going to do this on prem yourself. If you're going to build your own solution. Um, inevitably you have to, as you said, manage things like updates, refreshing the technology where that media sits, making sure those servers are run in a resilient fashion. There's a huge amount of work involved in actually delivering that sort of service. But do businesses really have the same degree of SLA internally that a separate business would have to you, you know, if you didn't run the backups and you missed an SLA, would somebody internally really get in, you know, any sort of compensation from an internal business unit that run data protection? Unlikely. You know, so as you said, the standards required of an external business are very different. And those SLAs are super important because, you know, ultimately, if somebody doesn't take a backup and they have some sort of breach and their system is exposed and they need to recover, that could be a major issue for them. So, you know, these SLAs have to be adhered to and all of that has to be done properly. So let me build on it for a second. Chris. If you are going to do it on prem, you should be looking to build it as securely as a backup service provider would. Absolutely. I mean, at the end of the day, we just highlighted the fact that internally, you could potentially restore data that you shouldn't have access to. You know, that itself is is an issue. So you should be looking at who could be the backup administrators, who's got the ability to restore data, what the security controls are, to be able to audit those people and see what they've been doing. You know, we we do allow a degree of self-service, obviously, in those sort of solutions. But there's a, you know, there are a set of standards that it would be a minimum that you would apply. But, you know, then you've got to think about things like patching and software upgrades and all of that has to meet the set of standards. Um, it's it's a lot of work to make sure that your, your backup environment is permanently compliant. Yeah. To your point, it's it's an ongoing effort. It's not just, you know, getting it to that state day one, you know, at implementation it's you know, you have to maintain that through, you know, day two, day 365. And you know who is to know, you know, tomorrow there's a new zero day vulnerability. And now you have to go and patch everything. And did that break anything. So, you know, there just adds all these layers of complexity and responsibility. You know, when you're trying to do it yourself, when you know, quite frankly, you could pass that responsibility to somebody else that has, you know, certain obligations and responsibilities in order to provide those levels of service for you. Data center is not getting less complex, so why not at least make your backup easier? Yeah, and, you know, we've got so many different places that we create data now. So just just looking at the fact that it's not a case of just putting this in your own data center and backing your data center up, you're now looking at edge SaaS cloud. So your your responsibility and remit of doing backup yourself or data protection yourself is much wider than it ever used to be. Well. Very good point, very good point. So the myth is that cloud based backups are not as secure, as reliable as what I can build myself, but the reality is completely the opposite. Agree? Yeah. Agreed. Myth. Busted. Yeah. All right. Cool. All right. Let's segue now into into costs. So we've talked about security reliability Matt I'm going to stay with you. One of the biggest myths out there is that the costs of cloud backups are unpredictable and more expensive than on prem and what I can build myself. So I'll start by saying, if you're doing it yourself, uh, you know, and you don't necessarily know what you're doing, then you know for sure the cost of working in the cloud can be, uh, unpredictable and expensive. You know, if you've got to take care of running all of the compute and the storage and worrying about orphaned resources or compute nodes are just sitting there idle and spinning. There's a lot of ways that, you know, all of a sudden that bill can get very, very large. Uh, but when you pivot to looking at it from a, you know, a cloud backup as a service provider, you know, like Druva like others, um, you know, who kind of again, they take that complexity away. Um, so you don't have to worry about the, you know, that unpredictable unpredictability of managing all those resources you just have to worry about, you know, how much data am I protecting? Uh, how many users do I have? You know, it doesn't matter if there's one server behind there or a thousand servers or a million monkeys on typewriters and keyboards. Um, you know, you're looking more at what's the service level that I'm looking for and how much am I consuming that? So it really simplifies that and makes it, you know, what would have otherwise been a very unpredictable and, uh, and potentially expensive, uh, business, uh, into a quite predictable and simple one in the terms of since you don't have to worry about all those other pieces and managing those pieces, uh, the cloud vendors are doing that for you. Uh, you just have to worry about the most important thing, you know, how much data am I protecting? And. And going and consuming that resource. So it becomes much more predictable and linear in terms of understanding what your costs are going to be in the cloud. Yeah, I sort of laugh at this one, actually, because, um, if you break down all of the different components that are required to build an on premises solution, you're building servers, which you'll have to upgrade, maintain, you're buying software, which you have to license and you have to pay for. You buy media, you potentially have to put in networking. And inevitably, I found that when people increase their primary storage, they tend to forget that the back up systems need to be upgraded as well in order to take the additional capacity. So inevitably you get to a point where, you know, you put in a few hundred more terabytes petabyte or whatever, and then suddenly somebody says, well, we haven't got capacity to back this up because nobody really sort of budgets for that. And it sort of limps along and it gets extended. And then, you know, maybe you get sort of six months down the line or ten years down the line, however long it happens to be, suddenly you need to refresh the media because the media is getting old and you need to retain those backups. Well, where does that cost center sit? Is this just an overhead that has to be accounted for? Generally, people don't account for that. And it's certainly not billed back to the business in terms of per terabyte cost for backup or, you know, a seat cost, perhaps based on the number of people that you're actually using, say, an an office 365 type solution. So inevitably you end up with a very disjointed charging model and it limps along. And, you know, people are always going back and justifying budget. I think when you look at the way that the public cloud. Well, let's, let's call it the SaaS providers for, for data protection have built their systems. They've got a much more abstracted charging model. So they'll look at things like seat price, like I just said, you know, so if you've got 1000 users of of a particular platform, you may just pay by the user. So that makes your costs much clearer to understand. Similarly, if you're paying by terabyte and it's terabyte retained, you're pretty clear on what you what your, um, your charges are going to be. So actually, I think they, you get a much clearer model and a much easier to understand model that you can build back to the business with the cloud. Um, with the SaaS model, it's much, much better way of doing it. The on premises. I think it gives you a lot more control as well over those costs, because they are metrics tied into your actual business, you know, you know how many users you have, you know what your retention is and what the the amount of data that you're protecting is, you know, you've got that visibility into those metrics. So you can really predict, you know, not just, you know, next month, but you could map that out, you know, on a quarterly yearly basis. So you can really understand what that true TCO is going to look like over a period of time, as opposed to kind of that haphazardness of, well, did I do I have enough storage already provisioned? Do I have enough compute to address, you know, these SLAs? What if all of a sudden we get like a burst need where you know, now I need to, you know, rapidly scale and then scale back down, you know, did I turn everything back off? Just a myriad of things that you need to be worried about. Again, just like in our other point, uh, you know, if you're trying to do it yourself and build it yourself as opposed to relying on, you know, a vendor that to provide that for you and essentially take all of that and simplify it down into that simple consumable model. Okay. So to summarize this myth, we're going to turn this around right on its head that the costs of cloud backups are actually more predictable and less expensive than doing it on your own. Agree. I think. I think that's a fair point. I think that is fair. Um, it's not to say that, you know, um, you're not going to look at the costs and not be surprised by them. But then I think that's possibly because in on the on premises environment, the costs are definitely hidden from you. So, you know, I think actually it's actually a good thing because it exposes the cost of delivering the service more clearly. And that's a good thing when you're passing that back onto users. You hit on a great point there, because a lot of times, you know, when I'm talking, uh, you know, with uh, customers or other organizations, um, they tend to not have either on, on purpose or uh, or just, uh, through happenstance, uh, full understanding of where all the costs are coming from, uh, when they're doing their own on premises, they might only be looking at the licenses for the, the backup software itself instead of saying, well, what about all the infrastructure? What about those appliances? What about those servers? What about all this? What about the D.R. site that you've also got in there, uh, kind of thing? You know, because, you know, that's something that we haven't talked, talked about. You know, we were just kind of talking about primary backup environment. You know, when you start adding in stuff like, okay, well, now I need multiple copies of the backup. Now I need that resilience in the backup solution itself. Maybe a Docker build of it. Um, you know, when leveraging, you know, a cloud service provider, you know, a backup as a service, um, you know, all of that redundancy is kind of baked into that infrastructure behind the scenes. You know, you don't have those added costs of, well, now I need, you know, an off site copy. It's like it's all already off site and there's probably multiple copies back there. I know for us, we've we we store multiple copies, uh, automatically, you know, and you don't have to worry about. Well, what if site one fails? How do I get site two? You know, with the cloud deployment model? Uh, you know, that's all again, the multi-regional support is there. So, uh, there was are other costs that again, to your point, not everyone looks at that whole picture. It's like, well, my my backup software license is this, uh, and, you know, that's much, that's, uh, much better than, than, um, what the cloud provider is offering. It's like, well, no, you need to you're not looking at the whole thing. And so I'm really glad you hit on that point. Uh, I think. It's I think you. You're highlighting an interesting fact there, Matt, that, you know, depending on the complexity. And we said when we looked at this first myth, you know, I said about the fact that there's stuff at the edge, there's stuff in the cloud, there's stuff on prem. Um, you're highlighting the fact that the more complex your environment and more disparate it is, potentially the more opportunity there is to have fragmentation, wastage and have more equipment than you necessarily need. So, you know, your cost could be actually quite more a lot more significant than you realize. And think that's myth for you. Come on to that in a moment. Jumping ahead. So in any case, the first two, I think we have definitively shown that cloud based backups are definitely as secure or as reliable as anything that you could build internally, and likely far more so, and that the costs of cloud backup are definitely more predictable, more transparent, you know, obviously expensive or not, that's a whole, you know, different story. By and large. By and large, it's going to be less expensive, but definitely more predictable and more transparent. So okay, okay, let's go on to our third myth. Um, and Chris, I'll start with you, that on prem applications and data require an on prem backup solution myth or reality. What do you think? Well, so where did this one come from? Where do we think this myth came from? And you need to sort of look back at the history of the way we did data protection, you know, 20 years ago. And a lot of these sort of myths, I think, come from, um, people's experiences from, you know, ten, 20 years ago. And we had a situation where we had relatively slow networks to what we have today. You know, we may not have had an external connection into the, um, into the internet or externally from our data center like we did in the we do today. And as a result, it was a sort of a requirement to have your backup data as close as possible to the system you're going to restore, because networking was expensive and relatively slow. Now, exclude the fact that if you've got a D.R. site, you'd still have to be putting that data protection system in another location. We'll come back to that in a second. So I think that myth has come from from that scenario. Um, and, and obviously, the one thing that people think about all the time is that when we do a restore, they think it's an all or nothing thing, that when we restore, we have to restore our everything. And actually, if you look at the different styles of failure that occur in a data center, you can fat finger data and delete it by accident. Somebody could delete it. Um, because there's a bug and a bit of software, you might have a minor hardware failure, or you might have an entire data center go down. And it could be any or any or all of those sorts of things that that cause you to have a problem. And as a result, you might only be restoring a small amount of data for a certain requirement. So why do you need big pipes to restore, you know, masses of data? The assumption is that you're restoring everything, and that's not necessarily true. Now, even if you are restoring everything, you need to think, well, what scenario am I doing that in my data center might have gone well. There's no point having an on prem copy in the same data center, but you've now lost, so you've still got to put a copy somewhere. You can't keep it on on prem. There's still an issue there. So I think, you know, the idea of needing to have an on premises copy in order to restore is not true, because actually it's more complicated than, than it seems. And and, you know, I don't know what your view on that one is, Matt. But, you know, the architecture of the way you designed the backup, you simply just wouldn't want that to be the case anyway. Oh I mean a couple of really great great points there. You know, I think it it does all come from that old ideology that you had small pipes. And so you had to, to really have kind of that locality in terms of, uh, protection and recovery. You know, I can't move that data very fast, very far. So I'd better have it close, you know, uh, which led to, you know, a lot of the synchronous, asynchronous kind of replication modes at different layers so that you had, you know, I've got another copy over there, so I don't have to move it or recover it over there. It's already there, you know, which of course goes to our previous slide about just adding cost, expense and complexity in there. Um, but the more important point, I think, is the nature of the disasters we're trying to build around and architect for recovery for. To your point, you know, it's very rare, uh, that you're seeing like an entire site going down. You know, you may see an application go down, you may see, you know, a subsystem or, you know, important network get affected or, you know, more likely, you know, in the event of kind of a cyber incident, you'll see parts of things all over the place, uh, that are affected. So you can't necessarily just smash everything back in place because then you'd be, uh, overwriting the good data along with the bad. So kind of the nature of recovery is very fundamentally shifted. And just, you know, the past five, five, six years to the point where I need that granularity in terms of I may be restoring, you know, a million files, but they're going to be spread out across my entire environment because I'm trying to undo whatever that malware infection did, or I'm trying to just bring up this one critical application of my business and don't need to bring the whole data center back. I just need that server, that cluster of VMs or what have you, uh, you know, so between kind of the increased size of the pipes, uh, the need for architecting around a completely different backup and recovery dynamic, uh, you know, cloud very much, uh, is well positioned because of all the other reasons we just talked about, uh, to provide the same level of, you know, enterprise protection that you would come to expect from, you know, one of the traditional on premises, uh, solutions. I think that was also another thing was I don't think that the feature set is there and it's like, well, well, it is. You can get the same, uh, you know, if not better in some cases, uh, depending on your use case, uh, solution direct from cloud, as you would, you know, from, uh, one of the one, one of the traditional vendors. Yeah, I mean, I didn't, um, another another angle. I think you think about the way your environment might look today again. You know, go back 20 years ago, you probably had a single data center or two data centers. If you were a big company, you might have a few more than that. But in generally you're it was concentrated. Nowadays you could have stuff in at least one cloud, you could have stuff at the edge. We could have stuff on prem, um, you could have stuff in SaaS. Why would you think that? You need only one place to store that backup data, and it has to be on your data center because, you know, are you going to back up SaaS application in the cloud into your own data center? That sort of doesn't make a lot of sense. Really? Surely not. No. Um, you know, so when you step back and think about it for a moment, you suddenly realize, actually, the better way to do it is to have somebody else completely separate from all of the infrastructure you use and do the backup for you, because inevitably they're they're giving you like a D.R. as part of that. So you don't have to have your second site with a second set of equipment and, and backup equipment. You have one set and and it's maintained by somebody separately. So I think modern modern setups are very different to what what they were previously and where, as usual, harking back to what people used to think. The way we did things was meant to be, when actually we've moved on a lot. Yeah, it just goes to speak of our experience in, uh, in the olden days. Uh, yes. Uh, back then, uh, I always think of this one, always makes me think of. And I know, uh, when we were talking about this offline, uh, you were like, I don't I don't get the the joke, but, uh, there's a Dave Chappelle meme where it's like, modern problems require modern solutions. Uh, so I always think of that when I see this. But to your point, you know, if I'm getting the feature set that I need, which, you know, is exactly what you're going to see from from the backup service providers, uh, in the market today, if I've got the speed, if I've got the granularity and the ability to recover that data where I need it, and then I get the added bonus of as soon as I leverage, you know, a backup, a service like Druva or others. Um, you know, now that data is automatically isolated. Now it's all and I've already got that disaster recovery copy. I've got that air gap, I've got that secured, um, data set that's sitting outside of my attack surface, outside of my data center. So that doesn't matter if I recover here or there, you know, uh, somewhere else. Uh, that data is going to be available for me as part of recovery. And, you know, you can do other things, can't you? So, for instance, you could restore into the cloud if you've got an on prem data center, um, if you're being compromised and you're not really sure whether you're, you're, um, equipment is compromised on prem, you could restore to the cloud and run, run from there. You could use that restore process to to test for ransomware. You could use it as a D.R. testing environment. There's 1,000,001 different ways you could use it. And whether you're going from the cloud into your own data center or back, or from the provider, it's all the same thing. It's all across the network. So yeah, why not? Okay. Cool. Okay. So outside of those isolated, highly secure situations, for the most part, um, cloud backup applications can pretty much handle any kind of data, any kind of on prem app. Um, so cool. Okay, so let's get to the next myth, which sort of builds off of the last one, which is that my environment is just too big and too complex for a cloud backup solution. So, Matt, what do you think? Uh, let's start with you and then we'll go to Chris. Well, I think Chris covered it off in the last couple of slides in here. You know, it kind of is. It's all right. It stems. You know, I mean these all kind of build and build on each other. You know, if, uh, your environment. All right. I'm getting my, uh, furry assistant to join us here, as many of us do. And the home office, um, you know, just it's the same excuse as if you were arguing. Hey, you know, it's on prem. It needs to stay on prem, you know, it's too big. It's too complex. Uh, you know, cloud backup can't handle it. Look at you. You're. You're going to be famous. Um. You know, and I think that those are maybe excuses from days gone by where, you know, there simply wasn't the support for some of these applications or there wasn't the ability to provide, you know, very highly customized and capable, uh, backup solutions, uh, you know, from the cloud, you know, a decade or so ago when some of these myths first came out, uh, and that's just not the case anymore. You know, there's there's no reason why the applications that you're leveraging, the environments that you're using, uh, you know, and as I said, you know, I think way back in slide one, you know, um, you know, these environments that you're working in are getting big. They are getting complex. And yet, you know, by being able to go with, uh, you know, a backup as a service provider, um, you know, the, uh, you can simplify all that. So, yes, it's your your environment is complex, but that doesn't mean that you can't simplify it through, uh, through a backup solution that, uh, that takes some of that burden off your hands. So everybody likes to think they've got a bigger and better environment than you have. Everybody likes to think they've got the most complex, the biggest environment, and theirs is the biggest one to sort out or the biggest trouble. And it's just not the case. I mean, unless you're, you know, the size of the US government or even then I doubt they've got the same sort of degree of problem as maybe some of the bigger, bigger banks or, you know, there's always going to be there's always going to be a bigger fish, isn't there, who's got a bigger setup than you've got. So, you know, just just accept that, yes, you might have a complex environment, but it's still going to be handleable by the cloud or, or a solution that's built in the cloud. Because ultimately, most of the vendors that are building SaaS based data protection aren't building it in their own on premises data centers. The ones who are clever enough are looking at the fact that the cloud gives them the scalability to build a solution and to scale up and down to match your requirements. And therefore, no matter how big you are, the cloud's probably bigger than you are anyway, so you're still going to be able to be protected by that environment as long as their environment scales to match. So it doesn't to me, strike me as being a bit a big issue, to be fair. And I think it also goes back to that, to that, you know, that point we we mentioned a second, Matt, where I mentioned about would you really back up your SaaS applications to an on premises environment? Well, surely the simplification of that is to have somebody who actually can write, can back up a SaaS application directly, and then there's no data flowing through your data centers anymore. It's going between the cloud provider and and the, the data protection provider. You're out of the loop. Simple. Keeps it really simple. And so I think you can actually simplify your data protection by deciding to move it to an external provider. Yeah. And you look at a lot of that increase in terms of the diversification of applications of, uh, you know, data source and stuff like that is actually happening in the cloud. So, you know, as you said, it just it just makes logical sense that, you know, if most of these new workloads and new databases and new applications are being built and living in the cloud, uh, you know, working with a provider that's also in the cloud is kind of just a logical step there. Uh, you know, instead of trying to pull it somewhere else. Um. I don't want to pick on the legacy, um, data protection vendors. You know, there are an awful lot because the backup and data protection generally is very sticky as a environment, as a solution. But it could be that you end up needing to deploy 2 or 3 solutions in order to protect your data that is quite heavily dispersed nowadays, simply because one platform either isn't suitable or doesn't protect it to the degree you want. So actually you could end up making your on premises environment more complicated because you need to meet all these different sets of requirements, as you just highlighted. Matt. So actually it could be more complicated and and more difficult to back up even a relatively simple, uh, on premises environment if you're doing it on premises. Okay, let's get to the last myth, and then we'll get to some audience questions and we'll get to the giveaway. So Chris, I'm going to bring this one up to you because you sort of touched on it earlier when you mentioned that these solutions can be sticky. So this myth is with cloud, your data is locked in myth fact. What do you think? Well, isn't it funny I mentioned sticky just before we get to the last one. Now what do we mean by sticky and what. Do we plan that. Yeah, it's almost look like I planned it, didn't it? Yeah. Um, what do we mean by sticky and what do we mean by lock in? I think so when I, when I say sticky, what I'm saying is that, um, potentially you may be keeping your, um, your backups and your, your data protection archives for, you know, some, some environments could keep them for years. Um, depends on the governance, sorry, the compliance requirements of your environment, where you may be required to keep things for an awful long time. And as a result, it's very difficult to get off one backup solution, because there are no tools that will take your data and migrate it to a new backup solution, usually without having to sort of rehydrate that data back into its original form. So people tend not to get off data protection solutions because they have a natural degree of lock in. So does a cloud have a degree of lock in? Well, yeah. All all solutions have lock in one way or another. So I don't think anything in the cloud is any worse than it would be if you were doing it on premises, to be fair. Okay. Yeah. And, um, I think I think the joke is, do you think you're not locked in anywhere else? You know, uh, it, you know, to be frank, it doesn't matter what solutions you're using. There's always some restrictions in terms of moving from one to the other, you know, as a as a backup vendor and having lived in the data protection space for. Well, too long. Uh, you know, that's always been one of the hardest things. It's like, well, I'm changing from this vendor to another vendor. Uh, you know, what do you know? Can I move all my backups with, uh, with me? It's like, well, there's no real good answer. Uh, but at least, you know, when you start looking at cloud, there certainly is a lot more avenue in terms of portability of that data. You know, you're not locked into a particular hardware. You're not locked into a particular platform necessarily. You're not locked into, you know, a particular, uh, storage array vendor or manufacturer or site or, you know, from, you know, physical, uh, restrictions, you know, so, yes, maybe all my data is in AWS, but it ain't that hard to get it back from there or to put it somewhere else where I need where I need it tomorrow or, you know, uh, so I think, uh, you'd be naive to think that there isn't lock in to some degree with anything that you're doing, or, I think, a better way of framing it of, you know, there there aren't challenges in kind of transitioning between different platforms, uh, regardless of if it's, you know, a database platform, it's not like you can copy your SQL database into Oracle and it's going to work, uh, you know, so, you know, there's always going to be challenges with replatforming. But I think when you look at, uh, just, you know, the cloud options in general, that road is a lot smoother and gives you a lot more options in terms of where and how do I want that, recover that data to come back and be repatriated? Yeah. Here's here's one other thing to think about as well. So you know, think about um, on premises lock in buying a solution that you may have to run for 10 or 15 years. Um, as you sort of highlighted indirectly, Matt, you're going to have to keep that hardware, potentially. You're going to have to keep that software. The vendor might not upgrade that software, but you still need to maintain it. So now you've potentially got an exposure every time you start that software up to recover. Alternatively, you ship your media to somebody else who does that for you, and then it becomes an expensive recovery point every time you want to get something back. So yeah, there are pluses and minuses in both sides of this. And it's it's going to be an issue whatever you do. But I do like the way you just described it in the sense that there's no hardware lock in, there's no software lock in, you know, this is a service you've got and it's a lock into a service is very different to a lock in to a software product. Mm. Okay. All right. Awesome. So I think we've busted these five myths. Let's take some questions from the audience. Then let's get to the giveaway. Uh, I think here let's go to this one. And I think, uh, Chris, we'll send this one to you. This I think, goes along with the myth of security, of backups in the cloud. And the question is, does the cloud backup provider protect the catalog for my data, meaning the backup catalog, or is that my job? Uh. Good question. So, um, ultimately, you know, you write your data into the cloud, that vendor will index it, that vendor will keep that index and that metadata, they will absolutely need to make sure that's protected multiple times and secure and, you know, replicated or whatever they need to do to make sure that's never lost. But ultimately, you're going to that vendor in order to do your searching and and finding out what data you've got on their system. So they're going to maintain all that for you. You're not going to be looking at having to keep the metadata yourself. I would suggest that most of the time you still want to have an idea of what you've got where because, you know, server names can be very random. It's very easy to lose track of what you've actually backed up and and backed up in different places. So probably a good idea to have a little offline thing where you just at least know what you think you've been backing up. But in terms of actual files and content, that's the responsibility of that SaaS provider. Okay, great. Let's take one more question. Um, Matt, we'll stick with you, I think, on this one, if I use a cloud backup provider, how does it change what I need to maintain for doctor? Do I still need a duplicate set of infrastructure for doctor purposes? So I'd say for the backup side of the house. No, you know the. Because that's being taken care of by by the provider. Now in terms of maybe availability, you know, for your applications, for your production applications, you know, stuff like clustering or replicating databases. You know, I'm talking about the availability of the application of your production workloads there. You know, there certainly is, uh, logic to, uh, you know, behind making sure that those are going to be as resilient as possible. Uh, and so, of course, there's always going to be a need for, uh, maybe not D.R., but availability and resilience built into that. Uh, but from a backup perspective, um, I would say, no, you don't need to be concerned with that because that's taken care of by the provider, uh, behind the scenes. Okay. Fabulous. All right, guys, thank you very much. Chris Evans architecting it. Thank you very much, Matt Tyler with Druva. Thank you. And of course, thank you to Druva for whom without this event today would not be possible. So thank you very much. Make sure you check them out at Druva. Com. Thank you all for coming today. I'm Dave Littman at Truth in IT. Thank you again for coming. And thank you, Dave for hosting. Yes. Absolutely. My pleasure. Thanks guys. Take care everyone.
