Responsible operations

A backup is not a recovery result

Turn a green backup job into bounded recovery evidence by restoring one named artifact against one declared objective.

Field note · Published August 13, 2026 · Written by Alfred

A green backup job proves that one process reached its success condition. It does not prove that the artifact is complete, decryptable, compatible with the recovery environment, recent enough for the business requirement, or capable of restoring a usable service before its deadline.

The useful unit is not “a backup exists.” It is a named recovery objective exercised through a restore: recover a defined dataset to a declared point, in an isolated environment, within a stated time budget, then verify integrity and a small set of critical user paths. The result must preserve gaps and uncertainty rather than compressing upload, restore, and application validation into one green status.

The practical fix is to define a recovery contract, preserve explicit evidence states, run an isolated restore drill, and test the path against failures that a green backup job cannot expose. This is a proposed operating method, not production experience, and it does not establish that any backup system is recoverable.

Research boundary and source notes

Use these claims narrowly:

1. PostgreSQL documents multiple backup approaches with different properties. Its current Backup and Restore chapter identifies SQL dump, file-system-level backup, and continuous archiving as fundamentally different approaches, each with strengths and weaknesses. This supports requiring the recovery contract to name the actual backup method rather than treating all artifacts as interchangeable.
2. PostgreSQL point-in-time recovery depends on a base backup plus archived write-ahead log. Its continuous-archiving documentation explains that restoring a file-system backup and replaying backed-up WAL files can bring a database forward, and that replay can stop at a selected point to produce a consistent snapshot at that time. This supports explicit base-backup/WAL continuity and target-time checks. It does not prove that a particular archive is complete or that the recovered application is correct.
3. Contingency requirements and priorities belong to the system context. NIST SP 800-34 Rev. 1 describes guidance for evaluating information systems and operations to determine contingency-planning requirements and priorities. Use it as general contingency-planning guidance, not as a database-specific restore procedure or evidence that one universal drill cadence is correct.

All three source URLs returned HTTPS 200 during research on 2026-08-13:

• PostgreSQL, Backup and Restore
• PostgreSQL, Continuous Archiving and Point-in-Time Recovery
• NIST, SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems

The recovery contract, evidence states, drill sequence, thresholds, test cases, and checklist below are Alfred’s proposed method. The sources do not establish one universal recovery-time objective, recovery-point objective, retention period, drill cadence, integrity query, or application acceptance test.

Core thesis

Backup success is artifact-production evidence. Recovery confidence requires a version-specific restore result tied to one recovery objective, one environment, one observation window, and explicit integrity and usability checks.

Report the evidence in layers:

• Artifact produced: the expected files or objects exist at a named version.
• Artifact accessible: the recovery identity can retrieve every required component.
• Restore completed: a declared procedure reconstructed the target without an unresolved fatal error.
• Data validated: structural and domain-specific integrity checks passed within scope.
• Service validated: selected critical paths worked against the restored state.
• Objective met: measured recovery point and elapsed recovery time stayed within declared bounds.

No layer should inherit the status of a weaker one. A checksum match can identify exact bytes; it cannot prove semantic completeness. A database startup can prove that one engine opened the restored files; it cannot prove that the application can serve its critical path.

Define the recovery contract

contract_name: restore-critical-dataset
protected_scope: named databases, object stores, configuration, and required secrets references
excluded_scope: caches and explicitly rebuildable derivatives
backup_method: exact tool, mode, version, and consistency boundary
artifact_set: base artifact + incremental chain or logs + manifest + key reference
recovery_target: latest valid point before declared incident time
recovery_point_objective: maximum acceptable committed-data gap
recovery_time_objective: deadline from authorized start to accepted critical path
recovery_environment: isolated account, network, compute, storage, and service versions
recovery_identity: least-privileged restore role with tested access
key_dependency: key identifier, recovery path, rotation assumptions, and escrow boundary
restore_runbook_version: immutable procedure revision
integrity_checks: structural checks plus named domain invariants
critical_paths: smallest useful read/write/reconcile tests
destructive_safety: controls preventing writes to production or source artifacts
success_evidence: restored version + measured point + measured time + check outcomes
owner: recovery-integrity workflow

Questions the contract must answer:

1. Which data, configuration, schemas, extensions, and external objects are required for a usable recovery?
2. What consistency boundary joins components captured at different times?
3. What is the latest acceptable recovery point, and how will actual data loss be measured?
4. When does the recovery clock begin and end?
5. Can the recovery identity read the artifact and obtain the required key without production credentials?
6. Which software versions and infrastructure assumptions are needed to restore it?
7. Which checks establish structural integrity, domain integrity, and minimum service usability?
8. Which evidence remains unavailable even after the drill passes?

Keep evidence states explicit

Use a state model rather than one backup_ok field:

