A backup job should be judged by a measured restore drill, because a successful object upload says nothing about whether the application can recover within its recovery objectives. Start with an isolated restore, a bounded verification query set, and an alert on the age of the latest verified archive; scheduling the dump is the easy part.

Short answer: run logical exports in a separate worker, compress and store each run under a unique key, then promote it to a recovery point only after an isolated restore and application checks succeed.

The important unit of work is the recovery point, not the file. A file can be complete, readable, and still be useless because it came from the wrong database, was overwritten by a later run, or depends on roles, extensions, migrations, and capacity that were absent from the test.

What should a Postgres backup, object storage, gzip, restore, and signed URL runbook verify?

Write down the recovery point objective and recovery time objective before choosing a schedule.…