Having a clear picture of what VM snapshots and backups can do for you is critical when your data is at stake. To dispel any doubts, snapshots are NOT backups. They are two different processes designed to address different needs. Today, I’m going to explain the discrepancy between VM snapshots and backups and provide you with a few scenarios where each of them best fits.
While it is true that many Veeam products will use a snapshot as part of a backup — a snapshot by itself is not a backup. This logic applies to VMware VM snapshots, Hyper-V checkpoints and storage snapshots as well.
How do snapshots work?
In a nutshell, a VM snapshot is the process of saving the data state of a VM with the possibility to revert to that point in time. The VM can be powered off, powered on or suspended when snapshots are taken. Multiple snapshots are organized in a parent-child hierarchy.
Usually, snapshots are used to test software updates or for unsafe operations on a VM, and then returned to the initial state if needed — think about it as a bookmark or an undo button. Snapshots are not a full copy of the base disk, therefore, they are not sufficient to restore a VM in case of storage failure.
VMware snapshots
In VMware VMs, the virtual disk is a .vmdk file residing on a data store (LUN). When a snapshot is created in Snapshot Manager, the original disk becomes read-only, and all the new data changes are written into a temporary .vmdk delta disk, pointing to the original one. The delta disk is the difference between the state at the moment when the snapshot was taken and the current state of the virtual disk. The process of taking a VMware snapshot also involves the creation of two additional files: snapshots and metadata information (.vmsd) and the running state information (.vmsn). After a snapshot is deleted (committed), all the changes are merged to the original .vmdk file, and it returns to read-write mode.
Figure 1. Snapshots in VMware vSphere client
To ensure a healthy use of snapshots in vSphere virtualized environments, VMware provides several best practices:
- Use a maximum of 32 snapshots in a chain, but for better performance, use only two to three snapshots
- Don’t leave a snapshot running for more than 24 – 72 hours. It will increase in size, and your storage can run out of space
- Do not use snapshots as backups. If the original virtual disk is deleted, you cannot restore a VM from snapshots
Hyper-V checkpoints
Things are slightly different with Hyper-V snapshots (renamed Hyper-V checkpoints starting with Windows Server 2012 R2). When a Hyper-V checkpoint is created in Hyper-V Manager, the running VM is paused and an .avhd(x) differencing disk is created in the same folder as the parent virtual disk (.vhd /.vhdx) to stock the changes, along with an .xml configuration file copy. The original virtual disk is set as read-only and, if the VM is running, there will be two more associated files — the VM saved state (.bin) and memory information (.vsv), then the VM is resumed.
Figure 2. Checkpoints in Hyper-V Manager
Microsoft recommendations for Hyper-V checkpoints include:
- Don’t use snapshots on VMs that host time-sensitive services, such as Microsoft Exchange Server or Active Directory Domain Services
- Don’t expand existing virtual storage of a VM when there are snapshots on it, as they will get compromised
- Use Hyper-V Manager to delete .avhd(x) files from the snapshots tree, instead of deleting them manually
What about storage snapshots?
Storage snapshots are a great framework to leverage as part of a backup job. Veeam Backup & Replication supports many storage arrays for both Backup from Storage Snapshots and Veeam Explorer for Storage Snapshots. There are a few points to cover here as well:
- Even with a support array to leverage Veeam Explorer for Storage Snapshots, you still need to take a backup to go to different storage. Veeam Explorer for Storage Snapshots is a recovery-only technique from the source array that took the snapshot.
- Backup from Storage Snapshots is a great way to take a backup using the power of the storage array and move the data to different storage.
One of Veeam’s evangelists, Rick Vanover, likes to say that: “We have nothing but evidence in the form of customer success stories that good arrays do indeed fail — so please take your backups onto different storage and follow the 3-2-1 Rule.”
When should I use snapshots?
Snapshots are a short-term solution to be used mostly in testing and development environments for patching, updates, or to test things quickly and rollback in case of failure. They are less recommended in production. However, there are certain scenarios where snapshots really come in handy for the production environment. For example, if you take risky actions, such as an OS update or configuration changes that could harm your system, then snapshots are a good idea.
Why aren’t snapshots recommended for production environments? Mainly for data integrity reasons. With snapshots, you’re not making a copy of the virtual hard disk. There is the VM virtual disk and the delta disk, which means that if the VM disk volume gets damaged, then your snapshots are gone as well because they can’t be merged on the base disk. Snapshots don’t protect you against disk breakdowns, and you’ll still have a single point of failure.
Another reason is performance-based. Snapshots can impact the performance of VMs. This does not happen very often – this occurs only in some particular situations, but it can happen. For example, running highly loaded VMs on aged (and thus increased in size) snapshots would definitely worsen the performance of those VMs, especially if they use dynamic disks. It is a common mistake to keep a VM running on a snapshot for a long time — the snapshot will increase in size because it will absorb all the changes, instead of the source disk. Consequently, committing will take much longer and it could even stun the VM during the merge process.
Wait, doesn’t Veeam use snapshots?
Good observation! Veeam Backup & Replication does indeed use snapshots as part of a backup job. It can use a VMware VM snapshot, a Hyper-V checkpoint or a storage snapshot. It is important to note that the snapshot by itself is not a backup – but it can be used as a critical part of the backup process. This is because the snapshot is used as part of the data movement process to a backup file or a replicated VM. The snapshot is removed when the backup job is complete.
Snapshots vs backups
A backup is a consistent VM copy that gives you the possibility to restore it in case the original files are compromised by a disaster or a human mistake. Unlike snapshots, backups are independent of the VM, and they can easily be exported and stored off premises (in the cloud, on tape or other remote storage). Read about the golden 3-2-1 Rule.
Veeam Backup & Replication leverages VSS technology (Volume Shadow Copy Service) and application-aware image processing to create image-level VM backups. Image-level VM backups allow you to protect an entire workload — virtual disk, operating system, software applications and system configuration files. All of those are stored in a single image-level VM backup file, which provides multiple restore options for your business-critical applications — from full VM recovery to granular, application-item recovery.
Furthermore, Veeam Backup & Replication is designed with numerous technologies for optimized backup traffic and backup file size reduction, such as deduplication, compression or WAN acceleration, and it gives you the ability to test your backup recoverability with SureBackup. Also, Veeam provides you with an alternative way to quickly test and troubleshoot your VM, the Virtual Lab. Here you can create an isolated virtual environment that doesn’t impact your production and perform different operations, like testing software updates or running trainings.
What if my environment cannot tolerate snapshots of any type?
This is a real possibility today. One way to go about the backup process is to use Veeam Agent for Microsoft Windows or Veeam Agent for Linux. These new Veeam backup products don’t use any infrastructure snapshots at all below the operating system. For Windows, the VSS framework is used to make an image-based backup, and for Linux, the veeamsnap is used to have an image of the file system.
Additionally, coming in Veeam Backup & Replication v10, the Veeam CDP capability will provide a replication engine for VMware virtual machines that doesn’t use VMware snapshots. This is leveraging the vSphere APIs for I/O Filtering or VAIO that work in the storage path of the VM.
Conclusion
VM snapshots alone cannot be used as a reliable way to protect your data and restore it in case of a failure, but they’re very handy for quick testing and troubleshooting. Additionally, a VM snapshot can be used if it is part of a comprehensive sequence of events to do a backup or a replication job. Remember, however, to keep an eye on snapshot amounts and properly manage them in order to avoid any storage and performance issues. On the other hand, image-level VM backups provide a high level of applications and data protection, allow for low RPO and support virtually any recovery scenario — from a full-VM to application-item restore.