Practical guide

Write a restore runbook that someone else can follow

Last materially reviewed 2026-10-01

Quick answerA runbook needs an isolated target, stop conditions and proof of acceptance.
What to know

Define the boundary

State that the exercise uses an approved isolated target and cannot overwrite production. Name the person allowed to stop it. Describe the artifact, target version, required permissions and where authorized credentials are obtained—without embedding those credentials in the document.

What to know

Record expected checks

Before running anything, specify what success would look like: expected schema, representative record checks, application behavior and the maximum allowed elapsed time. Keep these expectations independent of the observed result. A check invented after the run can hide what was never tested.

What to know

Follow the matching procedure

Use the current official restore instructions for the artifact and engine. Capture the command or UI step safely in your organization’s protected record where appropriate. Review warnings, dependencies and ownership mapping; do not equate a completed import with a working application.

What to know

Close with an honest outcome

Record pass, fail or not tested for every acceptance item. Note corrective actions and the owner of the next rehearsal. The worksheet on this site is a planning aid, not a certification, a backup product or an automatic recovery service. It does not execute commands.

What to know

Give the next operator a stop rule

A practical runbook has explicit stop conditions: target identity is ambiguous, the expected artifact cannot be identified, protected access is unavailable, or a required dependency is missing. Put these before any modifying step. Fictional handoff: the target version differs from the approved rehearsal record. The operator pauses for compatibility review rather than improvising. A runbook should also identify who may authorize a revised exercise. These boundaries make the document usable by someone other than its author without pretending that a generic web checklist is production change approval.

Continue when useful

Next: Isolated target

Use a target whose mistakes cannot silently affect real users.

Open Isolated target →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. SimpleBackups PostgreSQL restoration — Merchant documentation · simplebackups.com · Merchant-controlled · checked 2026-10-01
  2. PostgreSQL: pg_restore — Platform documentation · postgresql.org · Merchant-controlled · checked 2026-10-01