Snapshots vs Backups: Why a Snapshot Is Not a Recovery Plan

A snapshot that lives in the same account, on the same storage and under the same administrator credentials as the system it protects will usually disappear in the same incident that destroys that system. Snapshots are fast, cheap and excellent for short rollback, which is exactly why many teams quietly treat them as their backup strategy. This guide compares snapshots and backups by the guarantee each gives you: which failures it survives, what consistency it captures, and whether it can meet a stated recovery point objective (RPO) and recovery time objective (RTO) after an attacker holds admin rights. Cloud and virtualisation examples come from Amazon Web Services, Broadcom VMware, Google Cloud and Microsoft Azure, listed alphabetically; the order is not a ranking. It is written for infrastructure, backup and resilience owners. For the secrets that end up inside copies, see the Secrets in Backups and Snapshots guide, which this page does not repeat.

Key takeaways

• The difference is the failure domain, not the format. A snapshot is a point in time copy that normally shares the account, region, storage system and permissions of its source. A backup is a copy designed to survive the loss of all of those.
• Attackers delete snapshots on purpose. MITRE ATT&CK T1490 Inhibit System Recovery describes adversaries deleting ESXi virtual machine snapshots and, in cloud environments, disabling versioning and backup policies and deleting snapshots, database backups and machine images.
• Consistency is a separate question. Most block snapshots are crash-consistent by default: they hold what was on disk, not what was in memory. Databases need application-consistent capture or their own native backup to restore cleanly.
• Some snapshots can be hardened. Amazon EBS snapshot lock in compliance mode, vault locks and enforced retention move a copy out of reach of a compromised administrator, but only if retention, isolation and identity design are deliberate.
• Use both, for different jobs. Snapshots serve fast rollback with minutes of RPO; isolated, immutable backups serve recovery from destruction, ransomware and account compromise. Write which copy meets which objective into the recovery plan.

The short answer

A snapshot is not a backup unless it has been copied, or locked, somewhere a compromise of the source cannot reach. Keep snapshots for rollback, cloning, staging backups and forensics (CISA recommends volume snapshots for forensic review). Rely on backups, for anything you would call disaster recovery or ransomware recovery. Broadcom's VMware guidance says it plainly: do not use VMware snapshots as backups, because the snapshot is a change log and cannot restore a virtual machine if the base disks are deleted.

Side-by-side comparison

How each works, in architecture terms

Snapshots

Snapshot mechanics differ by layer, and the differences decide what a snapshot can survive.

• Hypervisor snapshots: a VMware snapshot freezes the base disk and writes new changes to a delta file. Broadcom supports a maximum of 32 snapshots in a chain but recommends using only 2 to 3 for performance, and advises not keeping a single snapshot for more than 72 hours because the delta grows and can fill the datastore. Lose the base disk or the datastore and the snapshot is useless.
• Storage array snapshots: fast and space efficient, but they share the array's disks and management plane, so an array administrator, or an attacker holding that account, can expire them.
• Cloud block snapshots: AWS describes an Amazon EBS snapshot as an incremental backup that saves only the blocks changed since the most recent snapshot, stored in Amazon S3 buckets you cannot access directly and replicated across all Availability Zones in the region. That survives a disk or zone failure, but the snapshot still sits in the same account, so it is exposed to anyone with snapshot delete permissions there. AWS also states it does not automatically back up the data stored on EBS volumes: protection is a customer responsibility.
• Backup service snapshot stages: Microsoft documents that Azure Backup for VMs first takes a snapshot and then transfers the data to a Recovery Services vault, and that snapshot data might not be copied to the vault immediately, taking some hours at peak times. Until then, the newest restore point is only a snapshot.

Backups

A backup is defined by independence: a separate copy with its own catalogue, retention and access path. In practice: a vault in a dedicated account or project, copies in another region or medium, at least one immutable or offline copy, and a restore path that works when production identity is down. The 3-2-1-1-0 Backup Rule expresses the target; scheduling choices are covered in Full vs Incremental vs Differential Backups.

Threat models: what each copy survives

Three threat models need explicit design.

• Admin credential compromise: the attacker uses a legitimate cloud or virtualisation account (ATT&CK T1078.004 Cloud Accounts covers the cloud case). ATT&CK T1490 explicitly lists deleting snapshots, database backups, machine images and prior object versions in cloud environments, and deleting or encrypting ESXi VM snapshots. See the T1490 Inhibit System Recovery Defensive Guide.
• Same-account blast radius: if snapshots, the backup vault, the key management keys and the workload all live in one account, a single privileged identity can remove every recovery option.
• Destructive and ransomware attacks: CISA warns that many ransomware variants attempt to find and subsequently delete or encrypt accessible backups. Snapshots that are reachable from the compromised management plane are, by definition, accessible. Destruction without encryption (ATT&CK T1485 Data Destruction) follows the same path; see Data Integrity Protection Against Destructive Attacks.

