Incremental Backup in PostgreSQL 17: A Summary

PostgreSQL 17 brings native incremental backup support directly into the database core, eliminating the previous dependency on third-party tools like pgBackRest or Barman. Instead of copying the entire dataset on every run, incremental backups capture only the data blocks that changed since the last backup, whether full or incremental. This results in faster backups, reduced storage consumption, and lower system overhead.

What Is Incremental Backup?

An incremental backup saves only what has changed since the previous backup. Unlike full backups that duplicate all data every time, incremental backups are leaner, quicker to create, and far more storage-efficient.

Key Features

• Native integration — No external tools needed; the feature is built into PostgreSQL 17.
• Storage efficiency — Only modified data pages are captured.
• Faster operations — Less data means quicker backup creation and streamlined recovery.

How It Works

1. Enable WAL Summarization — In postgresql.conf, set summarize_wal = on. This activates the WAL summarizer, which tracks modified data blocks. It is off by default and can be enabled on a primary or standby server.
2. Take a Full Backup — Use pg_basebackup to create the initial baseline backup.
3. Take the First Incremental Backup — Run pg_basebackup again with the --incremental flag, referencing the backup_manifest from the full backup so PostgreSQL knows what the baseline was.
4. Chain Further Incrementals — Each subsequent incremental backup references the backup_manifest of the previous one, forming a chain of changes.

Restoration

Recovery is handled by pg_combinebackup, a new utility in PostgreSQL 17 that merges the full backup and all incremental backups into one usable directory. Backups must be supplied in chronological order. After merging, the port is adjusted in postgresql.conf and the server is started from the restored data directory, with all records confirmed intact.

Advantages

• Cost savings — Less storage used means lower costs on cloud or on-premises setups.
• Better performance — Reduced data transfer lowers system load, especially during peak hours.
• Scalability — Ideal for large databases with frequent changes where full backups would be impractical.

Limitations

• summarize_wal must be enabled for the feature to function.
• Incremental backups require pg_basebackup and must be run from the primary server, not a standby.
• Recovery depends on a complete, unbroken chain — any missing backup in the sequence causes recovery to fail.
• Backups operate at the cluster level only; per-table backups are not supported.
• Proper retention of WAL and summary files is essential.

Conclusion

PostgreSQL 17 incremental backup tackles two longstanding challenges — excessive storage use and slow backup windows. With pg_basebackup's --incremental flag handling capture and pg_combinebackup handling restoration, the entire workflow is cleaner and more reliable, making it especially valuable for large, high-transaction database environments.