What is a snapshot?
A snapshot captures the active configuration, memory, and storage system of a virtual machine. Any change made to VMs after a snapshot is created is written on the snapshot while the actual VM hard disk remains unaltered.
Although snapshots might look like an adequate method for VM backups, they have a few major drawbacks. This blog will explain why snapshots should be used sparingly and not considered a substitute for backups.
1. Snapshots do not actually back up your data.
Snapshots are merely differencing disks created by the hypervisor. A differencing disk is a special type of virtual hard disk that has a parent/child relationship with the primary virtual hard disk. Once the differencing disk is created, all write operations are directed to the differencing disk. The virtual machine’s primary hard disk remains unaltered, which makes it possible to roll the virtual machine back to an earlier point in time.
2. Multiple snapshots put a strain on your storage space.
Each snapshot can grow to the same size as the original virtual hard disk since the snapshot can represent the changes made to each block of the virtual hard drive. For example, one snapshot of a 100GB VM could take up to 200GB of storage space (one for the original virtual machine disk and one for the snapshot), two snapshots of a 100GB VM could require approximately 300GB of storage space, and so on. Even a handful of snapshots can put a large strain on your storage repository. Since most VM backup tools compress backups to a more manageable size, you can save space by backing up your entire environment instead of using snapshots.
3. Chains of snapshots can impact virtual machine performance.
Creating multiple snapshots causes chains of differencing disks to be created. When a second snapshot is created, the first snapshot becomes a read–only disk and all further changes are made on the new snapshot. When a virtual machine needs to read data, it must work through the entire chain of differencing disks until the requested data is eventually found, negatively impacting the performance of the virtual machine.
4. One error to an earlier snapshot is all it takes to make everything moot.
When you have multiple snapshots, the virtual machine has to go through all the previous snapshots to read the complete data. If one of the earlier snapshots gets corrupted, all snapshots taken after that become worthless as the virtual machine cannot get information from all the levels of snapshots.
5. Deleting multiple snapshots is a time-consuming process.
Deleting all snapshots is easy since the virtual machine is reverted to its base state. But if you have multiple snapshots and are using the nth snapshot, deleting the previous snapshots is time–consuming.
Let’s assume you‘re using the third snapshot. When you attempt to delete snapshots one and two, the system merges the base VM disk with the first snapshot. The newly merged base disk is then merged with the second snapshot until a new base disk is created. This process can take quite some time depending how large the original base disk is and how large each subsequent snapshot is.
6. Snapshots are not usually application–aware.
Snapshots are great as they provide a way to roll a VM back to its previous state when performing a configuration change or a service pack installation. However, there are severe limitations to snapshots when it comes to rolling back an application server. In many cases, using a snapshot to revert a database–driven application server to a previous state results in application corruption.
Snapshots can be helpful when they are used for the right purpose. But when considered as the primary source of backup and restoration, snapshots do more harm than good. It is deemed good practice to delete snapshots as soon as possible, preferably within one to three days, but no later than one week. Once a single snapshot is used for an extended period of time or you roll out five or more snapshots, your virtual machine’s performance will be affected.