Cloud Snapshots…Magic or Just Another Tool in the Toolbox?

I had attended a presentation not too long ago that was talking about Disaster Recovery and Business Continuity Planning (DR/BCP) in the Cloud and a statistic was presented that compared the backup of a multi-terabyte database that took almost 8 hours to a snapshot which only took 8 seconds! I thought, “what is this snapshot magic that defies the laws of physics?” So, I endeavored to find out exactly how snapshots work.

Backup vs. Snapshot – High Level Overview

As you may already know; a backup is a READ operation followed by a subsequent WRITE operation to another location to create a second copy of whatever was read. This second copy could be on another disk/tape or into an object store in another data center/cloud environment. Backups require that an exclusive lock be taken on whatever is being READ to avoid any changes while the copy is being made. There are options to take “online backups” which do not require writes to be halted, but there are some performance considerations.

A snapshot on the other hand is an exact, block-for-block copy of a full disk volume at a point in time. This operation happens at the disk/hardware level, not at the application (or OS) level like a backup, so it is much faster and much less intrusive…to a certain degree. We still need to quiesce the disk that is being snapshotted and flush any memory buffers, but for a much shorter period than the exclusive lock which the backup needs for the length of the entire READ operation. To illustrate this let’s dive a little deeper into the 8-hour vs 8 second example I mentioned above.

8 Hours vs. 8 Seconds – What do you get?

After an 8-hour backup is completed, you will have a copy of whatever was the source for the backup in another location. In the case of a database, you will still need to restore the backup to a database instance to be able to utilize it.

After an 8 second, or so, cloud snapshot is completed, you will have ALL the changed blocks marked so that they can be “lazily copied” later to an object store for further processing. The crucial point here is you DO NOT HAVE A COPY of your data yet! You only have blocks that makeup the snapshot “marked.” During this part of the snapshot, all database activity must be quiesced to assure integrity of the database across all nodes. This means all reads and writes need to be suspended via a “TPASUSPEND” command. Once the marking operation is complete, which could take as little as a few seconds or a couple of minutes depending on the number of blocks on the volume(s), database operations can resume. Subsequent READ operations will continue unhindered, but if a WRITE operation attempts to change a block that is marked to be copied, the snapshot process MUST make a copy of the block before the write operation can be processed (see Copy-on-Write). For systems with heavy WRITE workloads, this could impact the performance of the workload, as a copy of each block must be made before the write can occur. There are ways to alleviate this impact by scheduling snapshots around periods of heavy write activity such as batch load windows.

Snapshot Complete…but not done yet!

As the blocks marked for the snapshot are being copied by the cloud vendor to an object store, the snapshot will show as “Processing.” I’d like to note at this point that I mentioned previously that the marked blocks will be “lazily copied.” What this means is that this part of the Cloud Snapshot process does not guarantee any SLA for how long it will take to copy all the blocks to an object store. This happens in the background based on available resources and is not something that can be controlled by the data owner.

Once it is marked “Complete,” what you now have is a copy of your volume in an object store, a Cloud Snapshot, in the same region as your source. So, you still are not protected in a disaster situation. You must now copy the snapshot from the object store to somewhere else, preferably another cloud region.

To be able to use the snapshot for recovery, you will need to allocate EXACTLY the same amount of storage, in the same configuration as was originally snapshotted and then “re-hydrate” the snapshot blocks back to the new storage volume(s). Remember that a snapshot is a point-in-time copy of your storage, so if you take a snapshot every 12 hours and retain the last 4 snapshots, then you can recover back to any one of the 4 snapshot periods that you have retained. If using for DR purposes, you will most often restore the most recent snapshot, but just know you have some flexibility, very much like with a backup.

Conclusions

Back to the original question, “Magic or just another tool in the toolbox?.” In general, snapshots are a great way to make a complete copy of storage attached to your compute nodes. They are fast and will have a relatively negligible impact on your workload compared to equivalent backup operations through your database engine. But they are NOT magic! They are just a different way of being able to copy and restore your storage to an equivalent system, whether that be in the same cloud region or a different region completely. The downside of snapshots over backups is that there is no capability for object level recovery. If you have a single, high value object that becomes corrupted, you CANNOT restore just that object from a snapshot like you can from a backup. Another downside is that the system you recover to MUST be the same in size and configuration as your original system, where a backup can be restored to a different sized system, if desired. The bottom-line is do not be confused by the “8 hour vs. 8 second” comparison. While a snapshot will take less time to create a copy of your database, it will take more than 8 seconds for you to be completely protected from a disaster.