Snapshots and backups: which failures can you recover from?

Start with the failure boundary

A backup is a recovery copy, not a particular storage command. [7] A product label cannot tell you which disks, credentials, applications or locations that copy depends on.

OpenZFS snapshots preserve a read-only view while initially sharing data with the active dataset. As that dataset changes, retained blocks consume space. [1] The engineering consequence is simple: a snapshot retained only in a pool cannot survive the loss of that entire pool.

This is not a claim that every snapshot shares the same failure domain. A service may export or replicate one to independently managed storage. Verify the actual placement and retention arrangement.

Three arrangements, three different claims

The following is Hesela's qualitative comparison under the stated assumptions, not a measured recovery guarantee. "Independent" means independent of the named failure, not immune to every failure.

The first row follows from OpenZFS's shared-pool organization. [1] OpenZFS send streams support full and incremental transfers to storage or another system, enabling the second arrangement. Transfer is not a retention policy. [3] Receiving an incremental replication stream with zfs receive -F can destroy destination snapshots and filesystems that no longer exist on the sending side. [8] Application coordination addresses a different dimension. [5]

An incremental stream needs its base

OpenZFS v2.3 requires an existing destination whose latest snapshot matches the incremental stream's source. A delta file alone is therefore not a complete recovery copy. A completed receive is different: the destination has reconstructed snapshot state. Do not confuse an archive of unapplied streams with a received dataset. [8, description]

For PostgreSQL-specific predecessor chains and checks, see backup verification versus an actual restore.

Consistency is not one switch

OpenZFS snapshot creation is atomic within its documented scope; recursive creation captures descendant datasets together. That does not establish coordination across independent pools or capture data still buffered by an application. [2]

For a concrete crash-recovery example, PostgreSQL 18 supports consistent filesystem snapshots of a running database. Recovery uses the complete cluster and WAL. If data, WAL or tablespaces span filesystems, snapshots must be simultaneous; otherwise use a documented alternative such as shutting down during capture or a base backup with continuous archiving. A snapshot can therefore be recoverable without having been application-quiesced. [4]

Microsoft VSS illustrates application coordination: writers prepare application state and participate in a temporary write freeze. Merely calling a storage snapshot does not demonstrate successful writer participation. [5] Check the application's supported procedure rather than assuming that "application-consistent" means a copy of all memory.

A distributed snapshot includes channel state

Chandy and Lamport's 1985 paper records processes and messages in transit. Its marker algorithm assumes reliable, ordered channels and finite delivery delays; recording does not require simultaneous local captures. The result can be a reachable global state that never occurred in the original event order. [9, sections 2-4]

This is an algorithmic model, not evidence that unrelated volume snapshots implement it. Our practical question: what coordinates the database, queue and other participants? See distributed snapshot.

RPO and RTO are targets

RPO specifies the required recovery point; RTO concerns tolerable resource unavailability. Neither is a measurement of a successful recovery. NIST treats testing as part of contingency planning. [6, sections 3.2.1 and 3.5.1]

Our reporting recommendation is to record both the target and the observed result. Name the failure being exercised, the newest usable recovery point, the start and end of recovery, and the checks that demonstrate usable service. A job's scheduled frequency and the time spent copying bytes are insufficient evidence on their own.

What to record in a recovery exercise

This is a proposed verification checklist, not a report of an experiment conducted by Hesela. Use an isolated test environment and approved recovery procedures.

• Identify the failure being simulated and which storage, credentials and keys remain available.
• List the captured datasets, volumes and logs, together with the application's required capture procedure.
• Document destination retention and who can delete both source and recovery copies.
• Restore a named recovery point and validate application-level behavior, not only successful file transfer.
• Record data recency and elapsed recovery time separately, with explicit success criteria and remaining limitations.

Read the structured definitions of snapshot, backup, application-consistent snapshot, RPO and RTO. For another protection boundary, see why scrubbing is not a durability guarantee.

Sources and limitations

Scope: OpenZFS v2.3 and PostgreSQL 18 documentation, Microsoft VSS documentation, NIST's 2010 contingency-planning terminology, and Chandy-Lamport's 1985 system model. Product-specific behavior must be checked against the deployed version. No restore experiment or product benchmark was performed.

1. OpenZFS v2.3: zfsconcepts(7), snapshots and storage pools
2. OpenZFS v2.3: zfs-snapshot(8), atomic and recursive snapshots
3. OpenZFS v2.3: zfs-send(8), full and incremental streams
4. PostgreSQL 18: File System Level Backup, section 25.2
5. Microsoft: Volume Shadow Copy Service, application writers and snapshot coordination
6. NIST SP 800-34 Rev. 1 (2010), sections 3.2.1 and 3.5.1: recovery objectives and testing
7. NIST CSRC glossary: Backup (SP 800-34 Rev. 1 definition)
8. OpenZFS v2.3: zfs-receive(8), -F and incremental replication
9. Chandy and Lamport (1985): Distributed Snapshots: Determining Global States of Distributed Systems, sections 2-4, ACM TOCS 3(1), 63-75