Our Sunday full backup of a 2.4 TB cluster had stretched to nine hours and the object-storage bill looked like a second salary. PostgreSQL 17's native incremental backup cut the weeknight run to about 95 GB — but the first…
Database Topic Archive
Backups and Durability Articles
Backups, restores, PITR, archive gaps, and recovery drills for PostgreSQL.
When a bad migration forced a real point-in-time recovery, our restore took nine and a half hours against a two-hour RTO — replaying 1.8 TB of WAL is single-threaded, and we had never once timed it. The drill routine, the…
Expired object-store credentials made archive_command exit 1 at 02:11; by 07:40 pg_wal held 380 GB on a 500 GB volume. The failure was visible for hours in pg_stat_archiver — the view almost nobody graphs.
mysqldump, XtraBackup, and the clone plugin map surprisingly well onto pg_dump, pg_basebackup, and pgBackRest. The concepts transfer; the tools, PITR mechanics, and failure modes do not.
PITR lets you restore the database to any moment within your retention window. The feature is well-documented; the operational reality is messier.
Most teams have backups. Most teams have never restored from one. The first time you test, you find out the backup was missing something.
Logical and physical backups solve different problems. Most teams need both, but only have one. Here is the actual decision framework.
WAL accumulates fast. The retention policy is a tradeoff between PITR window and storage cost. Here is how I think about it.
Backups only matter if restore is rehearsed. The real work is choosing RPO/RTO, preserving WAL, testing restores, and knowing what data you can afford to lose.