Is there an existing issue already for this bug?
I have read the troubleshooting guide
What happened?
Hi CNPG Team,
We are currently using CloudNativePG in our OpenShift environment with MinIO configured for physical backups (base backups + WAL archiving), and that part is working well for our disaster recovery strategy.
However, we now have a requirement to also implement logical backups (per-database dumps) for additional use cases such as:
Point-in-time logical restore of individual databases
Selective recovery (single database restore without full cluster recovery)
Safer application-level recovery testing in non-prod environments
Migration and refresh operations between environments
We have attempted to implement logical backups using pg_dump inside a Kubernetes Job and store the output on a PVC (and optionally MinIO), but we are encountering a few challenges:
Issues we are facing:
Permission issues when dumping certain sequences/tables for non-superuser roles
Lack of a native CNPG-supported logical backup workflow (compared to physical backups which are well integrated)
Challenges in standardizing restore workflows for multiple databases
Uncertainty around best practices for integrating logical backups with CNPG-managed clusters
What we are looking for:
We would appreciate guidance or best practices on:
Recommended approach for logical backups in CNPG-managed PostgreSQL clusters
Whether CNPG plans native support or tooling for logical backups (pg_dump orchestration, scheduling, restore helpers, etc.)
Proper RBAC/permissions setup for application users performing full logical dumps
Suggested patterns for storing logical backups (PVC vs object storage like MinIO/S3)
Best practice for restoring single databases without impacting the full cluster
We want to ensure we are aligning with CNPG best practices instead of building unsupported patterns.
Any guidance, examples, or roadmap direction would be highly appreciated.
Thank you in advance 🙏
Cluster resource
Relevant log output
Code of Conduct
Is there an existing issue already for this bug?
I have read the troubleshooting guide
What happened?
Hi CNPG Team,
We are currently using CloudNativePG in our OpenShift environment with MinIO configured for physical backups (base backups + WAL archiving), and that part is working well for our disaster recovery strategy.
However, we now have a requirement to also implement logical backups (per-database dumps) for additional use cases such as:
Point-in-time logical restore of individual databases
Selective recovery (single database restore without full cluster recovery)
Safer application-level recovery testing in non-prod environments
Migration and refresh operations between environments
We have attempted to implement logical backups using pg_dump inside a Kubernetes Job and store the output on a PVC (and optionally MinIO), but we are encountering a few challenges:
Issues we are facing:
Permission issues when dumping certain sequences/tables for non-superuser roles
Lack of a native CNPG-supported logical backup workflow (compared to physical backups which are well integrated)
Challenges in standardizing restore workflows for multiple databases
Uncertainty around best practices for integrating logical backups with CNPG-managed clusters
What we are looking for:
We would appreciate guidance or best practices on:
Recommended approach for logical backups in CNPG-managed PostgreSQL clusters
Whether CNPG plans native support or tooling for logical backups (pg_dump orchestration, scheduling, restore helpers, etc.)
Proper RBAC/permissions setup for application users performing full logical dumps
Suggested patterns for storing logical backups (PVC vs object storage like MinIO/S3)
Best practice for restoring single databases without impacting the full cluster
We want to ensure we are aligning with CNPG best practices instead of building unsupported patterns.
Any guidance, examples, or roadmap direction would be highly appreciated.
Thank you in advance 🙏
Cluster resource
Relevant log output
Code of Conduct