Backup Kubernetes PersistentVolumes
This how-to guide explains how to back up Kubernetes PersistentVolumes (PVs) used by Hybrid Manager
For general storage architecture recommendations, see Kubernetes storage best practices. For troubleshooting guidance, see Troubleshooting Kubernetes.
Important: Backup methods and tooling vary by Kubernetes platform and cloud provider.
Understand backup requirements
Hybrid Manager Postgres clusters store critical data on Kubernetes PersistentVolumeClaims (PVCs). Backups are required to meet disaster recovery (DR), compliance, and operational needs.
Typical backup goals:
- Protect Postgres data volume (PVC)
- Protect WAL volume (if used)
- Protect critical Hybrid Manager platform data (where applicable)
Important notes:
- Use application-aware backups whenever possible.
- Avoid relying on raw PVC snapshots alone unless coordinated with database quiesce.
- Hybrid Manager supports database-native backup pipelines → these should be your primary backup mechanism.
- PVC-level backups can be used as an additional DR safeguard.
Backup methods
Common backup approaches for Kubernetes PVs:
Database-native backup (preferred) Use Hybrid Manager or Postgres Operator backup features to perform database-consistent backups to object storage.
Volume snapshot-based backup Use cloud-native or CSI snapshot capabilities to create point-in-time snapshots of PVs.
Filesystem-level backup Use Restic or similar tools to back up PVC content at the filesystem level.
Each method has trade-offs — see below.
Database-native backup (preferred)
Hybrid Manager-managed Postgres clusters support:
- Scheduled backups to object storage (S3, GCS, Azure Blob)
- Point-in-time recovery where supported
- Consistent backups that avoid filesystem-level race conditions
Always enable and test database-native backups first. PVC backups should complement, not replace, these backups.
Volume snapshot-based backup
If using CSI snapshots:
- Verify that your StorageClass supports volume snapshots.
- Use Kubernetes VolumeSnapshot and VolumeSnapshotContent resources to manage snapshots.
- Coordinate snapshot timing to avoid capturing partial database writes.
Snapshot limitations:
- Not always supported on all platforms or storage backends.
- Not guaranteed to capture a crash-consistent Postgres state unless coordinated.
Use snapshots primarily for:
- Fast recovery within the same cluster
- Additional DR layer in conjunction with database-native backups
Filesystem-level backup (Restic)
For advanced use cases:
- Use Restic or similar tools to back up PVC content via file-level copy.
- Requires running a temporary Pod with PVC mounted read-only.
- Requires careful coordination to avoid capturing inconsistent state.
Filesystem-level backup can be useful for:
- Off-cluster archival
- Backup of other types of PVCs (non-Postgres)
- Air-gapped environments
Key considerations
When implementing any PVC backup:
- Validate backup consistency — perform test restores.
- Coordinate backup timing with database state.
- Monitor backup success and storage health.
- Validate retention policies and compliance requirements.
- Document restore procedures.
Summary checklist
- Enable and test database-native backups first.
- Validate CSI snapshot support and configuration.
- Implement volume snapshot backup where appropriate.
- Implement filesystem-level backup for additional DR or specific needs.
- Coordinate and test all backup methods.
- Document and monitor backup and restore procedures.
Related topics
Could this page be better? Report a problem or suggest an addition!