Cloud snapshots provided by a cloud vendor are still the best way to protect most infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) workloads, but they are not without their limitations. The following is a discussion of the advantages and disadvantages of backing up cloud resources using what cloud vendors call snapshots.
Not a traditional snapshot
Historically, the word snapshot has referred to a virtual copy of a physical volume. It is a “picture” of the way the blocks that comprise the volume looked like at the point in time the snapshot was taken. These types of snapshots are typically taken by storage arrays and software-defined volume managers. VMware customers can also take virtual snapshots of VMs. All of these snapshots have one thing in common: they rely on the protected volume during recovery. It is a virtual copy – not a real copy. If the original volume is damaged, a snapshot that has not been copied to another location is worthless.
When cloud vendors say the word snapshot, they are not referring to this type of snapshot. When you take a snapshot of, for example, an EBS volume in AWS, it creates one or more objects in S31 that are a complete copy of the blocks that represent that EBS volume. Subsequent snapshots will be the blocks that have changed since the previous snapshot was taken. If the EBS volume is damaged, it can easily be restored from the snapshot. I would’ve preferred if cloud vendors had chosen a different word for this, but I was not in the room where it happened.
Advantages of cloud snapshots
The biggest reason to use cloud snapshots is that recovery is very fast. They can typically recover the protected resource with a single command, and the restore process runs very quickly. This means they are the simplest and fastest way to recover almost any IaaS/PaaS workload.
The cloud snapshot process can also usually integrate with the Windows volume shadow services (VSS). This means can create a Windows-level snapshot before taking a snapshot of the VM – creating an application-consistent backup of any VSS-supported application. Ask your data protection vendor if they support this functionality.
Cloud vendors can also design them to support any service that they offer. For example, AWS customers can use them to protect EC2, RDS, RedShift, DynamoDB, and many other AWS services. In some cases, cloud snapshots are the only way to protect a given service.
This is why it is important to make sure a vendor claiming support for a cloud vendor supports more than just VMs. Unfortunately, many vendors do not. They announce that they are able to backup AWS, when what they really mean is they can backup EC2. There is so much more to Amazon than EC2.
Benefits of using a data protection provider
One downside of most cloud providers’ snapshots is that they are typically designed to restore the entire protected entity. For example, if you are backing up an EC2 host, the snapshot is only able to restore the entire host; you cannot restore individual files within the host.
This is where data protection providers can be very helpful. Druva, for example, is able to do file-level recovery from EBS snapshots of EC2 instances. The backend work done by Druva to accomplish this is hidden from the customer; they see a UI very similar to what they would see from a more traditional backup. Customers get the quick recovery benefits of EBS snapshots along with file-level recovery. Make sure to ask your data protection provider if they are able to do something similar.
Snapshots stored in the same availability zone or same account as the protected resource are vulnerable to attack or damage. The most infamous story that illustrates this point happened to codespaces.com. They used AWS snapshots to protect all of their cloud resources, but they stored them in the same account.
A hacker gained access to their account and deleted their company – and its backups. This is why you should copy your snapshots to a different region and account. One good idea is to copy all snapshots to a single account set up just for backup, then limit access to that account. Since copying snapshots can be a laborious and error-prone process, talk to your data protection provider about how to automate it. This is not something you want to try to do manually.
Depending on how long you store your snapshots, the per-gigabyte price can get rather expensive if you do it for long periods of time. This is why you want to talk about moving the snapshots to less expensive tiers of storage. Talk to your service provider to see how they can help you automate that.
Migrating to another service provider
On last week’s Restore it All podcast, Chris Evans (@chrismevans) said that he didn’t like that such snapshots are designed for a particular IaaS/PaaS platform and can’t be used to migrate workloads to another cloud provider. I agree it would be nice if this were not the case, but it is important to remember that quick recovery and protecting the workloads against attacks take precedence cross-platform migration. There are also tools designed to do this – they just don’t usually happen to be data protection products.
Another criticism Chris Evans mentioned is that in other areas of IT, we have made progress in the area of application recovery. Chris likes to be able to restore an application, rather than to have to think about the infrastructure that provided that application. Snapshots assume you know the host or service that was hosting your application, which means it does not address this concern. One possible long-term solution to this might be the trend towards Kubernetes and containers because in Kubernetes you find a complete description of an application in one place. This is one of the many reasons why support for Kubernetes and Docker will become increasingly important as they both become much more popular.
Cloud snapshots are great, but they’re not perfect
Cloud snapshots are still the quickest and easiest way to recover cloud resources. However, there are some concerns that you must be aware of, and many of them can be addressed using a data protection provider to manage those snapshots. Securing cloud snapshots from attacks by copying to another account, file-level recovery, and long-term retention are all valuable features they can bring to the table. Keep your eye on Kubernetes, though, as that will probably change the landscape once again.
Learn how you can utilize Kubernetes to develop better and faster cloud applications.
1EBS and other AWS snapshots are stored in S3, but they are not visible via the normal S3 APIs.