Editor’s Note: As of January 2022, iland is now 11:11 Systems, a managed infrastructure solutions provider at the forefront of cloud, connectivity, and security. As a legacy iland.com blog post, this article likely contains information that is no longer relevant. For the most up-to-date product information and resources, or if you have further questions, please refer to the 11:11 Systems Success Center or contact us directly.
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 concepts: snapshots, backups, and replication (not to mention the words that tend to follow, such as 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. We’ll handle the other two in the coming weeks.
What is a snapshots?
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 like nothing happened at all. Or, if the battle did not go your way, reject the changes, 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 need to clean up manually to make room for the next game, snapshots can expand exponentially in size more quickly 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 havoc 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. 11:11 Systems 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 a more technical explanation: 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) 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 our save files from an unfinished playthrough of Final Fantasy III: once they’re gone, they’re gone.
Snapshots are NOT a backup method. They are used to save a point in time temporarily, but are not a long-term solution. If you are looking to create a copy of a VM to store 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.
