Database backups, snapshots and consistency

What it means

A snapshot describes a captured storage state; a recoverable backup describes what you can reconstruct from preserved data. These are not opposing product categories. A snapshot may contribute the starting copy, but you still need evidence that the copy meets the database engine's requirements and supports the intended recovery method.

For the PostgreSQL 18 physical recovery method discussed here, compare the evidence rather than the labels:

The simulation isolates the middle question. By assuming a valid base, it lets you see exactly why missing history changes the reachable target without pretending to validate the starting copy.

For a PostgreSQL 18 filesystem-level backup, a usable starting copy must cover the whole database cluster and the files needed for recovery, not an arbitrary subset of relation files. A live snapshot must be consistent across the relevant data, WAL and tablespace storage; taking unrelated volume snapshots at different times does not establish that condition. The lab assumes a valid starting snapshot. Its time-window calculation cannot repair an inconsistent base copy.

Try it

Simulation: change Missing segment from 3 to none, then inspect the current result and its explanation. Use Compare with baseline to display the baseline and current outcomes together. This is a local calculation, not a backup check or restore. Without JavaScript, the initial example remains readable, but the controls are unavailable.

Requested recovery target is not covered. Base: minute 0. Available log segments: 1, 2, 4, 5, 6. The uninterrupted chain ends at minute 2; target is minute 5. A later archived segment cannot fill an earlier gap. Locate the missing evidence; do not claim point-in-time recovery from snapshot existence alone.

Keep Requested recovery minute = 5 and Last archived log minute = 6. The assumed valid base stays fixed at minute 0; only the presence of segment 3 changes.

Reset restores Requested recovery minute = 5, Last archived log minute = 6, and Missing segment = 3. It removes input errors, clears the comparison, and returns the displayed result to the baseline. There is no running clock or stored event history. Reset preserves your independent choices to open or close FAQ answers and About this model.

How it works

The model separates a starting state from the changes needed after it. It assumes the base at minute 0 is already valid. Each later segment supplies the next step in reconstructing the state, so the calculation first finds how far the sequence remains uninterrupted and only then compares that boundary with the target.

With segment 3 missing, segments 1 and 2 connect to the base, but segments 4, 5, and 6 sit beyond a break. Their presence does not establish the missing transition. The modeled chain therefore ends at minute 2, even though the archive contains a segment labeled 6. A target at minute 3 is already beyond that boundary; the failure is not specific to the default target of minute 5.

This illustrates the dependency behind PostgreSQL 18's physical base-backup and archived write-ahead log (WAL) recovery method: the needed sequence must be available from a compatible base. It does not establish that a particular snapshot supplies that base. Consistency of the starting copy, continuity of the required history, and successful recovery are separate questions. Passing the continuity check cannot repair an unsuitable starting copy or stand in for a restore test.

Worked example

This is a synthetic sequence, not an observation of a database or backup service.

The assumed base is at minute 0. Available log segments are 1, 2, 4, 5, 6. Following the sequence from the base reaches minute 2, then stops because segment 3 is absent. The requested target, minute 5, lies beyond that boundary, so the result is Requested recovery target is not covered.

The useful distinction is between the newest available segment, 6, and the last continuously reachable minute, 2. Only the second answers whether this modeled base can reach the target.

What changes when the condition changes

Change Missing segment to none. Keep Requested recovery minute = 5 and Last archived log minute = 6.

Target covered by the modeled log chain. Base: minute 0. Available log segments: 1, 2, 3, 4, 5, 6. The uninterrupted chain ends at minute 6; target is minute 5.

The change supplies segment 3, connecting segments 1–2 to segments 4–6. The target becomes covered because the dependency gap has closed, not because the newest archived minute has increased. Real backup validity, timelines, checksums, configuration and an isolated restore still need verification.

In practice

For a PostgreSQL 18 recovery assessment, begin with read-only access that you are authorized to use. Identify the proposed physical base, database version, required archived WAL, recovery timeline, and target. Record which evidence establishes base compatibility and log continuity. PostgreSQL 18's filesystem-level backup section, 25.2, addresses the starting copy; continuous archiving and recovery, section 25.3, addresses the base-and-WAL recovery method.

The expected planning result is an identified starting point and a supported path to the requested target—not merely a successful snapshot job or a recently archived file. STOP if the base's suitability, required sequence, or timeline is unknown. Preserve the source database, backups, and archives; do not overwrite them or discard logs on the strength of this simulation.

A real restore is outside this page's procedure. Before commissioning one, require an authorized, platform-specific plan naming the exact backup set, target, and isolated nonproduction destination. Confirm the operator's restore permissions and preserve any destination state that must survive the test. Production switching requires separate authorization; permission to run a drill is not permission to replace the live database.

Verify the recovered state against the requested target and test the required application behavior. If the result differs or isolation is uncertain, stop rather than promoting the restored system. The plan must also define rollback for the test destination: return it to its preserved before-state, or recreate it only if it was explicitly disposable. After rollback, verify that the destination is in the intended state and that production and the source backup artifacts remain unchanged.

Limits and unknowns

The controls accept Requested recovery minute and Last archived log minute in the labeled 0–10 range, with Missing segment set to none, 3, or 5. Empty or invalid input removes the calculated outcome until you correct it or use Reset; an earlier valid result must not be treated as the answer to an invalid draft.

For valid inputs, this model answers only whether the target is covered by its assumed sequence. It does not inspect a real backup or produce a real-world recovery diagnosis. If you do not know whether an actual base is usable or whether all required logs are present, recoverability remains unknown—not proven by either modeled verdict.

The one-segment-per-minute representation is deliberately unlike the layout of real PostgreSQL WAL files. A real archive's file count or newest timestamp cannot be substituted directly for these minute values. Compatibility, integrity, configuration, timelines, and a verified isolated restore remain outside the calculation.

What to carry forward

Judge a recovery option by the starting state it can restore, the uninterrupted history needed to reach your target, and the evidence from an isolated recovery test—not by whether it is called a snapshot or a backup. Your next safe step is to identify those three kinds of evidence. If any is missing, keep the recovery claim qualified rather than treating the newest archive file as proof.