Nutanix AHV Snapshot Best Practices for Linux Virtual Machines

Author: Javier Rodriguez, Managing Technical Architect, ePlus Technology  |  javier.rodriguez@eplus.com  |  August 21, 2026

This guide summarizes best practices for using snapshots to protect Linux virtual machines running on Nutanix AHV. It covers how AHV snapshots work, when to use crash-consistent versus application-consistent snapshots, how to configure application consistency for Linux workloads, scheduling and sizing guidance, and how snapshots fit into a broader data protection strategy. The recommendations below are drawn from current Nutanix product documentation for AOS and Prism Element data protection.

Snapshots are the foundation of Nutanix data protection, but they are one tool among several. Used correctly, they give infrastructure teams fast, low-impact recovery points for Linux VMs. Used without the right configuration, particularly around application consistency, they can create a false sense of protection.

How AHV Snapshots Work

Nutanix AOS uses a redirect-on-write mechanism for snapshots. Taking a snapshot does not copy data. It marks the current virtual disk read only and creates a new writable virtual disk for subsequent changes, while unchanged blocks continue to be shared between the snapshot and the running VM. This is why AHV snapshots are near instantaneous and have minimal impact on running workloads, regardless of the guest operating system.

Snapshots are point-in-time captures of a VM or volume group and are used both for local recovery and as the basis for replication to remote sites. They can be created on demand or on a defined schedule through a protection domain, and stored locally, replicated remotely, or both.

Snapshot Consistency: Crash-Consistent vs. Application-Consistent

Every AHV snapshot falls into one of two categories, and the difference matters most for database and transactional workloads.

Crash-Consistent Snapshots

This is the default. The snapshot captures the on-disk state of the VM as it would appear if the system had lost power at that instant. Nothing in memory and no in-flight transactions are captured. Crash-consistent snapshots are well suited to systems and applications that do not require quiescing, such as file servers, DHCP servers, and print servers, and most Linux workloads recover cleanly from this state.

Application-Consistent Snapshots

These capture everything a crash-consistent snapshot does, plus any data the application has flushed to disk as part of the quiesce process. The key difference from crash-consistent is that NGT signals the application to pause and flush pending writes to disk before the snapshot is taken, then signals it to resume afterward. Nothing in VM memory is captured. Application-consistent snapshots are the right choice for database and transactional workloads such as SQL, Oracle, and similar platforms, but they take longer to complete than crash-consistent snapshots because of the quiesce and flush step.

Enabling Application Consistency on Linux VMs

This is the area where Linux differs most from Windows, and it is worth calling out clearly. On a Windows guest, Nutanix Guest Tools (NGT) can invoke the native Microsoft Volume Shadow Copy Service (VSS) automatically. Linux has no built in equivalent to VSS. For a Linux VM to produce a true application-consistent snapshot, Nutanix Guest Tools must be installed and active, and the VM must also have a pre_freeze script and a post_thaw script in place. Without both of those scripts, a Linux VM configured for application consistency will still only produce a crash-consistent snapshot.

NGT Prerequisites

• Nutanix Guest Tools must be installed on the guest OS and enabled for the VM.
• NGT is considered active only when it is installed, VSS capability is enabled, the VM is powered on, and it is actively communicating with the Controller VM.
• Confirm the Linux distribution and NGT version are listed as supported in the current Nutanix Compatibility and Interoperability Matrix for the AOS release in use, rather than relying on a version baseline from an older deployment.

Pre_freeze and Post_thaw Script Requirements

These scripts let NGT hand off quiescing to the application itself, for example flushing and locking a database, before the snapshot is captured, and resuming normal operation immediately after.

Failure handling on AHV works as follows: if pre_freeze returns a non-zero exit code, the system captures a crash-consistent snapshot instead and raises an alert in Prism Element. If post_thaw returns a non-zero exit code, the Nutanix documentation states the system will attempt an application-consistent snapshot once again. Separately, Prism Element raises alert A130113 for post_thaw script failures. Treat these alerts as an operational signal, not background noise. A pattern of script failures on a protected database VM usually means the script needs attention, not that the schedule needs adjusting.

Nutanix does not ship these scripts. Backup vendors such as Commvault publish scripts for common applications, or your team can write and test your own against the specific database or application running on the VM.

Consistency Group and Schedule Configuration

Whether a given snapshot actually comes out application-consistent depends on two separate settings, both of which must be enabled. Getting only one of them right still produces a crash-consistent snapshot, with no error to flag the mismatch.

For application consistency to apply at all, the consistency group must also contain only the single VM being protected. If a consistency group holds more than one VM, Nutanix ignores the application-consistent setting for that group entirely and captures crash-consistent snapshots.

Where Application-Consistent Snapshots Are Not Supported

• Guest VMs with delta disks, SATA disks, or IDE disks do not support Nutanix VSS recovery points.
• Guest VMs with iSCSI attached LUNs do not support Nutanix VSS recovery points; the operation fails for these VMs.
• Do not enable Nutanix application-consistent snapshots on a VM at the same time a third-party product (for example, Veeam) is also taking VSS-based snapshots of that VM.
• A protection domain’s snapshot naming is restricted to upper and lower case Latin letters, digits, dots, hyphens, and underscores, with a maximum length of 80 characters.

Matching Snapshot Frequency to Recovery Objectives

AOS supports several replication models, and the right one depends on the recovery point objective (RPO) the workload actually needs, not the lowest RPO available:

