# VM Snapshots and Backups Solve Different Problems

An upgrade failure and a lost storage volume require different recovery plans\. Test the failure you actually intend to survive\.

<https://rdpcore.blog/en/articles/vm-snapshots-and-backups>

![A layered virtual machine beside a physically separate archive\.](<https://rdpcore.blog/media/0fd2c8969089c870f7e85e2132a1ea21/1600.jpg>)

Recovery independence depends on where the data and credentials live\.

Imagine an operating system upgrade fails ten minutes after it starts\. Now imagine the storage volume holding the virtual machine disappears\. A snapshot can be a fast answer to the first incident\. Whether it helps with the second depends on where its data lives and what else failed\.

## Ask what the snapshot depends on

Many snapshot implementations retain a base disk and record changed blocks separately\. Others are implemented by a storage service\. Read the platform's description before assuming a snapshot is independent, portable or application\-consistent\. A snapshot retained beside the original under the same account may be lost through the same storage failure or destructive credential\.

Even a coherent disk image may resemble a machine after an abrupt power loss\. A database can often recover its journal, but a multi\-volume application may require coordinated snapshots or an application\-aware backup\. Do not infer transaction consistency from a successful snapshot status\.

## Use different recovery tests

Before a risky change, take the supported short\-lived snapshot and record how to revert it\. Check available space for changed blocks during the maintenance window\. A long\-running snapshot chain can add storage pressure\. Consolidate it using the platform's procedure once the change is accepted\.

For disaster recovery, restore an independent backup into an isolated network\. Confirm that the machine boots, the application can read its configuration and a representative record and attachment match\. Keep scheduled jobs disabled during the exercise so the recovered copy cannot send duplicate mail or process live payments\.

## Put a number on the result

Record the timestamp of the newest recovered transaction and the elapsed time until the service was usable\. Those two measurements tell you more than a list of successful backup jobs\. Choose the retention, isolation and restore frequency against the amount of data loss and downtime the business can accept\.

## Further reading

[Red Hat: Virtual machine snapshots](<https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_virtualization/creating-virtual-machine-snapshots_configuring-and-managing-virtualization>)

Related guide: [Trace Both Power Feeds Before Calling a Rack Redundant](<https://rdpcore.blog/en/articles/dual-power-server-rack>)\.