EnterpriseDB · github-actions · Jul 25, 2025
@@ -5,11 +5,8 @@ originalFilePath: 'src/architecture.md'
 
 
 
-!!! Hint
-    For a deeper understanding, we recommend reading our article on the CNCF
-    blog post titled ["Recommended Architectures for PostgreSQL in Kubernetes"](https://www.cncf.io/blog/2023/09/29/recommended-architectures-for-postgresql-in-kubernetes/),
-    which provides valuable insights into best practices and design
-    considerations for PostgreSQL deployments in Kubernetes.
+This section covers the main architectural aspects you need to consider
+when deploying PostgreSQL in Kubernetes.
 
 This documentation page provides an overview of the key architectural
 considerations for implementing a robust business continuity strategy when

@@ -5,42 +5,13 @@ originalFilePath: 'src/backup.md'
 
 
 
-!!! Info
-    This section covers **physical backups** in PostgreSQL.
-    While PostgreSQL also supports logical backups using the `pg_dump` utility,
-    these are **not suitable for business continuity** and are **not managed** by
-    EDB Postgres for Kubernetes. If you still wish to use `pg_dump`, refer to the
-    [*Troubleshooting / Emergency backup* section](troubleshooting.md#emergency-backup)
-    for guidance.
-
 !!! Important
-    Starting with version 1.26, native backup and recovery capabilities are
-    being **progressively phased out** of the core operator and moved to official
-    CNP-I plugins. This transition aligns with EDB Postgres for Kubernetes' shift towards a
-    **backup-agnostic architecture**, enabled by its extensible
-    interface—**CNP-I**—which standardizes the management of **WAL archiving**,
-    **physical base backups**, and corresponding **recovery processes**.
-
-EDB Postgres for Kubernetes currently supports **physical backups of PostgreSQL clusters** in
-two main ways:
-
--   **Via [CNPG-I](https://github.com/cloudnative-pg/cnpg-i/) plugins**: the
-    EDB Postgres for Kubernetes Community officially supports the [**Barman Cloud Plugin**](https://cloudnative-pg.io/plugin-barman-cloud/)
-    for integration with object storage services.
-
--   **Natively**, with support for:
-
-    -   [Object storage via Barman Cloud](backup_barmanobjectstore.md)
-        *(although deprecated from 1.26 in favor of the Barman Cloud Plugin)*
-    -   [Kubernetes Volume Snapshots](backup_volumesnapshot.md), if
-        supported by the underlying storage class
-
-Before selecting a backup strategy with EDB Postgres for Kubernetes, it's important to
-familiarize yourself with the foundational concepts covered in the ["Main Concepts"](#main-concepts)
-section. These include WAL archiving, hot and cold backups, performing backups
-from a standby, and more.
-
-## Main Concepts
+    With version 1.21, backup and recovery capabilities in EDB Postgres for Kubernetes
+    have sensibly changed due to the introduction of native support for
+    [Kubernetes Volume Snapshots](backup_volumesnapshot.md).
+    Up to that point, backup and recovery were available only for object
+    stores. Please carefully read this section and the [recovery](recovery.md)
+    one if you have been a user of EDB Postgres for Kubernetes 1.15 through 1.20.
 
 PostgreSQL natively provides first class backup and recovery capabilities based
 on file system level (physical) copy. These have been successfully used for

@@ -5,14 +5,6 @@ originalFilePath: 'src/appendixes/backup_barmanobjectstore.md'
 
 
 
-!!! Warning
-    As of EDB Postgres for Kubernetes 1.26, **native Barman Cloud support is deprecated** in
-    favor of the **Barman Cloud Plugin**. This page has been moved to the appendix
-    for reference purposes. While the native integration remains functional for
-    now, we strongly recommend beginning a gradual migration to the plugin-based
-    interface after appropriate testing.  For guidance, see
-    [Migrating from Built-in EDB Postgres for Kubernetes Backup](https://cloudnative-pg.io/plugin-barman-cloud/docs/migration/).
-
 EDB Postgres for Kubernetes natively supports **online/hot backup** of PostgreSQL
 clusters through continuous physical backup and WAL archiving on an object
 store. This means that the database is always up (no downtime required)

@@ -5,4 +5,12 @@ originalFilePath: 'src/backup_recovery.md'
 
 
 
-[Backup](backup.md) and [recovery](recovery.md) are in two separate sections.
+Until EDB Postgres for Kubernetes 1.20, this page used to contain both the backup and
+recovery phases of a PostgreSQL cluster. The reason was that EDB Postgres for Kubernetes
+supported only backup and recovery object stores.
+
+Version 1.21 introduces support for the Kubernetes `VolumeSnapshot` API,
+providing more possibilities for the end user.
+
+As a result, [backup](backup.md) and [recovery](recovery.md) are now in two
+separate sections.
@@ -5,10 +5,12 @@ originalFilePath: 'src/appendixes/backup_volumesnapshot.md'
 
 
 
-!!! Important
-    Please refer to the official Kubernetes documentation for a list of all
-    the supported [Container Storage Interface (CSI) drivers](https://kubernetes-csi.github.io/docs/drivers.html)
-    that provide snapshotting capabilities.
+!!! Warning
+    As noted in the [backup document](backup.md), a cold snapshot explicitly
+    set to target the primary will result in the primary being fenced for
+    the duration of the backup, rendering the cluster read-only during that
+    For safety, in a cluster already containing fenced instances, a cold
+    snapshot is rejected.
 
 EDB Postgres for Kubernetes is one of the first known cases of database operators that
 directly leverages the Kubernetes native Volume Snapshot API for both

@@ -35,7 +35,7 @@ For more detailed information about this feature, please refer to the
     EDB Postgres for Kubernetes requires both the `postgres` user and database to
     always exist. Using the local Unix Domain Socket, it needs to connect
     as the `postgres` user to the `postgres` database via `peer` authentication in
-    order to perform administrative tasks on the cluster.
+    order to perform administrative tasks on the cluster.  
     **DO NOT DELETE** the `postgres` user or the `postgres` database!!!
 
 !!! Info
@@ -63,6 +63,9 @@ specification. EDB Postgres for Kubernetes currently supports the following boot
     [`pg_basebackup` subsection](#bootstrap-from-a-live-cluster-pg_basebackup)
     carefully.
 
+Only one bootstrap method can be specified in the manifest.
+Attempting to define multiple bootstrap methods will result in validation errors.
+
 In contrast to the `initdb` method, both `recovery` and `pg_basebackup`
 create a new cluster based on another one (either offline or online) and can be
 used to spin up replica clusters. They both rely on the definition of external
@@ -500,7 +503,23 @@ or a standby PostgreSQL server. It’s crucial to thoroughly review the
 requirements section below, as the pros and cons of PostgreSQL physical
 replication fully apply.
 
-The primary use cases for this method include:
+-   Reporting and business intelligence clusters that need to be regenerated
+    periodically (daily, weekly)
+-   Test databases containing live data that require periodic regeneration
+    (daily, weekly, monthly) and anonymization
+-   Rapid spin-up of a standalone replica cluster
+-   Physical migrations of EDB Postgres for Kubernetes clusters to different namespaces or
+    Kubernetes clusters
+
+!!! Important
+    Avoid using this method, based on physical replication, to migrate an
+    existing PostgreSQL cluster outside of Kubernetes into EDB Postgres for Kubernetes, unless you
+    are completely certain that all [requirements](#requirements) are met and
+    the operation has been
+    thoroughly tested. The EDB Postgres for Kubernetes community does not endorse this approach
+    for such use cases, and recommends using logical import instead. It is
+    exceedingly rare that all requirements for physical replication are met in a
+    way that seamlessly works with EDB Postgres for Kubernetes.
 
 -   Reporting and business intelligence clusters that need to be regenerated
     periodically (daily, weekly)