Consistency: what a snapshot actually captured

Microsoft's Azure Backup documentation gives clear definitions that apply across platforms.

Azure Backup uses application-consistent capture by default for VM policies and falls back to file-consistent on Windows if VSS fails, so a "successful" job can hold weaker consistency than expected. For databases, a native backup with transaction log retention (for example RMAN, SQL Server log backups or PostgreSQL continuous archiving) gives point in time recovery that no volume snapshot can; see the Database Backup and Recovery Security guide.

RPO and RTO: when each copy meets the objective

State objectives per scenario, not per system. A database may have a 15-minute RPO for operational failure and a 24-hour RPO for ransomware recovery, and different copies meet each.

• Operational RPO: frequent snapshots (hourly or more often) plus database log backups give minutes. This is where snapshots earn their place.
• Destruction RPO: set by the last copy that reached isolated, immutable storage. If the vault copy runs nightly, the destruction RPO is up to 24 hours, however frequent the local snapshots are. In Azure, add the snapshot-to-vault transfer lag Microsoft describes.
• Operational RTO: reverting a snapshot or attaching a volume created from it takes minutes. Test the real figure.
• Destruction RTO: restoring from a vault in another account or region means rebuilding networking, identity and keys as well as data. Measure it in exercises; it is usually hours to days for a full estate, and the identity rebuild often dominates. See IAM and PAM Recovery After Ransomware.
• Retention versus dwell time: NCSC advises retaining backups by time period rather than a fixed number of copies, so an attacker cannot flood the store and push clean copies out. Snapshot retention of a few days rarely reaches back before an intrusion.

Controls that close the gap

Platform controls only work inside an architecture that separates duties.

1. Separate account or project for backups. Copy snapshots and recovery points into a dedicated backup account, project or subscription with its own administrators, ideally in a separate organisational unit with policies that deny deletion.
2. Immutability with a time-based retention. Lock the vault or the copies, and set minimum retention to cover realistic dwell time. Beware retention "forever" under compliance locks: AWS warns such recovery points cannot be altered or deleted once grace time expires.
3. Deletion delay and out-of-band approval. NCSC recommends soft delete, a deletion delay that only works if an alert is also raised, and destructive requests from any customer identity, human or machine, being blocked unless approved through a separate channel.
4. Separate keys. NCSC notes that deleting or altering an encryption key can make backups unusable. Hold backup keys in the backup account, with deletion protection, and keep an offline copy of master key material.
5. Restore path independent of production. Break-glass access to the backup service that works if corporate identity is down, as NCSC's principle that customers must not be locked out describes.

Where identity fits

Snapshots and backups are created, copied, locked and deleted almost entirely by non-human identities: backup service roles, snapshot lifecycle automation, infrastructure as code pipelines and agents on hosts. Those identities decide the real blast radius.

• Split create from delete: the role that schedules snapshots needs create and tag permissions, not delete. Run expiry under a distinct role or platform retention.
• Keep backup identities out of the production directory: on premises, do not join backup servers to the production Active Directory domain; in cloud, do not let workload account roles assume roles in the backup account.
• Restrict snapshot read and share: Google's snapshot guidance stresses granting snapshot permissions such as compute.snapshots.useReadOnly only to trusted principals, because a readable snapshot is a full copy of the disk (ATT&CK T1578.001 Create Snapshot describes adversaries creating snapshots to reach data).

See the Backup Identity Isolation Guide for the full identity design.

Decision guidance and worked scenarios

Choose snapshots alone only for data you could rebuild from source control or another system of record, such as stateless web tiers built from images. Choose snapshots plus isolated backups for every system with unique data. Choose native database backups on top of both where point in time recovery matters.

Small organisations can get most of the value from one managed backup service with a locked vault in a separate account and short-lived local snapshots for patching. Large organisations need a backup landing zone (dedicated accounts per region, organisation-level deny policies, central monitoring) and per-tier policies.

