Workflow: backup strategy combining history window, restore, and dumps

Workflow: layered backup strategy

Goal

Recovery coverage from "oops five minutes ago" to "compliance needs last quarter".

Steps

1. Set the history window for your recovery point objective: up to 7 days on Launch, 30 days on Scale. This covers recent human errors via instant restore and Time Travel.
2. Practice instant restore on a schedule (see the PITR drill workflow); an untested restore is not a backup.
3. For retention beyond the history window, schedule pg_dump to object storage (Neon documents automating nightly pg_dump to S3). Use the direct connection string.
4. Document the recovery runbook: which layer for which scenario, exact commands, who approves a production restore.
5. Separate concern: the deletion recovery period covers whole-project deletion; know it exists but do not rely on it as your backup.

Ordering constraints

• Set the history window before you need it; it does not backfill.
• Test-restore the pg_dump archives periodically; dumps nobody restored are hopes, not backups.

Traps

• Assuming the history window is archival: it caps at 30 days and meters History usage on the bill.
• pg_dump against the pooled endpoint under load can behave oddly; use direct.
• Long dumps hold resources; schedule off-peak.

Verify

Quarterly: restore each layer to a scratch branch and confirm the data. The runbook's commands are copy-paste current.

Neon's history window docs (verified live 2026-09-26) give the per-plan retention limits and note the window bounds instant restore/Time Travel/branching from past states; Neon's docs cover automating pg_dump backups to S3; the instant restore docs cover the drill mechanics.