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

## TL;DR

Recovery coverage from "oops five minutes ago" to "compliance needs last quarter". Quarterly: restore each layer to a scratch branch and confirm the data. The runbook's commands are copy-paste current.

Use this when you run into the situation in the title.

**When not to use this skill:** unrelated tasks. It covers only the procedure above.

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

   Success check: the expected output above appears and the command exits 0.

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.

   Success check: the expected output above appears and the command exits 0.

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.

## Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

## Details

# Workflow: layered backup strategy

## Goal

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