One of the trickier parts of getting started in a new cloud environment is getting used to all of the jargon that is immediately thrown your way. One of the things that seems to be a big source of confusion in the virtual world, especially in DRaaS, is the following set of three important concepts: Snapshots, Backups, and Replication (not to mention the words that tend to quickly follow like failover test or live failover). We know we want to use them, but we don’t know exactly which one we need and at what time.

This guide is a simple introduction to each of these concepts, and helps to explain the differences in clear, simple terms. We will discuss what each one is, isn’t, and how you might want to use them in your environment. First, let’s tackle Snapshots. I’ll handle the other two in the coming weeks. 

Snapshots – What they are:

A snapshot is a way to “freeze” a live VM at a moment in time, while still being able to make changes to the machine. If you make the changes, and the machine bites the dust, you can choose to reject those changes, and the machine will be restored back to the time of the snapshot creation. This is especially useful when making changes to a single VM that you may want to roll back, like a small hardware change or an OS-level update. 

Think of snapshots like a “Save Point” in a video game. You always want to make sure you have a recent one, right before you go into battle against the boss. It’s really useful to have a nearby checkpoint that you can go back to if things don’t work out the first time, but once you’ve conquered that challenge, you don’t really need it anymore.

It works the same way with a snapshot. Once you have verified that the changes were a success and the machine is alive and kicking, you no longer need the snapshot. You can choose to accept the changes, they’ll be written back to the original disk, and the VM will be “unfrozen” and continue on its merry way, likenothing happened at all. Or, if the battle did not go your way, reject the changes and delete the snapshot, and your VM will return to its former self. 

What happens on the backend is a little more complicated than that, but that’s the gist of it. What you should keep in mind is that just like a “Save Point” in an older game where running of out storage on your system was a problem (PS1 Memory Cards, anyone?), the same is true of keeping snapshots in your virtual environment. Except, instead of a few scattered, reasonably-sized files here and there that you later need to clean up manually to make room for the next game, Snapshots can expand exponentially in size, much quicker than you might expect. This is particularly true when there are a lot of changes to the data on the machine after the time that the snapshot is first taken. Database Servers can be a nightmare of storage-devouring havok waiting to be unleashed on your environment, if you aren’t careful. This is why it is important to remember that a snapshot is a living, growing, hungry thing, and you should always try to handle them as quickly as possible. iland recommends STRONGLY that you do not keep a snapshot running for more than 24 hours unless you absolutely have to, and even then, be prepared for some of the possible headaches noted.

For those of you who want something a little more technical:

• When you choose to take a snapshot, a new file is created on the backend that all changes are written to, instead of the disk. 
• This file grows as changes are made. 
• When you choose to either accept the changes, or to delete them, the contents of this file are either written into the original disk (which was “frozen”, remember?) or deleted. 
• Once this action is complete, the machine resumes writing to the original disk file, and the “snapshot” file is no more. 

Because of the way snapshots are processed, there is never a full second VM created. And, since the file is deleted once you make your choice, you can’t go back to a snapshot at a later time. Like all of my save files from an unfinished playthrough of Final Fantasy III: once it’s gone, it’s gone.

Snapshots – What they aren’t:

• Snapshots are NOT a backup method. They are used to save a point in time TEMPORARILY, not for a long term solution. If you are looking to create a copy of a VM to store, then you want a backup, not a snapshot. More on those later. 
• Snapshots do NOT create copies of VMs. It’s just a file that enables a machine that already exists to be returned to a previous state.
• Snapshots are created manually, and should be created before any work is done. They are not a method for quick restore UNLESS you have already taken one. 

Next up, we’ll tackle Backups and Replication – after which, you’ll have a full arsenal of tools for ensuring the continuity of your VMs.