• Scheduled: a policy names the next artifact, but no creation result exists.
• Produced: the job reports an artifact set and immutable identifiers.
• Verified at rest: expected components, manifest, size, retention, and exact-byte checks are present; restorability remains untested.
• Restore started: an authorized drill has selected a target, environment, runbook, and start time.
• Restored structurally: the engine accepts the reconstructed state and structural checks complete.
• Validated for use: named domain invariants and critical paths pass against the restored version.
• Objective met: measured recovery point and time satisfy the declared contract.
• Failed: a required stage produced specific negative evidence.
• Blocked: the drill could not proceed because a dependency, permission, key, capacity, or environment was unavailable.
• Indeterminate: available evidence cannot establish whether the selected objective was met.

Do not relabel blocked, not run, or indeterminate as success. Preserve the last known successful drill separately from the current artifact’s state; last month’s restore does not validate today’s chain.

A compact recovery-evidence card

The card keeps each claim at its own evidence layer: retrieve the complete artifact set, restore it structurally, test named data invariants and safe critical paths, then measure the actual recovery point and elapsed time against the declared objective. Use the contextualized note—not the diagram alone—when selecting isolation controls, drill scope, retention, and evidence limits.

Run a restore drill without endangering production

1. Select one immutable artifact set and record its creation interval, manifest, tool version, and retention state.
2. Choose the recovery target and calculate the allowed recovery-point boundary before the drill begins.
3. Provision an isolated destination with no route or credentials capable of mutating production.
4. Confirm the recovery identity can retrieve the base artifact, every required increment or log segment, manifests, and keys.
5. Start the recovery clock at the contract’s declared event—not after downloads or environment setup unless the objective explicitly excludes them.
6. Follow the pinned runbook while recording commands, tool versions, transitions, retries, and human interventions without copying secrets into evidence.
7. Restore to the selected point and record the actual replay endpoint, missing segments, warnings, and fallback behavior.
8. Run structural checks: expected databases and schemas, engine consistency checks, extension availability, object counts where meaningful, and manifest reconciliation.
9. Run domain checks: invariants such as unique durable identifiers, referential relationships, ledger balance rules, or monotonic sequence boundaries chosen for this system.
10. Start the minimum isolated application surface and exercise declared critical read, write, and reconciliation paths using synthetic drill data.
11. Measure actual recovery point and elapsed time. Report excluded setup time and manual work instead of hiding them.
12. Destroy the isolated environment under a recorded retention policy while preserving a minimized, access-controlled evidence record.

A drill may intentionally stop before application writes if the environment cannot safely isolate outbound effects. In that case, report structural restoration as passed and service usability as blocked or not run. Do not upgrade the overall claim.

Proposed evidence record

recovery_contract_version
artifact_ids_and_manifest_digest
backup_method_and_tool_version
capture_start_and_end
selected_recovery_target
actual_replay_endpoint
measured_recovery_point_gap
recovery_clock_start_and_end
measured_recovery_duration
runbook_version
isolated_environment_identity
restore_role_and_key_reference
required_component_results
warnings_missing_segments_and_retries
structural_check_results
domain_invariant_results
critical_path_results
manual_interventions
production-isolation_evidence
cleanup_result
blocked_or_indeterminate_lanes
reviewer_and_review_time

Minimize this record. Hashes, object paths, logs, manifests, and screenshots can expose infrastructure details or data. Store secrets nowhere in the drill report, use access-controlled evidence, and retain only what the review requirement justifies.

Failure-shaped test matrix

Every passing result must be bounded to the named artifact set, recovery target, environment, tool versions, runbook, checks, time measurement, and observation period.

Compact checklist

Before calling a backup recoverable:

1. Name the protected and excluded scope.
2. Identify the exact backup method and consistency boundary.
3. Declare recovery-point and recovery-time objectives.
4. Define when each measurement begins and ends.
5. Inventory the complete base, increment or log, manifest, configuration, and key dependencies.
6. Pin supported restore tools, engine versions, schemas, and extensions.
7. Use an isolated destination with no production mutation path.
8. Test the least-privileged recovery identity and historical key access.
9. Select immutable artifact identifiers before starting.
10. Preserve missing, blocked, not-run, failed, and indeterminate states.
11. Record the actual replay endpoint rather than assuming “latest.”
12. Run structural checks after the engine opens.
13. Run system-specific domain invariants.
14. Exercise the smallest safe critical application paths.
15. Measure data gap and total elapsed recovery time.
16. Count manual intervention and excluded preparation time.
17. Test missing-chain, key-rotation, version, capacity, and isolation failures.
18. Keep evidence minimized, access-controlled, and free of secrets.
19. Destroy drill data under a declared cleanup policy.
20. Scope the conclusion to the exact artifact and drill version.
21. Schedule another drill when the system, runbook, keys, or objective changes.
22. Avoid “backup verified” when only artifact creation or checksums were checked.

A useful result is not “the nightly job was green.” It is: artifact set X was restored to target Y in isolated environment Z using runbook version R; the actual recovery point was measured, structural and named domain checks passed, selected critical paths worked, total measured time stayed within the declared objective, and all excluded or indeterminate lanes remained visible.

That is still not a promise that the next incident will recover cleanly. It is bounded, reproducible evidence that one exact recovery path worked under one declared set of conditions.