12.4 Taking and Managing VM Snapshots in Prism

12.4 Taking and Managing VM Snapshots in Prism

Objective 2.1 lists "take a snapshot" alongside deploying a VM and configuring its storage and networking, and the blueprint reference list names "Creating a VM Snapshot Manually" and "Deleting a VM Snapshot Manually" specifically. This is an operational item, distinct from the architecture covered in section 5.2.

Two Kinds of Snapshot

The most common confusion in this area is that Nutanix has more than one thing called a snapshot, and they serve different purposes.

The distinction that gets tested: a local VM snapshot lives on the same cluster as the VM. It is excellent protection against a bad patch or a failed application upgrade, and no protection at all against losing the cluster. Only a protection domain snapshot replicated to a remote site — or a backup product, or Multicloud Snapshot Technology writing to object storage — protects against site loss.

Taking a Snapshot Manually

The workflow in Prism Element is short:

1. Open the VM dashboard and select the virtual machine.
2. Choose Take Snapshot.
3. Give it a meaningful name.
4. Confirm.

Because snapshots are redirect-on-write, the operation completes in seconds regardless of how large the VM is, and it consumes almost no capacity at the moment it is taken. Capacity grows afterwards as the live VM diverges from the snapshot.

[!TIP] Name snapshots for their reason, not their date. "pre-payroll-patch-v4.2" tells the next administrator whether it is still needed; "snapshot1" does not. Snapshots named badly are snapshots nobody dares delete, and undeleted snapshots are a common cause of unexplained capacity growth.

The single most common use is the pre-change undo point: take a snapshot immediately before patching, upgrading an application, or changing a configuration, so that reverting is a fast operation rather than a restore.

Crash-Consistent vs. Application-Consistent

This determines whether the snapshot is actually useful for a database.

Crash-consistent is the default. The snapshot captures the vDisks exactly as they are at that instant, with no coordination with the guest. Recovering from it is equivalent to the VM having lost power at that moment. A modern journaling filesystem recovers fine; a database may need to replay or repair, and in-flight transactions held only in memory are lost.

Application-consistent requires Nutanix Guest Tools (section 6.3). NGT quiesces the application before the snapshot is taken — through the VSS provider on Windows, or pre-freeze and post-freeze scripts on Linux — so that buffers are flushed and the on-disk state is transactionally coherent.

[!IMPORTANT] If a scenario involves a database and asks for a reliable snapshot, the answer requires NGT. Application consistency is not a checkbox on the snapshot itself; it is a capability the in-guest agent provides.

Restoring and Cloning From a Snapshot

A snapshot gives you two recovery paths:

• Restore the VM from the snapshot, returning it to that point in time. The current state is replaced, so this is the destructive option.
• Clone a new VM from the snapshot, leaving the original untouched. Because clones are space-efficient (section 5.2), this is cheap, and it is usually the safer choice — you can inspect the recovered copy before deciding what to do with the original.

For file-level recovery, Self-Service Restore lets the VM owner browse a snapshot and recover individual files themselves, which also depends on NGT.

Deleting Snapshots and Reclaiming Capacity

Deleting a snapshot manually is done from the same VM view. What happens next is worth understanding because it explains a frequent support question.

Deletion marks the snapshot for removal; it does not instantly free space. Curator (section 2.3) subsequently runs its background scan, determines which extents are no longer referenced by any snapshot or live vDisk, and reclaims them. Capacity therefore returns after a delay, not immediately.

Two practical consequences:

1. Do not expect an instant capacity change after deleting snapshots. If a cluster is critically full, deleting snapshots buys relief on Curator's timetable rather than at once.
2. Long snapshot chains consume real capacity. Every snapshot pins the extents it references, so a VM with months of forgotten snapshots holds every version of every block that changed in that period.

Snapshots Are Not Backups

Worth stating plainly because it is examinable and because it matters:

Related but distinct, from section 11.2: the Recycle Bin retains a deleted VM's configuration and vDisks for up to 24 hours. It protects against deleting the VM, whereas a snapshot protects against changing what is inside it.