Physical backup stream

PostgreSQL Base Backup Storage & Transfer Planner

Estimate target footprint and completion time when a physical base payload and WAL generated during the backup share one measured stream path.

Decision guide

A physical backup grows while the source continues to write

What this tool helps you decide

This planner estimates how long a PostgreSQL physical base backup takes and how much target space it occupies when WAL is generated throughout the transfer. It reports effective stream rate, net base-payload progress, duration, WAL created during the backup, per-copy footprint, total target footprint, target headroom, and minimum free target capacity. It also identifies a non-converging scenario where the entered WAL rate equals or exceeds the shared backup stream rate.

Before you start

Measure or estimate the base payload after applying the exact output format and compression choice you intend to use. Benchmark effective end-to-end throughput across the source, network, encryption or compression stage, and target storage. Measure WAL generation across a comparable busy window in stored GB per hour. Decide whether several physical copies are written independently and therefore consume separate target capacity. Record current free target bytes rather than label capacity and keep unrelated data outside that number.

How the calculation works

Decimal MB/s becomes GB per hour by multiplying by 3.6. WAL generation shares the stream in this planning model, so net base progress is stream GB per hour minus WAL GB per hour. Duration equals base payload divided by positive net progress. WAL generated during the backup is WAL rate multiplied by duration. Per-copy footprint adds base payload and generated WAL. Total target footprint multiplies by copies, and usable target capacity applies the selected reserve.

How to interpret the results

A capacity pass means the modeled stream converges and the resulting copies fit the reserved target. It does not prove the backup is restorable, that the source retains every required WAL segment, or that throughput remains constant. If WAL rate approaches stream rate, the completion estimate grows rapidly; treat that as a reason to benchmark during a representative load and improve the path. A capacity failure means add target space, reduce simultaneous copies, or change measured payload and format only after validating the recovery requirement.

Worked example

A 1,200 GB base payload streams at 180 MB/s, or 648 GB per hour. The primary generates 24 GB of WAL per hour, leaving 624 GB per hour of net base progress. Estimated duration is about 1.92 hours and approximately 46.15 GB of WAL is created, so one copy occupies about 1,246.15 GB. A target with 2,000 GB free and 15% reserved offers 1,700 GB and leaves about 453.85 GB of headroom.

Assumptions and limitations

PostgreSQL notes that total backup size can grow beyond the initial estimate when WAL is included. This transparent equation assumes base bytes and WAL share one constant effective throughput and that the entered base payload already reflects compression. Real pg_basebackup behavior varies by format, compression location, WAL method, tablespaces, parallelism, source writes, checkpoints, network contention, target synchronization, and version. The tool does not execute a backup, inspect progress, guarantee WAL availability, estimate restore time, validate manifests, or replace a restore test.

Next steps

Confirm the chosen options in the current official pg_basebackup documentation. Run a representative backup, compare actual bytes and duration, preserve its manifest and logs, and restore it into an isolated environment. Monitor both target capacity and source WAL retention until completion. Use the WAL Retention & Replication Slot Planner for the source-side outage window, and the Backup Verification Schedule Planner to schedule recurring recovery evidence.