A VM snapshot preserves the state and data of a virtual machine at a specific point in time. For example, admins resort to taking a snapshot before upgrading some software or performing any risky operation. They do that so they can roll back in case something goes wrong. But why are we advised against using snapshots as backup?
- A VM snapshot uses delta files that track changes made to the virtual disk’s data at the time of the snapshot and store it locally. If a previous snapshot or the original virtual disk is corrupted or unavailable, recovering the VM is not possible. In contrast, a backup takes a full and direct copy of a VM and can retain it independently in a separate location. In essence, a snapshot is not a full copy of the base disk; therefore, it is not enough to restore a VM in case of storage failure.
- As time passes, the snapshot file grows in size. Given enough time, the snapshot storage location can run out of space and impact the system performance. Therefore, VMware does not recommend using a single snapshot for more than 72 hours.
- Since a snapshot only contains the changes to the disk since the snapshot was created and is not a complete copy of the disk, it cannot be restored as a separate VM. It can only be restored on the same VM.
- Snapshots cannot be used to recover individual files; a snapshot must be restored in its entirety because the system restores the virtual disk as a storage block device and does not manage the filesystem within it.
Because they can efficiently and quickly restore a VM to a specific point in time, VM snapshots are a valuable tool in any admin’s toolbelt. But, they must only be used as intended; otherwise, they can cause problems if not used carefully. Furthermore, snapshots are not intended to replace a proper backup system, which provides independent, self-contained copies that can store files indefinitely in suitable locations and recover them without dependencies.
