Some say that the best things in life are free, but when it comes to data protection in the cloud, free might only get you part of what you need and cost more in the long run. At the end of the day, it is good to have options and review the pros and cons of any data protection solution in the public cloud to ensure you are getting what you need at the lowest cost. In this blog post, we are going to detail out the pros and cons of snapshots in AWS, why to use Clumio’s free tier for operational recovery, and how to configure snapshot management in Clumio’s backup as a service for Amazon RDS and EBS we announced a while back. Let’s dig in…
I am sure that many people thought to themselves, “what is Clumio doing providing free snapshot management capabilities since snapshots are not backups?” You are correct, snapshots are not backups, but they do have their place in the public cloud. Snapshots are an awesome operational recovery mechanism for applications that need point-in-time recovery in AWS. Operational recovery might be the only requirement if you are an early cloud adopter, or for most, it can be part of a broader holistic data protection solution that requires backup of data with longer than 14 – 30 days of retention for compliance requirements. We are providing this snapshot management capability for free to our customers, versus charging for it like many of our friends in the industry. It is only part of a complete data protection solution in the cloud. Although I think they should rename it to AWS Operational Recovery instead. 🙂
What are the pros and cons of snapshots in AWS and why are they not backups?
One of the major pros with snapshots is the ability to quickly restore from mistakes, accidental deletions, or data corruptions. On-premises snapshots are typically stored on the same array or application infrastructure as the core application to enable quick recovery. In AWS, snapshots are stored in the same AWS account as the production data. No matter where these snapshots reside, they are typically kept for relatively short-term durations as their value diminishes over time for operational recovery.
Beyond snapshots, backups are required to be held outside the production environment to ensure you have access to your data, even when the production infrastructure goes down or has major issues. Backups are also stellar at fine-grain recovery as they are indexed and cataloged for quick granular retrieval outside of production. Compliance backup goes even further, as it needs to be kept for legal or compliance needs, which need to be protected even when an entire site or account is compromised.
One of the major cons of snapshots is they fail miserably in both functionality and cost when used for backup and long-term compliance. For example, let’s say you have a new application you developed or moved from on-premises that has a requirement for 30 daily backups and 12 monthly backups for long-term retention. Snapshots are stored on the same account as the production data, so if you fat-finger a script, delete the wrong thing, or a bad actor gets access to your account, you lose the backup and potentially the data. This is obviously bad. To avoid this vulnerability, you could always replicate these snapshots to another AWS account for safekeeping, but then you get hit with transfer costs, twice the snapshot bill, and if you are using PaaS services such as RDS you will be required to keep full copies versus chains of snapshots. Since none of the data is indexed or cataloged, now you have to restore the entire thing and find the data yourself. Getting the data back is painful as well, but the costs alone in this scenario makes snapshots unusable.
Why use Clumio’s Free Tier for Operational Recovery instead of AWS Backup or snapshot managers?
Clumio’s backup as a service for native AWS services provides a holistic data protection solution well beyond snapshot management. As you proceed along your cloud journey, Clumio can provide a single data protection service for any enterprise needs. Maybe today you use snapshots for operational recovery in a testing and development environment. When the application goes into production, the requirements change and you need more protection, yet you don’t want and probably didn’t plan for massive costs with snapshots. With Clumio, you can leverage our unique air gap protection, full indexing and catalog, and granular restores of files for EBS or granular record retrieval for RDS via direct query access to our data lake. The experience is stellar and can instantly be turned on for any application requiring these features beyond snapshots. The best part is all of this is delivered at up to 50% less cost compared to AWS snapshots.
What is the Clumio experience for snapshot management?
As with everything at Clumio, the experience is simple and getting up and running takes only 15 minutes. The first step is to create your login, which is as simple as inputting an email and password. Afterward, you input your AWS account information including AWS account number, account description (so you can remember), AWS region, and click next, then launch CloudFormation Stack wizard:
This will kick you over to AWS to create the stack. Click Create stack and wait about 3 – 5 minutes to complete.
Once completed, your account will run through inventory services. You can run the same process on all our other accounts you want to protect as well. Once you are done, the next step is to create a unified policy across EBS and/or RDS.
Define the policies for up to 30 days for EBS or up to 35 days for RDS:
Clumio leverages existing tags for aligning policies, so the next step is to determine the tags you would like to protect with your new policy you just created. This makes life very easy so you can tag specific resources and they will be automatically protected with this policy.
That is it! Now you are up and running with Clumio’s free tier for operational recovery for both EBS and RDS.
Now that we have operational recovery available for EBS and RDS, let’s review the restoration process for EBS. First, you pick the EBS volume you want to restore, then define the point in time you want to restore. In this case, I have backups (shown in blue dots) and snapshots (shown in orange dots). When you click on the date it will give you options for both.
You can then restore the volume to any AZ available.
RDS is a similar experience, but slightly different as there are multiple options for the protection of RDS available including rolling backup (time-lagged RDS instance in Clumio) and granular record retrieval (long-term backup).
First you pick a restore date where there is a snapshot available (orange dot), click recover, then pick the point in time of which you want to recover the database, down to the second. In this case I am restoring to 5:04:04 AM.
As you can see in this quick overview, protecting AWS resources for operational recovery is incredibly easy! No matter if you are developing net-new applications, lifting and shifting legacy applications from your on-premises data center, or a cloud-optimized veteran with 100% of your applications running on the cloud, Clumio has a solution. For more information, check out our backup as a service for Native AWS resources.
Until next time, stay SaaSy my friends.