Not all snapshots are created equally. This article aims to provide clarity on the differences between Virtual Machine Snapshots (VM Snapshots) and Volume level Snapshots.
Why Snapshot
A snapshot is essentially a point in time copy of data that an object had at that time or a delta ( changed data) since an earlier point in time and previous snapshot.
These data snapshots can be used as a recovery point to roll back to in the case of a problem with that object and in environments where snapshot data is shipped remotely to an offsite destination can be used as part of a disaster recovery strategy. In zCompute the use of the Protection Groups feature helps to orchestrate snapshot management for VMs and their attached Volumes.
VM structure
A virtual machine can be thought of as a container object, it's structure at the most base level means it must have a configuration to define it within the zCompute cluster and it must have at least one volume given over for the Operating System. Additional data volumes can optionally be added.
vm configuration or metadata - this describes the internal definition of the Virtual Machine for example; the AMI image, Instance type (vCPU and RAM resource size), Key Pairs, User data, Boot Volume Index, Firmware Type, Network Info, Security Groups, List of attached Volumes ....
boot volume - each VM must have an operating system installed to a boot volume to bring the VM online
data volume(s) - a VM may also have one or more optional data volumes .
Snapshot Creation
In zCompute we have 2 types or levels of snapshots.
- A VM snapshot (Virtual Machine)
-
A Volume snapshot
VM Snapshot
A VM snapshot groups together the metadata for the VM (ie: the VM snapshot data) and also creates snapshots for any attached volumes. One use-case would be to allow a return to an earlier point in time for the whole VM.
Volume Snapshot
A volume snapshot can be taken for an individual volume or volumes, ie: this does not include VM metadata information. The use-case here is more specific and allows a volume to be returned to an earlier timeframe.
Protection Groups
Snapshots triggered manually from the UI as described above are not considered to be crash-consistent. In order to achieve a crash-consistent set of snapshots we recommended the use of Protection Groups, these provide a way of scheduling regular snapshots for VMs and/or Volumes.
Note: snapshots actioned through Protection Group policies are atomic at the level of the VM (all IO is blocked when the snapshot is taken) this is not the case for standalone snapshots performed via the API although an enhancement to address this is in our roadmap (as of time of writing December 2025).
Our online guides provides much more information Here!
Snapshot Management
Whilst an individual volume snapshot can be deleted without impact,the same logic can't be applied when dealing with a volume snapshot when it forms part of a VM & Volume snapshot group, however it can be difficult to see this from the User Interface.
In Example 1 deleting an individual Volume snapshot within the grouping renders the full VM Snapshot invalid for a full point in time return.
However, deletion of the VM Snapshot (ie:VM snapshot data + Volume snapshots) , removes the whole group of snapshots in one go.
It's useful to understand the above when cleaning up a VM and it's related components otherwise you can get blocked by missing dependencies if snapshots for volumes are targeted instead of the VM snapshot group.
You can check if a Volume snapshot is part of a VM Snapshot group using the SYMP command line interface and commands.
Example: A customer attempts to use the UI to delete/cleanup an Account, but receives an error in the UI that other resources rely on the snapshot when they try to delete it. The below shows in the SYMP cli what we know about the problem snapshot;-
Explanation:
Volume Snapshot = abc12347-3d57-4668-b591-abc1231390cd was part of a VM Snapshot group = abc12345-6168-4ff8-9474-e05f1f7c7872 and the Source VM was found to no longer exist.
In order to deal with the situation , a vm-snapshot delete is issued and this removes all snapshots from the vm snapshot group cleaning up the orphan situation.
and when we re-check the individual volume snapshot we started with;
This is now successfully removed and no longer poses a problem.
The SYMP CLI is available to accounts with appropriate privileges, see Here for more online help and a SYMP primer.
| SYMP command | Use case |
|---|---|
snapshot get <snapshot id> |
Retrieve general snapshot details from the cluster, snapshot can be a VM or volume snapshot. |
vm-snapshot get <snapshot id> |
Retrieves details for a Virtual Machine Snapshot, content will reference vm snapshot information and disk snapshot(s). |
snapshot list |
Retrieves a list of snapshots in the cluster. |
vm-snapshot list |
Retrieves a list of VM snapshots in the cluster. |
The table shows several snapshot commands you may need, other snapshot related commands are available, some relate to manual creation or removal of snapshots so caution must be exercised when using.