• Asynchronous replication: RPOs of one hour or greater. Appropriate for most general purpose Linux workloads.
• NearSync replication: RPOs between one and fifteen minutes, using Lightweight Snapshots (LWS) rather than full snapshots to hit that window efficiently.
• Synchronous replication (Metro Availability): Zero data loss for AHV workloads. Note that Metro Availability on AHV is not configured through Prism Element protection domains. It is delivered through Prism Central protection policies, which combine synchronous replication with cross-cluster live migration and a witness service for automated failover. It also requires NCI Ultimate licensing. If you are looking for this capability in the Prism Element data protection screen, it will not be there.

The node and Controller VM resources required to sustain a given RPO scale with how aggressive that RPO is. Zero-second and sub-fifteen-minute RPOs require more CVM cores and memory per node than hourly or daily schedules. Validate current resource requirements against the Nutanix Configuration Maximums and node sizing guidance for the specific AOS release and hardware platform in use before committing a workload to an aggressive RPO, since these figures change between AOS releases.

Scheduling and Retention

• Set the snapshot schedule to match the RPO the workload genuinely needs. An hourly snapshot on a Linux VM that changes infrequently consumes cluster resources better spent on workloads with a real low-RPO requirement.
• Stagger replication schedules across protection domains rather than starting them all on the hour, to spread out the performance and bandwidth impact.
• Configure retention to keep the smallest number of snapshots that still satisfies the retention policy. Seven daily, four weekly, and three monthly snapshots covers a three month retention window more efficiently, from a metadata standpoint, than 90 daily snapshots.
• Nutanix always retains at least the most recent snapshot, even through a prolonged replication outage, through the min-snap-retention-count setting at the protection domain level, so a site is never left with zero recovery points.

Sizing Local Snapshot Storage

Local snapshot reserve should be sized from the environment’s actual data change rate and the planned retention window, not a flat percentage of capacity. As a starting point:

Variable definitions:
  N  = number of snapshots retained (e.g., 7 for a seven-snapshot schedule)
  CR = daily data change rate for the VM, in GB
  S  = number of snapshots taken during one full Curator scan (typically 2 for hourly schedules)
Formula:
  snapshot reserve = (N x CR) + (CR x S x 0.1)
Worked example:
  VM with 50 GB daily change rate, 7 snapshots retained, 2 snapshots per Curator scan
  snapshot reserve = (7 x 50) + (50 x 2 x 0.1)
                   = 350 + 10
                   = 360 GB reserved for local snapshots

Reducing snapshot frequency does not automatically save space. Fewer, more widely spaced snapshots can increase the effective change rate captured per snapshot, since more blocks have had time to change between captures. Base sizing on measured change rate for the specific workload rather than an assumption carried over from a different environment.

Self-Service File Restore for Linux VMs

Self-service restore lets a Linux VM administrator recover individual files from a Nutanix snapshot without engaging the infrastructure team, provided the following are in place:

• A Pro or Ultimate Nutanix license.
• NGT deployed and the self-service restore feature enabled by the Nutanix administrator, through Prism Element or nCLI.
• The VM protected through a protection domain. Snapshots taken from the VM table view (on-demand snapshots) do not support self-service restore.
• In-guest access as a user with sudo privileges, using either the Nutanix SSR interface or the ngtcli command-line tool.

Two operational details are worth flagging to application owners. First, a disk attached for restore purposes is automatically detached after 24 hours if the guest administrator does not detach it manually. Second, the granularity available differs by replication type: asynchronous DR (one hour RPO or greater) exposes its native hourly snapshots for restore, while NearSync, which generates much more frequent delta recovery points, exposes only the last full hourly snapshot for self-service restore rather than every delta, to keep the number of restorable points manageable.

Snapshots Are Not a Substitute for Backup

Local and even replicated Nutanix snapshots are a fast, low-friction way to recover from operational mistakes, failed patches, or accidental deletion. They are not, on their own, a complete backup and disaster recovery strategy, particularly when they remain on the same physical cluster that hosts the VM. Pair snapshot-based instant recovery with genuine off-cluster protection: Nutanix asynchronous or NearSync replication to a second site, or a supported third-party backup platform such as Rubrik, Veeam, Commvault, Cohesity, or Zerto, depending on the recovery point and recovery time requirements for the workload.

Recommended Validation Steps

Before relying on any of the above in production, validate it end to end on a non-production Linux VM:

• Confirm NGT shows as installed and active, and that pre_freeze and post_thaw scripts are present with the correct ownership, permissions, and location.
• Force a snapshot and confirm in Prism Element that it was captured as application-consistent, not crash-consistent.
• Intentionally break the pre_freeze script (for example, a non-zero exit) and confirm the expected fallback behavior and alert are triggered.
• Perform an actual restore, whether through self-service restore or a full recovery, and confirm the application starts cleanly and data is consistent. Application consistency behavior is one of the areas most likely to change quietly across AOS and NGT upgrades, so this validation is worth repeating after any upgrade.

One failure mode the validation checklist is specifically designed to catch: an empty script or a placeholder that exits (0) without doing any actual quiescing will cause the platform to mark the snapshot application-consistent. AHV has no way to verify that I/O was quiesced; it only checks the exit code. A script that opens and immediately returns (0) satisfies that check. The result is a snapshot that Prism reports as application-consistent but is functionally crash-consistent, with no alert, no fallback indicator, and nothing in the metadata to tell the difference. That is a false sense of protection problem, and it is why forcing an actual restore and confirming application state is the only test that matters. Checking that the scripts are present and executable is not sufficient.

References

• Nutanix Prism Element Data Protection Guide (Protection Domain-Based Disaster Recovery, AOS 7.6)
• Nutanix AHV Data Protection and Disaster Recovery Best Practices Guide

For questions about this topic or assistance with Nutanix data protection planning, reach out at javier.rodriguez@eplus.com.