General comparison for virtual machines. Snapshot consistency, chain behaviour and retention limits are platform-specific.
Stuart Kerr Spindlow has confirmed personal use and testing of the software covered by Happy SysAdm. The assessments here distinguish documented behaviour from measured results; worked scenarios are labelled and are not personal test records.Identify what the recovery point depends on
Use a short-lived supported checkpoint for reversing an appropriate local change, and an independent retained backup for recovering from loss of the original storage or an older data mistake. Microsoft distinguishes standard Hyper-V checkpoints, which include memory state, from production checkpoints using supported guest consistency mechanisms. A more consistent checkpoint still shares dependencies with the VM; consistency and independence are separate properties.
Ask where the snapshot data and its parent disks live, which credentials control them and what happens if the datastore disappears. A point-in-time view can depend on the original disk chain. If the same failure destroys both, it does not provide the isolation needed for that scenario.
A backup should be evaluated by its recoverable data, retention, consistency and independence, not just by whether a product calls an operation backup. Some backup systems use snapshots as one step before copying data to a separate repository.
A checkpoint can still depend on the source disks
- Original storage boundary
For a typical Hyper-V differencing-disk chain, child changes depend on parent disk data. A local checkpoint shares source-storage risk.
- Independent recovery copy
A backup design must retain the required recovery data separately and protect access, keys and retention.
- Proof of recovery
Exercise a supported restore without depending on the original VM or datastore.
A checkpoint is not automatically an independent backup. Never manually delete checkpoint or virtual-disk files.
Use snapshots for a bounded purpose
A short-lived checkpoint can be useful around a supported change when the application and platform permit it. Define the reason, owner, expiry and expected rollback consequence. Application state, identity changes and external systems may make reverting inappropriate.
For example, reverting one application VM while leaving its external database at a later point can create inconsistent state. A snapshot of a running system may not provide application-consistent recovery without the relevant integration and support.
Manage capacity and deletion safely
Track snapshot age and storage growth using the hypervisor’s tools. Change rates and chain behaviour affect capacity consumption and performance. Plan supported consolidation or deletion with enough headroom and an appropriate window.
Never manually remove virtual disk or delta files because their names look old. They may be required by the current chain. If the platform reports consolidation errors or space exhaustion, preserve the state and follow the vendor’s recovery guidance.
Prove independent recovery
Use a backup restore exercise to show that the workload can be recovered without relying on the original VM or datastore. Confirm access to the repository and keys under the failure scenario, then validate the application in isolation.
Document which recovery job each mechanism serves: short-term change reversal, accidental deletion, storage failure or broader disaster. Keep retention and ownership explicit. A convenient rollback point and a disaster-recovery copy can both be useful, but they answer different questions.
Count surviving recovery domains, not checkpoint labels
One VM with five checkpoints on its only datastore has six labelled states but no copy that survives loss of that datastore. This is a dependency count, not a predicted failure rate. Copying recoverable data to a separate repository changes the storage failure domain, but credentials and site location can still remain shared.
Checkpoint age is useful for enforcing a chosen expiry, while actual changed-block growth is useful for capacity planning. Age alone does not establish consumed space or a safe lifetime. No universal performance penalty is assigned here because workload, chain behaviour and storage implementation change the result.