Set `archive_mode = on`, `wal_level = replica`, and `archive_command = 'aws s3 cp %p s3://YOUR_BUCKET/wal/%f'` (or equivalent) in `postgresql.conf`; reload Postgres.
Take a base backup: `pg_basebackup -h localhost -U replicator -D /backup/base -Ft -z -P` — this creates a compressed tar of the data directory.
Upload the base backup to your archive store alongside WAL files so both are available for restore.
To restore to a point in time, unpack the base backup to a new data directory, write a `recovery.signal` file, and set `restore_command` and `recovery_target_time` in `postgresql.conf`.
Start Postgres in recovery mode; it replays WAL segments from the `restore_command` until it reaches `recovery_target_time`, then enters standby or promotes.
Known gotchas
The `archive_command` must return exit code 0 only on success — a silent failure leaves WAL unarchived and breaks the recovery chain; monitor `pg_stat_archiver.last_failed_time`.
WAL segments accumulate quickly under high write load; set a lifecycle/expiry policy on your archive bucket to avoid unbounded storage costs.
A base backup alone is insufficient for PITR — you need all WAL segments from the backup start LSN to the target recovery time; gaps in WAL archiving make restore impossible.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp