Why Agentic AI Makes DynamoDB Backups Mandatory | Clumio (Commvault) CTO Explains the Risks
Transcript
Uh, I love having these CTO conversations. We have the CTO and founder of Clumio, now the CTO of Convaults Cloud Native Division, W Jumble, right? Yep. Welcome to the CTO advisor CTO dose. The team reached out to me to record this uh sponsored content to talk about Dynamo DB and why should I even as a developer in the agentic AI setup be worried about backing up Dynamo DB. Can you walk us through why that's even a thing? What's the problem?
Yeah. So the well first of all the agenti changes the behavior of the applications right the applications are more autonomous adaptive and they cannot take actions without human intervention. However what it doesn't change is that it is only as good as the input data. In other words you know is really garbage in garbage out. Okay right but what we should think about and it's about the the the amplification factor. Uh this agentic AI uh allows you to implement amazing things and do things really really fast which amplifies the value but at the same time it also amplifies the potential accident small accidents.
This LLMs could actually very quickly make it into a big accident. So, Dynamo DB uh which stores things like you know customer data states and even things like LLM intermediate states corrupting that table could actually have uh very catastrophic uh consequences for the enterprise. >> So I have firsthand experience with this. I've been doing a lot of agentic AI based application development and I use git as my workflow and I'm accustomed to using git every time I make a major or even a minor change.
It's simple to just write that change to my git repository. >> Learn the hard way. When you introduce a e a e a e a e a e a e a e a e a e a e a ejectic workflow into your development the agent can go rogue and it deleted it dropped a table from my database and when I challenged it on it said oh yeah sorry made a critical mistake and dropping data that wasn't backed up okay so that wasn't part of the workflow talk to me about the gap in the existing workflow that you received yeah so uh to say that Dynamo DB uh does not have versioning at all.
It's a little incorrect. So uh Dynamo DB which you know let's say is this table here has a feature called uh pitter. So think of pitter be more of a transactional wall. So that all the updates that happens it also gets not only updated into the table but into this log here. So then as a user you can leverage that log to create a brand new table of as a specific point in time. m. and you want to go back.
m. Sure. This is going to be more of a rudimentary versioning, right? Very similar to what you're talking about. It lacks some of the functionality, but it is a good starting point. >> Right. So, where does Kumio come in? What what advantages am I getting on top of what this pitter process I had with Dynamo DB? >> Yeah. So, there's a couple of things. Let's start with the very first one is air gap. Being able to create a discrete copy of your table.
Mhm. >> Like I said, you could use that uh pitter table to create new tables, >> right? But this is within all of your tenency. This whole thing is within your own uh tenency. Meaning if a malicious attacker were to have access to that table or to this whole account, guess what it could >> I can do either or the table, I can do I can I can uh attack your backup. >> Yeah, that too. And then it's as simple as uh disabling pitter in which case you could actually end up losing all of that pitter.
In that point you don't have the capability to go back in time. Okay. So then what you want to do to protect the data is to create a separate copy in a different entity al together to actually create a backup. Right? So that allows you to do you know you would have an independent copy. So am I when I back up am I backing up the entire uh database and including the logs and and pitters or am I having an additional level redundancy or am I just backing up just the database itself?
>> Yeah so that's a great question. So uh first of all yes we we'll back up basically this will be fluio and then this will be your uh AWS 10z correct and then when we back up we'll back up the entire table but we'll also do what's called an incremental backup because this table is not a static table but you're continuously changing right so we'll actually go ahead and do that the now coming back to the air gap again the benefit of this approach is that even if your account tier which is your ten gets compromised, you have the second table that you can actually restore from.
>> So, I want to make sure I'm clear on this. This is happening in my AWS VPC. >> Yes, that's yours. >> With with everything that with all of my access control and my tag surface is here. >> I'm completely copying this over to a completely different environment that doesn't have the same control plane as my AWS control plane. >> Yep, that is correct. So then anything that happens here will not impact your backup data on this side at all.
So this was good backup hygiene. I I'm accustomed to this. Let's bring it the discussion back to agentic AI. What are some of the practical agentic AI uh use cases that we're see? So before we go there, so let me just kind of show these other questions about what you know brings to the picture, right? m. m. And let's say >> right that's that's actually my my recovery point. You know what we have to capture all of those things.
So what we do is we capture what's called incremental backups right so let's say the initial table was one terabyte in size but then every hour you know it wouldn't change much you were changed the entire terabyte let's say you know 100 megabyte changes every hour and we'll actually capture that incremental backup. So one of the differentiations that we had uh as compared to the AWS backup or the native solution is that AWS backup allows you to do something similar. However, the challenge there is that all of the backup happens to be a full backup.
So what you're forced to do is let's say hypothetically our requirement is to keep seven copies one copy per day because you want to go back to let's say Monday or Tuesday or whatever. So you're keeping the last seven days. What that really means is that you're actually retaining seven full copies, which means that you're not retaining one terabyte and multiplied over the number of copies of that. >> Yeah. So you have to multiply the seven terabyte the one terabyte multiplied by the seven copies rather than having one terabyte and seven incrementals which are much much smaller.
>> And from a practical p perspective, how does that impact recovery? Well, recovery from a recovery standpoint is not uh it doesn't impact it at all. But one thing that you this will drive TCO, right? Right. You're not paying 7 terabytes, but you're paying seven one terabyte plus let's say 700 megabytes. >> Okay. >> Which is drastically lower than the 7 terabytes, right? So that's TCO. I did not I actually did not know that about AWS backup that it did a full backup every time it does a but Yep.
That's what it does. And then now you talked about the the recovery modality which is actually uh again a very important concept here. Now another gap that the built-in native solutions have is the different flexibility when it comes to the restore mode. Like I said before, you could always restore a full table, right? It's a new full table, but it doesn't allow you to restore partially like you can't restore like I think you also talked about some of the accidents, right?
Let's just go through that accident or that that that exper that uh thought exercise, >> right, to go through and just kind of outline the differences. >> Let's say that we have this table and this is your production table. Okay. And then uh Dynamob organizes data in what's called partitions, right? So let's say I have in this case uh six partitions. Okay. And then this stores customer data. Partition zero has data related to uh user zero, partition one, user one and so forth all the way to user five and partition five that stores data for user five.
Gotcha. Okay. m. m. Okay. >> Yeah. And I have and in the inter room I have all of these legit transactions between here and here. >> Yeah. So customer zero, you know, two, three, four, they're perfectly fine. They're all happy, but customer one or user one and user five, they got impacted right at different points in time. m. m. So, what we need to do is to actually go ahead and patch these things here.
Patch the user one and patch the user five. It's very similar to your git uh example that worry me like you know you made a mistake in a single file. You want to revert that one file, not your entire source. Or I can have my agentic AI or my uh developer look at a precision specific block of code and recover that specific block of code cuz it's a manual process but still I can I can do that. But that's kind of this is the problem statement that we have to go and and fix.
So I want to make sure we drill into this because I assumed AWS backup takes care of this level in the traditional infrastructure. just call it brick level backup that individual records or individual partitions we could recover. There's different recovery points for within that. So you're saying if the end result is that if this corruption happened my only real option with the AWS solution is to recover the entire >> Yeah. So then like >> they just had to reconcile between >> there's a couple of options right they say you know put aside from mate.
So what are your options when you're faced with this type of accident here? So number one is that okay well let's just go ahead and do a full restore because that's what I could do right. m. m. Okay. m. >> Right. And these are the the all the six partitions. Now you could actually change the applications to directly use this table and get rid of this old one got reupted. >> Is that functional? Yes. Well, you could argue that it's functional.
But then what's the problem with this? The problem with this is that user zero, two, three, and four, they were perfectly happy. m. pointlessly, >> right? >> Just to fix that one customer. >> Or I have some manual process. I could automate it but I have some process that reconciles the two partitions but that again adds complexity. >> Then what do you need to do like exactly like you said we have to take partition one from this new fully restore table.
We'll have to do a copy. Okay. And then what we need to do is we need to do yet another full restore because remember that the accident happened at different points in time. Right. >> Right. So then this one it's a 5pm and then we will have to take uh partition five which is uh this one here and copy it here to so two full v stores two full and two copies you have to cherrypick partition five you have to cherry pick partition one and once this all done you have to go ahead and make sure and delete all of these tables and then you able to recover all this yeah I'm I'm already getting into operations nightmare I've done enough disaster recovery testing to know if you don't remember to go back and delete the yeah the temporary partition somehow this becomes live production and that you're in a world of trouble.
So now talk to me about how Kumio changes the operational motion of doing a recovery based on kind of this two two point scenarios to okay got it. So first one you know just to recap uh is the fact that this is an air gap copy the fact that anything that happens here nothing will happen to your backup. So it's really air gap and related to air gap because we do these incremental backups is really reduces your TCO right and then the second thing is we still allow you to do pitter which is you know we allow you to pick any point in time right could be two five or you know whatever up to the second gallary middle of things so pitter p uh we allow you to do what's called the granular restore what that means is that you know I can allow you to restore a single partition a couple of partitions or even a single item.
So let's just call it no granular gran restore. And then uh lastly uh we implement what's called either out of place or in place restore. in out of place restored. So uh so it's a combination of these three. So let's say let's just let's combine these things this uh this uh let's say these features to go ahead and fix what happened here. No. Now you as a user if you had this MX accident but you were protecting it using Glumio all you need to do is read it two API calls.
m. >> right from here to the in place what's called it's not an out of place but will allow you to in place restore. So then the first API is going to say take this which is you know the partition number one and restore it directly into it. m. one API call and then the second API call will say partition key col five as of 5PN. So there's no need for you to this full restores to copy things over to delete things over.
It's just two API calls and then you are able to patch it and go. So, couple of questions. First off, obviously this is an immense capability. I don't have to restore to a to a offline copy and then make my changes and come back on. I can recover straight to production if I want to. I get the granularity of at the partition level which is also great. But users are going to automatically think okay what am I sacrificing? Am I sacrificing any uh consistency in the database?
>> Am I are there any sacrifices? How much can I trust this process if I want to restore to production? >> In terms of sacrifices, honestly, I don't think it's actually hard for me to come up with any downside or sacrifice. >> Uh it's actually solves both the TCO, the fact that is air gap, and these are all great features. I don't think there's main like concerns or sacrifices that you would have to make. >> I'm not going to push back hard because I thought this is how it should have worked from the beginning.
I'm sure you run into that uh that scenario with customers all the time. I I would say that one maybe one last thing if I really have to come up with something is that really pitter is a built-in functionality of the dynam table and depending what you want to do uh pitter is also a good functionality maybe uh for the use cases where this is good enough where an inac account protection is just good enough and it gets the job done that's where you just end the day that's it >> so I'm there's this obvious question that whenever I use a service that is outside of the AWS container.
What is my developer experience? What what does this look like to the developer? >> Oh, to the developer is uh technically developer or the S sur organization is the way that you onboard Kumio is through either cloudformation template uh Terraform or APIs. So then what we do is obviously when we're extracting and restoring backing up and restoring data uh we rely on what's called an IM role. We need an IM role that has to be in the customer's tenency. So I say this is your IM role that has to be created which has uh a policy attached to it.
It it is the policy that allow us to either back up or restore data from the source account back into this clumier account here. Now from a developer standpoint, all you really need to do is to actually install a cloud for template or a terraform to actually go ahead and install that IM role. Once that is in place, you effectively onboarded Clumia to your AWS account, >> right? >> The next thing that you need to do is to go ahead and start applying policies.
So this isn't impacting my actual day-to-day development and development experience. I am just oversimplifying flipping a switch on my uh to now Clumio have access to my uh from IM to my AWS container. >> Yeah. So on a day-to-day basis as a developer is something that you don't have to worry about it is you know that the data is protected. So all you need to do is just go on writing you know the things that matter the business logic the application that is important to the business and then the backup is just basically taken care of.
So last question for IT decision makers what's two or three major points that they should be asking when it comes to Dynamo DB specifically to backup and data protection. So one thing is it's really about come uh making a decision based on the the type of data. So you have to know you have 100 tables you have to make a call what tables are important and what level of protection do you need to do right is per good enough or maybe there's a requirement to create a second copy.
So then you would have to make that decision and create a solid protection plan right as a a goal that's uh that you have to go and then once you have that let's say out of those 100 table we did identify that you know 50 of them require a second copy okay great once you do that there's different tools that you can actually use AWS has some that are native from AWS backup clum of course we have our own then you have to start asking the questions about you know TCO Yes, I can create a discrete copy.
What does it mean to the TCO? Is it am I creating seven full copies or 30 full copies or am I actually creating one full and many incrementals which you know TCO third thing is that we talked about all of this exercise. It's not all about backup. You have to think about you know how do you restore it back when it's time to restore because accidents are always a lot more complex right? It's not as simple as hey you know this whole table goes away therefore I'm going to replace it.
It's never that way. It's always a partition, you know, got corrupted and stuff like that. In which case, you resorting to something very complex for you to do the restores. It's not like they will come and give you basic functionality, but you as a user, you would have to write all of this automation yourself. Then think about that like when it is time to restore and these are not like the simple hey simple accident because again accidents are complex. Think about how you're going to restore it.
All right. Well, I hope you enjoyed this exceptional example of where AWS ends and AWS ISB infrastructure comes into play and these partners help solve a lot of the operational gap. com. Obviously, Kumio is now part of Convalt. com. Thanks for tuning in.