• Scenario 1, cloud SaaS platform: production runs in one cloud account with hourly EBS snapshots kept for seven days. An attacker steals an engineer's access keys with administrator rights and deletes all snapshots and the RDS automated backups. Recovery fails. The fix: copy daily recovery points to a backup account with Vault Lock in compliance mode and 35-day minimum retention, apply compliance-mode snapshot lock to weekly snapshots, and deny ec2:DeleteSnapshot in production through organisation policy except for the lifecycle role.
• Scenario 2, virtualised data centre: a manufacturer keeps three days of VMware snapshots and believes it has backups. Ransomware operators with vCenter access remove snapshots and encrypt datastores, the pattern T1490 describes for ESXi. The fix: an external backup repository with immutable storage, backup server outside the production domain, and snapshots limited to pre-change rollback for under 72 hours. See the ESXi Ransomware Playbook.

Implementation: a phased approach

1. Inventory: list every system, its snapshot schedule, its backup job, where each copy lives (account, region, array) and which identities can delete each one.
2. Classify objectives: set operational and destruction RPO and RTO per tier, and map which copy meets each. Any destruction objective met only by a same-account snapshot is a gap.
3. Build the isolated tier: create the backup account or vault, cross-account copy jobs and separate keys. Start with crown jewel systems.
4. Pilot locks in governance mode: AWS suggests testing a snapshot lock configuration in governance mode before compliance mode; Microsoft advises locking an immutable vault only after you are satisfied with the impact. Run for a full retention cycle and confirm costs.
5. Lock: move to compliance mode or locked immutability. Rollback is only possible during the cooling-off or grace window; record the lock date and owner.
6. Tighten identities: remove delete permissions from production roles, add deny policies, and set alerting on snapshot and backup deletion and policy changes.
7. Test restores: restore from the isolated tier into a clean account on a schedule, scanning restored data. Use the Backup and Recovery Testing Checklist.

Detection and measurement

Log and alert on: snapshot and recovery point deletion (especially bulk deletes), changes to snapshot lifecycle policies, backup plan or vault policy changes, lock removal attempts, disabled versioning, key deletion scheduling, snapshot sharing to external accounts, and stopped backup jobs. NCSC recommends alerting whether or not the attempt succeeds and delivering alerts by more than one route.

• Isolation coverage: percentage of tier 1 systems with a recovery point in a separate account or vault inside the destruction RPO.
• Immutability coverage: percentage of isolated recovery points under a compliance-mode or locked retention.
• Restore success: percentage of scheduled isolated restores that completed and passed application checks in the last quarter.
• Measured RTO versus target: actual time to restore a tier 1 service from the isolated tier in the latest exercise.
• Delete-capable identities: count of human and machine identities able to delete snapshots or recovery points, tracked down over time.

Common failure patterns

• Counting snapshots as the backup: the recovery plan cites snapshots in the same account as the disaster recovery copy, and they are deleted in the first hour of the incident.
• Vault and workload in one account: the backup service is configured, but the vault, keys and workload share administrators, so one stolen role removes everything.
• Crash-consistent database copies: volume snapshots of a running database restore but will not start, or lose committed transactions, because nobody tested application consistency.
• Retention shorter than dwell time: seven days of snapshots cannot reach back past an intrusion that began a month earlier.
• Long-lived VMware snapshots: snapshots kept for weeks grow until the datastore fills, causing the outage they were meant to protect against.
• Locks never tested: a compliance lock applied without a pilot sets retention wrong, and it can only be extended, never shortened.

Framework mapping

Practitioner checklist

• Map every system to the copy that meets its operational and destruction RPO and RTO.
• Hold at least one recovery point per tier 1 system in a separate account, project or vault.
• Apply compliance-mode or locked immutability to the isolated tier after a governance-mode pilot.
• Set retention by time, long enough to pre-date a realistic intrusion.
• Use application-consistent capture or native database backups for stateful systems, and verify the consistency actually achieved.
• Remove snapshot and recovery point delete rights from production roles and pipelines.
• Keep backup keys and backup administrators outside the production account and directory.
• Alert on bulk deletes, policy changes and lock changes through more than one channel.
• Keep hypervisor snapshots to a short chain and under 72 hours.
• Restore from the isolated tier into a clean environment at least quarterly and record the measured RTO.

Standards and references

• NCSC: Principles for ransomware-resistant cloud backups
• CISA: #StopRansomware Guide
• MITRE ATT&CK: T1490 Inhibit System Recovery
• AWS: Amazon EBS snapshot lock concepts
• AWS: AWS Backup Vault Lock
• Broadcom: Best practices for using VMware snapshots in the vSphere environment
• Google Cloud: Backup vaults in Backup and DR
• Microsoft Learn: Immutable vault for Azure Backup

Related NHI Mgmt Group resources: Backup Security and Immutable Backup Guide · Secrets in Backups and Snapshots · Kubernetes Backup and Recovery · Cloud Native Backup and Ransomware Resilience Guide · Backup Identity Isolation Guide