In production you don't hand-roll archive_command with cp — you use a purpose-built tool. The big three are pgBackRest, Barman, and WAL-G, and all three wrap base backups plus WAL archiving with compression, integrity checks, retention, and parallelism. Knowing why these exist is the senior answer to "how do you actually run backups?"
Why not just scripts?
A bare archive_command = 'cp %p /archive/%f' has no compression, no encryption, no checksums to detect a corrupt segment, no retention policy, no parallelism, and no built-in restore orchestration. These tools solve all of that and turn PITR into a couple of commands.
pgBackRest
The most full-featured, widely adopted choice. Written in C, it offers parallel backup and restore, full/differential/incremental backups, per-block compression, encryption, page-level checksum verification, and direct S3/Azure/GCS repositories. You wire it in via archive_command, and it organizes everything under a "stanza."
pgbackrest --stanza=main backup --type=incr
pgbackrest --stanza=main --type=time --target='2026-06-02 09:13:00' restorearchive_command = 'pgbackrest --stanza=main archive-push %p'Barman
"Backup and Recovery Manager," from EnterpriseDB. It's a catalog-oriented tool that typically runs on a dedicated backup server and manages many PostgreSQL instances centrally. Supports both WAL streaming and archive_command, retention policies, and one-command recovery.
barman backup pg-primary
barman recover --target-time '2026-06-02 09:13:00' pg-primary latest /var/lib/postgresql/17/mainWAL-G
Successor to WAL-E, designed for cloud object storage first (S3, GCS, Azure). Lightweight, very fast with parallel compressed uploads, and popular in Kubernetes/containerized setups. Handles base backups and WAL push/fetch, including delta backups.
wal-g backup-push /var/lib/postgresql/17/main
wal-g backup-fetch /var/lib/postgresql/17/main LATEST