Learn pgBackRest - Ecosystem, Alternatives & Final Reflection

#Introduction

This is the last episode of our 23-episode journey. Before closing, we need to answer the most honest question: is pgBackRest always the right choice? No. The PostgreSQL backup ecosystem has several strong candidates, each with a different philosophy — and choosing the wrong one means paying unnecessary costs.

In episode 22 we compare pgBackRest with pg_dump, Barman, WAL-G/WAL-G2, and CloudNativePG, map out when to choose each, then summarize the whole series into a production checklist you can turn into a working document.

#Comparing PostgreSQL Backup Tools

#pgBackRest

• Philosophy: a dedicated physical backup tool for PostgreSQL — parallel, PITR, retention, and object storage in one package.
• Strengths: full/diff/incr, continuous WAL archiving, encryption, multiple repositories, support for 10 PG versions, complete documentation.
• Trade-off: requires configuration and understanding (exactly what you learned in this series).

#pg_dump / pg_dumpall

• Philosophy: logical backup — exporting data as SQL/custom format.
• Strengths: flexible (can dump per-database/per-table), portable across versions and architectures, built into PostgreSQL.
• Trade-off: no PITR, slow for large databases, doesn't capture every state (permissions, blobs depending on mode), and restore isn't a "complete copy" but a SQL replay.

#Barman

• Philosophy: server-based — a central daemon managing backups from several database servers.
• Strengths: centralized architecture, enterprise environment integration, mature PITR and recovery features.
• Trade-off: a different architectural approach (central server), a bigger learning curve and more components.

#WAL-G / WAL-G2

• Philosophy: object storage-first — built around S3 from the start, a descendant of WAL-E.
• Strengths: lightweight, natural S3/GCS/Azure integration, popular for large scale and Kubernetes.
• Trade-off: reporting/retention and debugging features are simpler than pgBackRest; relies on external tooling for some operational needs.

#CloudNativePG (CNPG)

• Philosophy: K8s-native — an operator that wraps pgBackRest (its default) into Kubernetes resources.
• Strengths: full automation of stanza/backup/restore, declarative, HA integrated.
• Trade-off: only for Kubernetes; behind the scenes it still runs pgBackRest.

Logical                              Physical
pg_dump          WAL-G    Barman    pgBackRest
   <--- migration / portability --- physical recovery + PITR --->

#When to Choose Which

#Choose pgBackRest If...

• You need a reliable physical backup + PITR for production.
• The database is large and needs parallel backup, automatic retention, and encryption.
• You want one tool supporting many media (local, remote, object storage).
• You want support for up to 10 PostgreSQL versions in a single installation.

#Choose pg_dump If...

• You need migration or logical backup: moving across versions, across architectures, or only part of the data.
• The data size is still small and PITR isn't needed.
• You need a "readable" backup for specific purposes (analysis, small staging).

#Choose Barman If...

• You're already tied to a server-based architecture and need centralized management of many servers.

#Choose WAL-G If...

• Your architecture is S3-native and you want something lightweight, or you already use WAL-G in another ecosystem (for example Kubernetes without an operator).

#Choose CloudNativePG If...

• Your PostgreSQL database runs on Kubernetes and you want backups managed declaratively by an operator.

#Recap of Episodes 0-21

Our journey in brief:

• Phase 1 (0-2): Prerequisites, history, architecture — why and how pgBackRest works.
• Phase 2 (3-7): Installation, stanza & check, backup types, WAL archiving, parallelism & compression — basic operations.
• Phase 3 (8-12): Restore & PITR, recovery scenarios, scheduling & retention, encryption, remote & object storage — data management.
• Phase 4 (13-16): SSH & networking, monitoring & metrics, troubleshooting, restore drill — security and reliability.
• Phase 5 (17-20): Latest releases, standby backup & HA, large scale & benchmarks, Docker/K8s/cloud — quality and production.
• Phase 6 (21-22): Roadmap & community, comparison & reflection — context beyond the code.

#Production Checklist

This checklist document can be used directly before your backup system goes into production:

• Stanza created: pgbackrest --stanza=main stanza-create succeeds.
• Check passes: pgbackrest --stanza=main check — DB connection, repository, archive-push/get.
• Scheduling active: weekly full + daily differential via cron/systemd timer (episode 10).
• WAL archiving OK: archive_mode=on, correct archive_command, pg_stat_archiver.failed_count = 0.
• Encryption at rest: repo1-cipher-type=aes-256-cbc, passphrase in a secret manager (episode 11).
• Retention determined: based on RPO/RTO, including repo1-retention-archive (episode 10).
• Periodic restore drill: scheduled restore test + report + runbook (episode 16).
• Monitoring active: backup age, late backups, stuck WAL, full repository (episode 14).
• Off-site object storage: a second repo at a different location (episodes 12, 20).
• Secure transport: SSH key auth, dedicated user, VPN/tunnel for remote (episode 13).

#Official Learning Resources

• pgbackrest.org: User Guide, Configuration, Command Reference, News.
• github.com/pgbackrest/pgbackrest: repository, releases (2.59.0), issue tracker.
• PostgreSQL docs: WAL archiving (archive_mode, archive_command) — the foundation you must understand.
• pgbackrest_exporter: Prometheus metrics for monitoring (episode 14).
• CloudNativePG docs: the Kubernetes operator with built-in pgBackRest (episode 20).
• Continue to the next series: learn-sql-postgresql (DB fundamentals), learn-cronjob (scheduling), learn-velero (K8s backup), learn-restic/learn-borg-backup (file backups), and learn-vault (encryption key management).

#Conclusion

Key takeaways:

• pgBackRest: reliable physical backup + PITR, parallel, multi-repository, supports 10 PG versions.
• pg_dump for migration/logical; Barman for server-based; WAL-G for lightweight S3-native; CNPG for K8s.
• Choose based on workload needs, not hype — they can even coexist.
• 23 episodes built the foundation: prerequisites → architecture → operations → security → production.
• The production checklist is the bridge from "can run a backup" to "confident you can recover."

Congratulations, you've completed Learn pgBackRest! From the prerequisites, your first stanza, precise PITR, all the way to Kubernetes integration and the production checklist — you now have the groundwork to make PostgreSQL backups a reliable part of your infrastructure. Technology will keep evolving — follow the releases, keep the passphrase safe, and most importantly: keep testing your restores. The 23-episode journey is over, but the responsibility of safeguarding your data has just begun!