# 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.