Backup and Recovery Checklist

A Green Backup Job Is Not Yet a Recovery Plan

A backup records some state. Recovery returns the product to useful service after damage. Between those two events sit credentials, commands, encryption keys, provider access, dependent services, and the question that matters most: how will you know the restored product is correct?

For a solo founder, this distinction is easy to postpone. The database console reports successful snapshots, so the risk appears handled. Then an accidental deletion, destructive migration, compromised account, or provider failure reveals that the snapshot excludes uploaded files, the restore command needs a missing secret, or the process takes longer than customers can wait.

Use this review for one customer capability, not for “the whole stack” in the abstract. Begin with a failure you need to survive: all production data is deleted, a bad deployment corrupts recent records, the primary region is unavailable, or an attacker gains the application’s credentials. Different failures defeat different recovery plans.

Begin With the Customer Consequence

Decide how much data the product can lose and how long the capability can remain unavailable. These are business decisions before they are infrastructure settings.

The recovery point objective, or RPO, is the maximum acceptable gap between the failure and the restored state. If backups run every 24 hours, a failure just before the next backup could lose nearly a day of work. A four-hour RPO means the complete recovery chain must preserve a usable point no more than four hours old; a database snapshot alone does not satisfy it if required objects or events are older.

The recovery time objective, or RTO, is the longest acceptable time to restore the capability. Measure from the disruption, not from the moment the restore command begins. Detection, diagnosis, access recovery, data transfer, rebuilds, verification, and traffic cutover all consume the interval.

Choose targets from the consequence. Losing a day of draft preferences may be tolerable. Losing a day of approved invoices, customer uploads, or entitlement changes may not be. An ambitious target also creates cost and operating burden: more frequent copies, faster standby capacity, tighter monitoring, and more rehearsal. Do not promise a five-minute recovery because a provider advertises point-in-time restore.

Trace What Must Return Together

Follow the customer capability through its authoritative and supporting state. A reporting workflow might depend on account and report records in a database, source files in object storage, a queue of pending generation jobs, configuration and secret references, application artifacts, and a payment entitlement held partly by an external provider.

For each component, choose one of three recovery paths:

• Restore it from a protected copy.
• Rebuild it from an authoritative source, as with a search index or cache.
• Reconcile it with another system, as with payment-provider events or messages whose delivery status is uncertain.

Replication and availability features may keep a product running through hardware failure, but they can also reproduce an accidental delete or corrupt write. Treat a replica as a backup only when its history, access boundary, and tested restore behavior actually survive the failure in question.

Inspect the recovery source as skeptically as production. Can the same mistaken command, compromised credential, expired account, or provider incident destroy both? Use separate permissions and, where the threat requires it, a separately controlled, immutable, or offline copy. Record retention explicitly: too little history may leave no clean point before slow corruption; indefinite retention increases cost, privacy exposure, and deletion obligations.

The recovery record must include the means of opening encrypted backups. A key that exists only inside the failed environment makes a sound copy unusable. Access should remain narrow, but emergency access that nobody can obtain is not a control; it is a dead end.

Rehearse the Restore, Not the Backup

Run the procedure in a clean, isolated environment with the same commands and permissions intended for an incident. Do not overwrite production to prove that recovery works. Start from the written record and note every undocumented choice, missing dependency, manual console step, and permission failure.

A successful command is only the midpoint. Verify the recovered point in time, inspect representative records and files, and exercise the customer journey. Check business invariants that corruption could violate: paid workspaces still have access, approved reports still reference an existing artifact, deleted accounts have not returned to active service, and queued jobs will not repeat an irreversible action. Rebuild derived stores, reconcile external state, and confirm that new writes succeed before declaring recovery complete.

Time the entire drill. If it misses the recovery target, change the capability, the target, or the recovery design. A checklist should expose that decision, not conceal it with a passing backup status.

Copyable Recovery Record

Write exact commands and locations. Keep secret values out of the record, but name how authorized access is obtained.

# Recovery review: [one customer capability]

Owner:
Failure being rehearsed:
Customer consequence while unavailable:
Maximum acceptable data loss (RPO), in plain language:
Maximum acceptable time to useful service (RTO), in plain language:

## State map
Authoritative data and location:
Files or object storage:
Queues, logs, or events needed for replay:
Derived state to rebuild:
External systems to reconcile:
Application artifact, configuration, and secret references:

## Recovery sources
Backup or history mechanism for each authoritative source:
Schedule, newest expected recovery point, and oldest retained recovery point:
Retention and deletion policy:
Encryption and key-recovery path:
Permissions required to restore:
Failure boundary: what could damage production and its recovery source together?
Backup-age or failure alert and destination:

## Restore procedure
Isolated restore destination:
Exact restore commands or provider workflow:
Application and infrastructure reconstruction steps:
Replay, rebuild, and reconciliation order:
Traffic or customer-access cutover:
Safe degraded mode if full recovery misses the target:

## Proof
Expected recovery point and observed recovery point:
Representative records and files checked:
Business invariants checked:
Customer journey exercised:
New write and read verified:
Elapsed time from declared failure to useful service:
RPO met: yes | no
RTO met: yes | no

## Follow-through
Undocumented steps, missing access, or failed checks:
Customer communication required:
Next corrective action and owner:
Next drill date or change that triggers an earlier drill:
Evidence location:

The record is ready when another careful operator could identify the intended recovery point, obtain authorized access, restore the capability, and decide from evidence whether it is safe to use. For a solo founder, that operator is often the same person working with an unavailable product and waiting customers.

Worked Drill: Recover the Agency Import

The reporting product used in the preceding release plan stores agency accounts and report metadata in a relational database, uploaded source files in object storage, and generation work in a queue. Reports are useful only when their database record and approved artifact agree. Recreating the database while losing the objects would produce references to nothing; restoring the objects alone would leave the application unaware of them.

The founder chooses a hypothetical target: at most four hours of accepted work may be lost, and the import capability should return within one business day. The review maps database history and object versions to the same time window, identifies the application artifact and secret references needed to start clean infrastructure, and treats the search index as rebuildable. Payment entitlements will be reconciled against the provider rather than trusted from an arbitrary restored instant.

The rehearsal begins in an isolated environment. The founder restores both authoritative stores to the chosen point, starts the recorded application artifact, rebuilds the index, and prevents queued generation jobs from running until their operation identifiers have been checked. Verification samples an agency, an approved report, its source-file retention state, and its final artifact. The founder then runs a synthetic import through generation, approval, and retrieval while measuring the full recovery interval.

Suppose the database restore succeeds but several approved reports have no corresponding object version. The drill has failed even if its dashboard is green. The next action is not to lower the standard in the record. It is to repair the object-retention or replication gap, decide how the product behaves when an artifact cannot be recovered, and repeat the drill.

Keep Recovery Proportional and Current

A narrow product does not need an elaborate disaster-recovery estate by default. It does need an honest account of what customers can lose, a recovery source outside the chosen failure boundary, and a restore that has been observed end to end. Test again after changing storage, regions, encryption keys, identity providers, data models, queues, or deployment architecture; those changes can invalidate a once-working procedure.

Do not schedule drills so aggressively that the ritual consumes the founder. Tie their frequency to consequence and rate of change. What matters is that the last result remains credible for the system that exists now.

Recovery is complete when the customer capability works with verified state and bounded uncertainty. The existence of a backup is where that proof begins.