Confessions of a CloudOps Engineer: Top 5 Backup Insights

Our favorite part of being Clumians is the opportunities we get to sit with numerous customers in learning about AWS backup needs in the cloud. Of course, we have all become Zoomers during this pandemic. Now we are sitting with them even though they are miles away physically, and we are pleasantly surprised to see how this has brought companies like Clumio a lot closer to their customers. After hundreds of hours of Zooming and enjoying a few feet of a daily commute to our home offices, it is time for us to share the top 5 confessions we’ve heard from CloudOps engineers as their application footprint in AWS solidified.

Confession 1: Backup is insurance – Didn’t know we needed it until our first incident

How many of us thought about insurance of any kind as kids and teenagers? Surprisingly, the same holds true for the CloudOps team running their applications in the cloud. The first few applications that landed in the cloud for the organization were exploratory projects. Backup was not a top priority during that time. As the business value of the applications in the cloud increased, the CloudOps team created a retrofitted backup strategy in AWS using snapshots. Then there were silos of snapshot-based data copies created by a disparate set of tools – scripts, lambda functions, storage tiering, and even an AWS backup service that orchestrated snapshots. All these were spread across 10s to 100s of accounts the organization has created to serve various projects.

One prospective customer admitted – “All is well until someone accidentally deletes something or a software glitch wipes out a key data set. Then we go through the lengthy, complex process of retrieving what needs to be restored from a large inventory of snapshots. We may survive without insurance, but it sure is painful when hit with an incident!”.

Confession 2: Backup is not just for recovery – Didn’t realize that until we were hit with an audit

While a snapshot centric AWS backup strategy checks the boxes for creating copies of data, CloudOps team admits that those strategies do not fulfill all their compliance and security requirements. The key problem is the lack of visibility into data itself spread across 1000s of AWS snapshots. When it comes to regulatory compliance for AWS assets at some point in time (no pun intended) the team has to prove that a file or database record can be reproduced from a very specific date and time

CloudOps engineers have walked us through their painful, manual processes that can take multiple hours just to retrieve a file or record to satisfy audit/compliance requirements. The process can be summarized as– find the correct AWS snapshot; turn the snapshot into a real instance by attaching compute; search for the file or record; and finally retrieve the file or record to a shared location. They would take screenshots throughout the entire process to create the proof points for reporting needs.

Confession 3: Backup is my last line of defense – Didn’t know that we needed to guard our backups

Oftentimes, the shared responsibility model of AWS is something completely overlooked when it comes to snapshots as AWS backup copies. AWS account is a single point of failure in the shared responsibility model. If I keep my snapshots in the same AWS account where my production is, it is technically NOT a backup. If my account is compromised, there goes both my production and backup data. Wait…what?

Then we retrofit yet another layer of snapshot management to solve that problem. We find ourselves creating scripts that would copy snapshots across accounts. Then we realize that we may have to re-encrypt before copying to avoid sharing production keys at the root level. This adds yet another layer of complexity. Soon, we find ourselves at sea. AWS snapshots are a data availability solution, and we had been trying to make AWS snapshots a true air-gapped backup solution.

Confession 4: Spending a ton on snapshots – Didn’t realize those small cents were adding up fast

This brings us to the conversation about money, cloudops teams pay a lot on their snapshots. They end up paying way more than they need simply because they have zero visibility into their snapshot footprint, and even when they do, they are not sure if any of those can be safely deleted. They hang onto all of them until they get that call from their finance team asking why costs were high and increasing month over month. Sound familiar?

Confession 5: Satellite vision matters in clouds – Else we couldn’t see the forest for the trees

As CloudOps engineers, we are wired to pay attention to the details. We like to dive deep. All of us operated at the account-region level in the AWS cloud. No one was looking at the full picture across various account regions. High-level visual inspection can be quite powerful, and this is 100% the case when it comes to protecting data in the cloud.

At Clumio we obsess about our customers, and we have made significant progress in solving the five pitfalls CloudOps engineers had to deal with the hard way. Now, with Clumio…

• You get true data protection for your assets in AWS – it is an insurance policy that covers your business running in the cloud.
• Your backup is not a sunk cost – unlock the value of backed up data to meet audit and compliance needs.
• Your backups are air-gapped away from production – Clumio guards your backups, period.
• Your wallet won’t bleed because of snapshots – As a customer, you would be saving up to 60% over traditional snapshots.
• You get 20/20 vision, you know, the good kind – The year 2020 was bad, but your visibility into snapshot footprint has gotten better with Clumio. The power of visual search and insights.

Let’s schedule a 1:1 demo today!  Can’t wait? Start your 14-day free trial