# Clumio Expands to Google Cloud: Multi-Cloud Data Protection and AI

**Podcast:** The CTO Advisor
**Published:** 2026-04-23

## Transcript

All right, you're listening to a really special episode of the CTO Advisor podcast.
We're here in beautiful Las Vegas at the Manly Bay doing Google Cloud Next.
We have a returning guest from the Lightboard series, Wung Jung, CTO of Clumio.
Wung, welcome back to the program.
Oh, nice to meet you.
Then?
So you folks have...
I don't think you coordinated this.
Google Cloud Next is all about data, data to support agentic workloads.
But you folks specifically had timed an announcement around data protection for Google Cloud Next.
What's that announcement?
We're at Google Next today to launch the support for GCS support, basically the backup of GCS.
We've been with AWS.
For some time now, for the last eight years, we've been just solely focused on protecting data sources on AWS.
And this will be our first venture into GCP.
So there's a bunch of data problems to solve around not just AI, but traditional workloads.
You folks have your hands full with AWS.
Why Google Cloud Next?
Literally, why Google Cloud Next?
Not just the show, but why?
uh tackle the google cloud uh challenge next this really uh we follow the customers is really what they asked us to do is what we're working on literally uh so over the last again five six years we've been working with a lot of the customers and then they've been asking us like they've been asking us to actually provide the same experience and service that they have in aws in gcp because they themselves are actually multi-cloud many times.
And then that's what made us work on GCP.
So what's different about GCP than AWS from the approach?
Because when people look at this, well, this is just object storage.
What makes backing up object storage hard from one cloud provider to the next?
Obviously, honestly, a lot of the thing is common.
is very much similar you know a lot of the you know public providers are converging and then there's small differences here and there that we have to handle it but that's the you know that's what we do like a lot of the learnings that we had from aws we're going to bring it into gcp and also along the way address some of the differences so that you know our customers don't have to deal with that at all And specifically in the context of our launch of the GCS support, today Google doesn't have a native support for GCS backup.
If you go back about five years ago, it's actually very similar to what we experienced with AWS.
When we first launched the support for STD backup with AWS, AWS didn't support STD backups.
It took them a little bit for them to launch.
And even after that, once we launched, a lot of the customers used to tell us, you know, why bother protecting SD?
I have replication.
And I'm guessing that a lot of the stuff, similar things will happen with GCP.
It's in early days.
We're going to get questions about, you know, GCS supports replication.
Isn't that enough?
Why do we need backup?
You know, it is the initial innings.
We're going to go through the same journey, but I expect the same things to happen over time where people will realize that the data in GCS needs to be protected beyond just replications because those are two different solutions that solve two different problems.
So there are folks that are natively born in GCP.
I found this an intriguing part of the conversations that I've had while I've been here at Next is that there are folks that's never used a different cloud so they're coming to this exact problem for the first time like the they're born in the cloud not just born in the cloud they're born in the gcp so they have no point of reference talk about some of the failure domains that you're protecting as a result of uh going beyond just replication yeah i know so in the case of uh replication you know like whatever happens in the source bucket gets replicated to the To the destination, right?
Whatever you're replicating to.
Correct.
Whether that's a malicious attack or whatever, intentional deletions or unintentional deletions, everything gets replicated over.
So then while replication solves the problem, really like the name says, it solves the problem of availability.
When you actually lose one region, you have the other bucket where you can pick it up.
But because every operation that happens on the source gets replicated on the destination, if let's say things get deleted or corrupted, that exact same accident happens on the replica which doesn't really help you in that case and moreover replication keep the latest copy because you know as you make changes on the source it happens on the destination but if you want to time travel like many times you know an accident happens let's say five hours ago you want to you know time travel to five hours ago you can't do that with replication and that's kind of where backup comes into the picture so replication protects from failures but not necessarily from corrupted data or the or some business challenge where you need to revert back to a previous copy of the data and this is this is the escape yeah exactly it's completely different like you know you can't call replication a backup just like i won't be calling backup replication it's different solutions so a lot of the conversation around customer use cases have been multi-cloud google is exceptionally adept at helping customers connect to other clouds.
So what's really tempting is to now look at my data landscape from an entire multi-cloud view, operational view.
Can you talk to some of the unique challenges with Google Cloud or even the commonalities between Google Cloud and AWS when it comes to operations of data protection?
So a lot of the things are Well, outside of the fact that, you know, there's things that are supported in AWS, but not in GCP and vice versa, there's small differences.
But again, that's what Kumio is about in solving.
The idea is that no matter where you are, whether you are in GCP or in AWS, you configure a single policy to back up the resources either in AWS or in GCP, the same way you do it in AWS, you do it in GCP.
Whether that being policy, whether that being APIs, configurations, or terraforms, everything that you do through Clumio, we hide that behind the scenes.
So you're just managing AWS like you're managing GCP or vice versa.
So we're in the world of AI, and everyone wants there to be an AI use case.
Most organizations I know that you're talking to are just trying to get their data together, like this whole data protection.
I need to know how to protect my data before I talk to them.
talk about moving it.
But there is this desire to move data.
How are customers embracing or what capabilities are you giving customers operationally to approach multi-cloud either data movement or data protection?
Yeah, so today we don't actively go ahead and move data between the cloud.
But what we go ahead and do is basically simplify the management of it.
It's like you treat AWS, no different than GCP.
Clumio, single portal, single policy, single API in Terraform and configurations.
And you get the same experience.
Despite the two cloud providers being slightly different in terms of what they support and the characteristics and all that stuff to get scale and performance, you have to do things slightly different.
In the two cloud providers, we hide all that for you.
You just have to configure it in one place.
There's no tools that you have to manage.
There's no...
things that you know it's just one thing that you have to get it right the customers i'm talking to are really worried about ai threat protection like malware is becoming real they you know we used to have security by obscurity hey i'm a small company no one's going to find my unsecured endpoint to maliciously attack, Mythos is changing that conversation.
If you have open endpoints, if you have vulnerabilities, a $20 spend in AI tokens will find that.
So the need to protect my data is even more...
prevalent.
As you're talking to customers, how has the conversation changed, if customers are even keeping up with it, how has the conversation changed around protecting their workloads from malicious malware?
A lot of the stuff is still the same.
Sure, we're talking about AI and Argentic and all that stuff is a theme.
But then the need to protect the data and all that stuff is still pretty much the same.
Yes, you know, AI, LLMs and all that stuff.
But, you know, at a high level, the way I see it is, you know, really garbage in, garbage out.
You have to make sure that the data is well protected.
The only difference, like you mentioned, some of the blast radius gets wider just because, you know, accidental deletions previously were done by a human.
Now it could actually be done by an agent that could actually expand the blast radius.
But really, it's about the same thing.
And the other thing that I started noticing, which is, if you think about it, some of the data that has been sitting in S3 or in the case of Google GCS, AI turns out to be a huge unlock.
Because these are, let's say, a bunch of text, a bunch of blob data that sits there that you couldn't extract value out of it.
With the AI, now you get an opportunity to extract value out of it.
It just becomes a huge unlock.
And some of the things that, you know, it wasn't important before, now people start caring more about it.
Moreover, specifically, you know, if I'm actually going and designing some of the applications, before there used to be data that, you know, things like log files, things like auxiliary data that, you know, I used to...
look at it and I say, okay, you know what?
We're never going to need it.
So let's just go ahead and delete it.
But I get to keep all that stuff more and more because I know that in the future, leveraging AI, I should be able to check stack value out of it.
So a little bit of that is changing, but then at the same time, protecting the data is a constant.
All right.
So you just...
unlocked something that I really didn't consider.
This ability that AI is allowing me to utilize my data, my log data, which I thought was useless.
Now I can put analytics against that data and get insights that I couldn't get before.
But there was always a cost associated with not just keeping that data hot, but keeping it backed up.
How are you helping me with cost?
Not just in...
GCP, but across GCP and AWS because I want to keep the same logs that I'm keeping in AWS.
I want to keep that same telemetry data that might be slightly different, but I want to keep it in GCP as well.
Yeah, so the way that the way that Kumia will support it is through giving you different tiers, right?
So you can back it up into the what we call the standard tier, which is, you know, hot backups, right?
If something happens, you can get it back immediately.
But then we also have what's called the archive tier that, you know, at a much lower price point.
But obviously when you need it, you do have to wait for the towing time, right?
So we'll actually help you with those two tiers.
That is really about trade-off, right?
In between, like, you know, you talked about how much does it cost me to maintain the data?
And what's the trade-off in between the two?
Like the other trade-off is the value, like how much, you know, value you assign to that data and, you know, how much does it...
cost you to keep it around.
Now, I think with the AI and what happens, the value that you can extract out of it, that went up a little bit.
Now your motivation to keep that data a little longer equally just goes up a little bit.
And I'm not saying by no means keep every data, but now it increases the surface area.
And I think this is where we're leaving.
The call to action isn't the...
traditional, hey, if you want to learn more about Clumio, I think it's more, if you want to have these deeper conversations, if you want to have the conversations about the trade-offs, if I want to use my data as an operational tool, as I'm starting to look at agentic AI and where is data being leveraged, where should I place GPUs, should I invest in Bedrock versus BigQuery, all of these questions become architectural questions.
And these are questions, I think, CTOs and their staffs are better suited to help directly with Clumio.
So the call to action isn't just how do I learn more about Clumio, but how do I help organizations solve this problem?
And I think the easiest way to do that is, what's the website?
Very easy, clumio.com.
So not clumio.io, which is what I wanted to say, but clumio.com.
If you want to learn more about the CTO Advisor, you can visit us on the web.
We now own ctoadvisor.com after 10 years or the traditional website, the CTO Advisor.
You want to follow me on the web and you want to ask me the questions, I have an ax wound.
DMs are open at CTO Advisor or on LinkedIn.
Talk to you next CTO Advisor podcast.