Backup strategy for Postgres in Kubernetes

A Postgres backup strategy on Kubernetes should layer three mechanisms: logical dumps with pg_dump for portable schema-and-data recovery, PVC volume snapshots for fast disk-level rollback, and Velero for namespace-wide disaster recovery that includes Secrets and workload manifests. SME teams need written RPO and RTO targets—not assumptions—and quarterly restore drills that prove backups are restorable, not merely scheduled.

DarDev runs Postgres for Twenty CRM, Listmonk, and client workloads on clusters we operate—nightly pg_dump to object storage, weekly VolumeSnapshots, and Velero for migration drills. The pattern fits a two-person platform team.

RPO and RTO for SME Postgres

Recovery Point Objective (RPO) is how much data you accept losing—up to twenty-four hours of transactions if backups run nightly. Recovery Time Objective (RTO) is how long until the application serves traffic again after failure. For most MENA SMEs running a single Postgres StatefulSet, aim for RPO under 24 hours and RTO under four hours on a tested runbook. Tighter targets require WAL archiving or streaming replication, which is a different cost and operations tier.

pg_dump: logical backups that travel

pg_dump produces a portable SQL or custom-format file independent of the underlying block device. Run it from a Kubernetes CronJob that reaches the Postgres Service—typically a Job using the official postgres client image and credentials mounted from a Secret. Store dumps in S3-compatible object storage with versioning enabled. Nightly dumps mean you may replay up to one day of writes unless you add WAL archiving.

• Use custom format (-Fc) for parallel pg_restore and selective table recovery
• Exclude large ephemeral tables only when the application can rebuild them safely
• Encrypt objects at rest; rotate backup credentials on the same schedule as production DB passwords
• Restore to a fresh staging namespace quarterly—never treat production as the first restore target

Logical dumps survive table-level corruption and can target a different Postgres major version after testing. Handle backup Job credentials like production secrets—see our Kubernetes secrets management guide.

PVC volume snapshots: fast rollback

When Postgres data lives on a PersistentVolumeClaim, your storage class may support VolumeSnapshot objects. A snapshot captures block-level PVC state at a point in time. Restore creates a new PVC and reattaches it to a rebuilt pod—often minutes instead of replaying a multi-gigabyte dump. Snapshots are crash-consistent unless you quiesce Postgres first; run a pre-snapshot hook that calls pg_start_backup() and pg_stop_backup(), or accept brief WAL replay on startup.

Velero: namespace disaster recovery

Velero backs up Kubernetes resources and, when configured, persistent volumes to object storage. It excels when you must recreate an entire namespace—StatefulSet, Service, Ingress, Secrets, and PVC data—on a new cluster or after control-plane loss. Install the Velero server and node agent, point a BackupStorageLocation at your bucket, and schedule nightly backups scoped to the postgres namespace.

• Include Secrets in backup scope; without them you restore data but cannot authenticate
• Enable CSI snapshot integration when your volume driver supports it
• Label critical resources so backup selectors survive Helm upgrades
• Keep Velero configuration in git; rehearse full namespace restore to staging quarterly

Velero is not a substitute for pg_dump when you need one table back. Pod rollback after a bad image is covered in our runbook for rolling back a bad deploy; Velero addresses namespace or cluster loss.

Restore drills: prove backups work

A backup nobody has restored is unreliable. Quarterly, restore one pg_dump to a staging namespace, run smoke tests, and time the exercise against your RTO target. Record steps: provision PVC, restore dump or snapshot, apply migrations, update Secrets, validate row counts.

1. Inventory backup assets

   List CronJobs, buckets, snapshot schedules, Velero backup names, and credential owners in one wiki page.

2. Pick a drill scenario

   Simulate accidental table drop, namespace deletion, or single-zone storage failure—rotate scenarios each quarter.

3. Restore in staging only

   Never practice first-restore under production incident pressure. Staging namespace fidelity matters; see staging environments that match production.

4. Verify application health

   Readiness probes, one critical API query, and comparison of checksums or row counts on finance or CRM tables.

5. Update the runbook

   Fix gaps discovered during the drill—missing labels, wrong bucket policy, expired backup SA token—before the real outage.

On dardev-vps and client clusters we alert when backup CronJobs fail or the newest dump is older than twenty-six hours—see monitoring deploy health with Prometheus for alert patterns.

Common mistakes

• Relying on PVC snapshots alone without logical dumps for portability
• Storing pg_dump files only on the same volume as Postgres data
• Skipping restore tests until ransomware or operator error forces one
• Cluster-admin backup tokens that never rotate when engineers leave
• Assuming a Helm upgrade preserved CronJob backup schedules and Velero labels

Start with nightly pg_dump and one documented restore path before adding Velero. DarDevOps applies these patterns on client engagements—see dardev.net/products for platform overview and contact.