A backup you have not restored is only a guess

Once a week a scheduled job restores the most recent database backup into a throwaway database, checks it, and deletes the copy. Nothing is written back to production. The goal is not to keep a recovery warm. It is to answer one question: can this backup actually be read?

A dump that exits cleanly only proves the file was written. It says nothing about whether it loads. So the drill checks the things a file-size check would miss.

Row counts on the core tables match the live database. A backup that restores to empty tables failed silently.

Row-level security is still on, on the same tables. Policies are schema, not data; a restore that drops them leaves the rows readable to anyone who can reach the database.

The security definer functions keep the search_path they were created with. Lose it and name resolution falls to a caller-controlled path, which is a long-standing route from helper function to privilege escalation.

The backups are not encrypted. They carry ciphertext and account metadata, and no plaintext keys — the recovery key and the data master key never reach the server. So a leaked backup reveals nothing readable, and the directory is root-only besides.

The remaining gap is the off-site copy. Today it pulls to a second machine and compares a checksum. A different provider would be better than a different machine.