VMware Snapshot Best Practices
VMware vSphere virtual machines deliver powerful capabilities that provide agile, versatile, and efficient environments for software. One of the very useful features in vSphere is the ability to take snapshots and revert to a VM’s previous state when needed using the snapshots. But this technology has its limitations.
In this post, learn about VMware snapshots and their use cases. We’ll also guide you through VMware snapshot best practices and explain how to create a snapshot in VMware vSphere Client and via PowerCLI.
What Is a VMware Snapshot?
A VMware snapshot is a point-in-time version of a virtual machine, and this version is recorded in the appropriate VM files. A snapshot can be used to revert to a VM’s state at a previous point in time, along with the data and other settings. VMware disk snapshot is a changelog for a virtual disk recorded to the appropriate snapshot file.
A VM snapshot includes:
- VM disk state, the disk content of the machine.
- VM memory state and VM power state, the memory footprint at the time of the snapshot, which allows the capturing of the power state of the virtual machine.
- VM settings, including devices, virtual network cards, etc. For instance, you could take a snapshot of a virtual machine without a secondary virtual NIC (Network Interface Controller (NIC). Then if you add a secondary NIC and roll back to the snapshot, the NIC will be gone as the snapshot includes configuration and not just data and state.
VM Backup vs Snapshot
The main difference between backups and snapshots is that backups are VM copies that are independent of the source VM files while snapshots depend on the original VM. That is why even if a snapshot is a point-in-time version of a VM, including the VM’s files, state, and configurations, it can’t be used as a vSphere VM backup. If you use snapshots as backups, you may find yourself unable to recover data and VMs after a failure.
- Snapshots rely on the source virtual machine files used to create them. Snapshots can be known as differencing disks as they really are a set of delta information in relation to the “base” disk. They are sometimes referred to as snapshot “chains” due to this interrelationship between the child/delta disk and the base disks they depend on. If the base disks on which the snapshots depend are deleted, the snapshots do not contain the data needed to recreate the deleted data.
- Backups are independent data copies that allow virtual machine files, disks, and entire virtual machine registrations to be recreated with no dependency on the production data or on the virtual disks contained in the virtual machine.
VMware Snapshots Use Cases
Often snapshots are used for quick “rinse and repeat” type operations, especially in a development environment. A snapshot may be created before a certain software process is tested on a virtual machine, like application testing, upgrades, updates, or patches. The virtual machine can then be quickly reverted to a previous state, bringing the VM back to the condition in which it was before running the software update, upgrade, and so on.
VMware does not support snapshots being run in production or long-term deployments of snapshots. They are not meant to be left in place for an extended length of time as they can lead to performance degradation or disk space issues if left unchecked.
Though snapshots are not equal to backups, they can be temporarily used to create a backup. For example, NAKIVO’s solution uses this technique for VMware VM backup. The solution takes snapshots of virtual machines to create a consistent VM backup even if the VM is running (when creating a host-level VM backup). After a VM backup has been created successfully, the snapshot is deleted.
VMware Snapshot File Extension
In VMware’s implementation, virtual machine snapshots are comprised of the following set of files making up the snapshot file infrastructure:
- .vmdk – the base virtual machine disk, which contains the raw data.
- -00000x.vmdk – the delta disk, which contains the difference between the current state of the virtual disk and the state of the virtual disk at the time the previous snapshot was taken. Virtual disk changes are represented as a redo log. Data in the child VMDK disk used for a snapshot is saved in the SPARSE format using the Copy-On-Write mechanism.
- .vmsd – the database file for the snapshot. It contains the snapshot information used by the snapshot manager. The database contains the relationships between snapshots and child disks for each snapshot.
- .vmsn – the file that includes the active state of the virtual machine, including the memory. This allows you to revert to a running state of the virtual machine when reverted. A snapshot created without including the memory, reversion to the snapshot will be to a virtual machine that is powered off.
By default, VMware snapshot files are located in the VM directory. But you can manually configure a custom directory to store snapshots for a VM by editing a VMX configuration file of the VM. This option can be useful when disk performance for the VM is not enough.
How Does the VM Snapshot Technology Work?
Now that we know what files are created when you take a snapshot in VMware environments, let’s look at the working principle behind the creation of a vSphere snapshot.
- When we request to create, delete, or revert snapshots using a client such as VMware vSphere Client or PowerCLI, the request is sent to the server through the VMware API.
- The request to create, delete, or revert a snapshot is sent to the server that runs the target VM. However, this holds true only for vCenter Server. It will be skipped if the request for a snapshot is sent directly to the ESXi host.
- If the Snapshot the virtual machine’s memory option is enabled, the ESXi host writes the VM memory to the disk. During this process, the VM will be stopped.
- The ESXi host modifies the VM’s snapshot database file (.vmsd) so that it reflects the changes in the VM snapshot manager.
- The ESXi host calls Virtual DISK API functions to make changes to the child disk files (-delta.vmdk and .vmdk) as well as the disk chain.
Creating snapshots
When a snapshot is created, the state of the virtual disk at the moment of taking the snapshot is maintained while all writes to the VMDK file are stopped. To capture changes, the system creates an additional VMDK file (delta disk) for every VMDK disk contained in the data store and writes changes to that file. If you take more than one snapshot, the system creates delta disks for each VMDK disk of every snapshot, representing differences between them.
A large chain of snapshots and the corresponding delta disk files reduce VM storage performance. When a VM needs to read data, the parent virtual disk VMDK file and related delta VMDK files (VMware snapshot files) must be read together in sequential order. This is needed to rebuild the data change (virtual disk input) history recorded in snapshot files and output the requested data for a VM. Snapshot files grow over time. Snapshots grow faster if intensive disk operations are performed on a VM (recording/deleting data).
You can create multiple snapshots, revert back to any snapshot, and create new snapshots after making changes. As a result, you can create a snapshot tree. In the image below, you can see a snapshot tree when we created Snapshot 3, reverted back to Snapshot 2, and then created Snapshot 3a.
Deleting snapshots
When you delete a snapshot, the system merges the changes between the snapshots and previous disk states. All the data from the delta disk, which includes information about the deleted snapshot, is written to the original VMDK disk. The time needed for the deletion of a snapshot depends on the amount of data that has been written to the virtual disks since the last snapshot. Let’s look at how snapshots are deleted in different situations.
We have a base disk (VMDK) and two snapshots illustrated in the corresponding diagrams for our examples:
- The size of the first VMware snapshot file is 3.3 GB, and the size of the second snapshot is 2.2 GB.
- Snapshots use the corresponding delta VMDK files but for more convenience, snapshot names are Snapshot_1 and Snapshot_2 in the diagrams.
- The You are here point explains the current VM state of our VM (can be after or before a snapshot).
Deleting the last snapshot
When we delete the second VMware snapshot, which is the last snapshot in our chain before our current VM state, the Snapshot_2 data is consolidated with the parent Snapshot_2 delta disk. The size of the first snapshot increases by the size of the deleted second snapshot (3.3 GB + 2.2 GB in our example).
Deleting the first snapshot
What happens when you delete the first snapshot in a snapshot chain, and your current VM state is the state after the last snapshot? Snapshot_1 data is committed to the base disk, and Snapshot_2 is retained. The base disk size increases by the size of the first VMware snapshot file that we are deleting (20 GB + 3.3 GB in this example). There are no changes in the VMware snapshot file (related to Snapshot_2).
Deleting all snapshots
When you delete all snapshots, VMware snapshot files are consolidated and data is committed to the base disk (the new algorithm is used). Snapshot_1 data is committed to the base disk first. Then Snapshot_2 data is committed to the base disk. The same process is performed for all following snapshots if you have more snapshots. The size of the base disk increases after writing data changes recorded in VMware snapshot files.
When using vSphere 5.0 and older algorithms, VMware snapshot files are consolidated by writing data to the parent snapshot disk first (Snapshot_2 to Snapshot_1 in our example), and then all snapshot data is committed to the base disk.
Deleting a snapshot after the current state
In the three previous examples, the VM state (marked You are here in the diagrams) represents the state after all the snapshots in the chain. In this example, the VM state is after the first snapshot and before the second snapshot (which is the last snapshot in this case).
When we delete the last snapshot, the snapshot is deleted without impact on the previous snapshots in the chain. No changes are written to Snapshot_1 and base disk in this example. If we would have more snapshots after the second snapshot (third, fourth, fifth, etc.), their data (the data of subsequent snapshot files) is also deleted with the data of the second VMware snapshot file.
How VMware snapshots are deleted
Starting with vSphere 6.0, the snapshot mirror driver is used for snapshot consolidation when deleting snapshots. This driver is also used for VMware Storage vMotion. Usage of temporary helper snapshot disks is minimized, and snapshot consolidation can be performed in one pass even without helper disks. VM changes are written to the active VMDK disk, and the write order is protected during the VMware snapshot consolidation process.
During the consolidation process, writes are made to both the active disk and base disk acknowledgements being sent.
How to Create a Snapshot in VMware vSphere Client
The following walkthrough is using the new HTML5 vSphere client in vSphere 6.5. The same workflow is true for vSphere 6.7, vSphere 7.0, 7.0U1 and 7.0U2.
- Right-click the VM you want to create a snapshot on and select Snapshots > Take Snapshot.
- In the Take Snapshot dialog box, you can name the snapshot and create a description for the snapshot if you want to add more details.
- The checkbox for Include the virtual machine’s memory allows us to select between snapshots with and without virtual machine memory. Let’s look at the differences:
- When you select Include the virtual machine’s memory, a dump of the internal state of the VM is included in the snapshot. To take snapshots with VM memory, the VM has to be in a powered-on state – otherwise, the option is not available for selection. By taking a snapshot of a powered-on VM, you can capture the live state of the VM and revert back to this state at any time.
- When this option is not selected, the snapshot does not capture the live state of the VM. If you need to revert back to the snapshot, your VM will be restored, containing the same data but in a powered-off state. After that, the VM must be powered on manually.
- You can select the Quiesce guest file system option to make an application-aware snapshot to preserve data consistency if writing operations are running on the virtual machine.
- VMware Tools, including the Sync Driver, must be installed for this purpose. A snapshot with the quiescing option is suitable to back up VM data using this snapshot.
- VMware Tools with VMware Snapshot Provider initiates creating a VSS snapshot in a guest OS (in a Windows guest). Volume Shadow Copy Service (VSS) writers in a guest OS get a request and prepare applications for creating an application-aware snapshot. All writing transactions are written from the VM memory to the VM disk. When this operation is completed, VSS writers notify VMware Tools that a VM is ready to take a snapshot.
Note: When you select the Include virtual machine’s memory option, the Quiesce guest file system becomes inactive. You can select one of these options if a VM is powered on.
- Click Create to create the snapshot, and then you can see the relevant task kick off in the vCenter Recent Tasks pane.
How to manage vSphere snapshots
- After we create a snapshot, we can manage it by right-clicking and selecting Snapshots > Manage Snapshots.
- In the Manage Snapshots dialog box, we can see the snapshots that exist on a virtual machine as well as the options:
- Revert – revert to an existing snapshot. Use this option to restore the virtual machine state saved in the snapshot.
- Edit – edit a snapshot name and description.
- Delete – delete the selected snapshot; remove the snapshot from Snapshot Manager. If a snapshot is before your current state, the snapshot data is consolidated with the parent snapshot disk or base virtual disk of the VM.
- Delete All – delete all snapshots for the current virtual machine.
Other pertinent information is displayed as well, such as the snapshot name, time created, and disk usage.
Snapshot alarm rules
When the snapshot size significantly increases, the VM disk performance is degraded. For this reason, you should keep an eye on your VMware VM snapshot size to perform measures and delete/consolidate snapshots before the negative VMware snapshot performance impact. Configuring a VMware vSphere snapshot alarm rule allows you to get notifications when the snapshot size exceeds the appropriate value set in the notification settings. Let’s take a closer look at how to configure vSphere snapshot notifications in vSphere Client.
We are going to configure notifications to be sent when a snapshot’s size exceeds 30 GB.
- Go to Hosts and Clusters and select a VM. Right-click the VM and in the menu that opens, click Alarms > New Alarm Definition.
- The New Alarm Definition wizard opens.
- Name and Targets. Enter the alarm name, for example, vSphere snapshot usage. Enter description (optional). Select the Virtual Machine target type. Click Next at each step of the wizard to continue.
-
- Alarm Rule 1. Set the rule as follows:
- IF
- VMware Snapshot Size | is above | 30 GB
- THEN
- Trigger the alarm and Show as Warning
- Send email notifications: ON
- Subject: You can use the default subject
- Email to: enter your email address
- IF
- Alarm Rule 1. Set the rule as follows:
-
- Reset Rule 1. You can configure the reset rule similarly as you have configured the alarm rule. The reset rule is responsible for sending a notification message when the warning or critical conditions are no longer met for a vSphere snapshot.
-
- Review. Review your rule configuration. If everything is correct, hit Create.
To learn how to work with vSphere snapshots in PowerCLI, check the next section.
How to Create Snapshots Using PowerCLI
A powerful way to interact with vSphere is by using PowerCLI. PowerCLI can be used to create, delete, and revert snapshots. Let’s look at some basic syntax to do this.
Creating snapshots with PowerCLI
To create a snapshot using PowerCLI we can use the following syntax:
get-vm testvm | new-snapshot -Memory -quiesce -name "Test snap"
Removing a snapshot
To remove a snapshot, we can store the snapshot name in a variable such as $snap and use it to remove the snapshot in question:
Remove-Snapshot -Snapshot $snap -RemoveChildren
Reverting to a snapshot
To revert to a snapshot that was created, we can use the following syntax:
get-vm “testvm" | set-vm -snapshot "Test snap" -confirm:$false
VMware Snapshot Limitations
There are some limitations for vSphere snapshots you should know.
- Issues can arise as the number of snapshots grows over time. The snapshots can become difficult to manage and can occupy too much disk space. They are also not protected from hardware failure.
- Keepin VM snapshots for too long, a large snapshot tree, or too many changes introduced in a VM and its guest OS since the last snapshot can have a negative impact on the performance of your VMs and hosts.
- Raw disks and RDM physical mode disks do not support VMware snapshots. However, RDM (Raw Device Mapping) with virtual compatibility mode supports snapshots.
- Independent disks do not support VMware snapshots. To create a snapshot, VMs with independent disks must be powered off first. If the VM is powered on or suspended, snapshots are not supported.
- VMware does not provide snapshots for PCI vSphere Direct Path I/O Devices.
- VMware snapshots are also unavailable for guest operating systems that use an iSCSI initiator in the guest.
- VMs configured with bus sharing do not support VMware snapshots.
- Snapshot-related procedures are time-consuming for VMs with VMDKs of 2 TB or more.
- Snapshots should not be considered as long-term data protection (backup) and recovery methods because snapshot files are not retrievable if the files are lost along with a VM.
VMware Snapshot Best Practices
Try to follow these VMware snapshot best practices when working with snapshots.
- Don’t use snapshots as backups. Snapshots do not suffice as a data protection and recovery method because snapshot files are just change logs of the parent virtual disk.
- A snapshot chain should not exceed 32 snapshots. For better performance, limit snapshots to 2 or 3.
- VMware snapshot files can grow over time, potentially occupying too much space in the data store and causing storage overhead. The general advice here is to not store snapshots that are older than 72 hours. You can display snapshots older than 3 days, for example, in PowerCLI.
Note: The command to show snapshots older than 72 hours:
Get-VM | Get-Snapshot | Where {$_.Created -lt (Get-Date).AddDays(-3)} | Select-Object VM, Name, Created, SizeMB
- Delete operations should not be performed in bulk because they can commit all the changes stored in delta files to parent VMware snapshot files or base disk VMDK files.
- Be especially careful with snapshot use for I/O-intensive database server VMs with rapid data changes, as snapshots could fill up all datastore space.
- While using third-party solutions that rely on snapshots, make sure snapshots are deleted regularly.
- Be careful if you are planning to increase the disk space of the VM disk while snapshots are still stored on it. Snapshots can be damaged, potentially resulting in unexpected data loss.
- Take advantage of vCenter Alarms and PowerCLI scripts to stay on top of VM snapshot and datastore space usage. This also allows you to track the age of VM snapshots.
- If your vSphere version is older than v5.0, delete all snapshots before you run Storage vMotion. Storage vMotion is only supported for VMs with snapshots after vSphere 5.0; with earlier versions, it might cause data loss or render VMs unavailable.
- Monitor VMware vSphere environments to prevent issues and proactively fix them.
Concluding Thoughts
Snapshots provide a powerful mechanism to allow reverting to a known state of a VMware virtual machine. This includes the files on disk, in memory, as well as the configuration present on the virtual machine at the time the snapshot was created. Especially in development environments, the use of snapshots can be very beneficial when testing code integration, updates, or other modifications that may need more than one run-through. By reverting back to a snapshot, you can quickly and efficiently get back to a known good state.
However, snapshots are not backups and should only be present in development environments and not in production. Additionally, they shouldn’t be left on a virtual machine for long periods of time as they can lead to performance degradation and excessive disk space usage. Use NAKIVO Backup & Replication to protect VMware vSphere data, apps, and machines. Download the Free Edition to try the product in your own environment.
