Repository: cloudnative-pg/cloudnative-pg
Pull request #7581: docs: restructure backup and recovery section for CNPG-I plugins
Author: login: gbartolini
Labels: name: documentation :book:
description: Improvements or additions to documentation
name: ok to merge :ok_hand:
description: This PR can be merged
name: do not backport
description: This PR must not be backported - it will be in the next minor release
name: size:XXL
description: This PR changes 1000+ lines, ignoring generated files.
name: lgtm
description: This PR has been approved by a maintainer
Created: 2025-05-19T05:53:39Z | Merged: 2025-05-21T17:49:19Z

With the introduction of the CNPG-I interface and official support for the Barman Cloud Plugin, the backup and recovery documentation has been reorganised to reflect the new plugin-based architecture.

This is the first step toward a more modular and extensible approach. Further work is planned outside the core CloudNativePG repository, including maintaining an inventory of available plugins and migrating volume snapshot support into a dedicated plugin.

Closes #6876 

Linked issue #6876: [Feature]: Support Barman Cloud as a plugin
### Is there an existing issue already for this feature request/idea?

- [x] I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.

### What problem is this feature going to solve? Why should it be added?

Since day one, **Barman Cloud** has been the primary backup solution for CloudNativePG. As its creators, this was a natural initial choice. However, over the years, we have recognised the need for **CloudNativePG to evolve into a Postgres backup/recovery-agnostic framework**, providing a **generic interface** that allows alternative backup solutions to emerge and thrive. This vision led to the development of **CNPG-I**.

Note: **Volume Snapshots**, as standard Kubernetes resources, will be natively supported - although we cannot exclude a transition to a plugin.

### Describe the solution you'd like

Starting with **CloudNativePG 1.26**, we plan to **deprecate native support for Barman Cloud** and transition it into a plugin over the course of two minor releases (1.28). 

To ensure a **smooth migration**, we will:

- Provide clear **documentation** on how to transition from native Barman Cloud to the Barman Cloud Plugin.
- Ensure a **transparent and well-documented migration path** for users.

### Describe alternatives you've considered

N/A

### Additional context

N/A

### Backport?

No

### Are you willing to actively contribute to this feature?

Yes

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct
Linked issue comments: user: login: dosubot[bot]
created_at: 2025-05-21T16:00:54Z
body: Hi, @gbartolini. I'm [Dosu](https://dosu.dev), and I'm helping the cloudnative-pg team manage their backlog. I'm marking this issue as stale.

**Issue Summary:**
- Proposal to convert Barman Cloud into a plugin for CloudNativePG.
- Targeted transition from version 1.26 to 1.28.
- Aimed at enhancing flexibility for Postgres backup and recovery.
- Plans for detailed documentation to assist users in migration.
- No activity or comments have been made on the issue yet.

**Next Steps:**
- Please confirm if this issue is still relevant to the latest version of the cloudnative-pg repository by commenting on the issue.
- If no updates are provided, the issue will be automatically closed in 7 days.

Thank you for your understanding and contribution!
author_association: NONE
user: login: vishaltanawade
created_at: 2025-06-17T07:22:09Z
body: Hi @gbartolini , @mnencia ,
I am using CNPG 1.26.0 . So when I use Barman Cloud I got  below warning: 
Warning: Native support for Barman Cloud backups and recovery is deprecated and will be completely removed in CloudNativePG 1.28.0. Found usage in: spec.backup.barmanObjectStore. Please migrate existing clusters to the new Barman Cloud Plugin to ensure a smooth transition.

so **Barman cloud plugin** is supported or not in version 1.26.0.
If not then in which version it will be supported.
Thanks and Regards,
vishal.tanawade@emerson.com
author_association: NONE

Diff:
diff --git a/.wordlist-en-custom.txt b/.wordlist-en-custom.txt
index bccda465d9..cc086513df 100644
--- a/.wordlist-en-custom.txt
+++ b/.wordlist-en-custom.txt
@@ -507,6 +507,7 @@ Uncomment
 Unrealizable
 UpdateStrategy
 VLDB
+VLDBs
 VM
 VMs
 VOLNAME
diff --git a/docs/mkdocs.yml b/docs/mkdocs.yml
index 5cf758e60d..fe3de716f7 100644
--- a/docs/mkdocs.yml
+++ b/docs/mkdocs.yml
@@ -14,6 +14,7 @@ markdown_extensions:
   - def_list
   - attr_list
   - footnotes
+  - pymdownx.caret
 
 nav:
   - index.md
@@ -34,9 +35,7 @@ nav:
   - replication.md
   - logical_replication.md
   - backup.md
-  - backup_barmanobjectstore.md
   - wal_archiving.md
-  - backup_volumesnapshot.md
   - recovery.md
   - service_management.md
   - postgresql_conf.md
@@ -77,4 +76,6 @@ nav:
   - CNCF Projects Integrations:
     - cncf-projects/external-secrets.md
   - Appendixes:
+    - appendixes/backup_volumesnapshot.md
+    - appendixes/backup_barmanobjectstore.md
     - appendixes/object_stores.md
diff --git a/docs/src/backup_barmanobjectstore.md b/docs/src/appendixes/backup_barmanobjectstore.md
similarity index 57%
rename from docs/src/backup_barmanobjectstore.md
rename to docs/src/appendixes/backup_barmanobjectstore.md
index 8c062f64bf..8573315567 100644
--- a/docs/src/backup_barmanobjectstore.md
+++ b/docs/src/appendixes/backup_barmanobjectstore.md
@@ -1,11 +1,14 @@
-# Backup on object stores
+# Appendix B - Backup on object stores
+
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 
 !!! Warning
-    With the deprecation of native Barman Cloud support in CloudNativePG in
-    favor of the Barman Cloud Plugin, this page—and the backup and recovery
-    documentation—may undergo changes before the official release of version
-    1.26.0.
+    As of CloudNativePG 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 CloudNativePG Backup](https://cloudnative-pg.io/plugin-barman-cloud/docs/migration/).
 
 CloudNativePG natively supports **online/hot backup** of PostgreSQL
 clusters through continuous physical backup and WAL archiving on an object
@@ -34,23 +37,90 @@ as it is composed of a community PostgreSQL image and the latest
 
 A backup is performed from a primary or a designated primary instance in a
 `Cluster` (please refer to
-[replica clusters](replica_cluster.md)
+[replica clusters](../replica_cluster.md)
 for more information about designated primary instances), or alternatively
-on a [standby](backup.md#backup-from-a-standby).
+on a [standby](../backup.md#backup-from-a-standby).
 
 ## Common object stores
 
 If you are looking for a specific object store such as
-[AWS S3](appendixes/object_stores.md#aws-s3),
-[Microsoft Azure Blob Storage](appendixes/object_stores.md#azure-blob-storage),
-[Google Cloud Storage](appendixes/object_stores.md#google-cloud-storage), or
-[MinIO Gateway](appendixes/object_stores.md#minio-gateway), or a compatible
-provider, please refer to [Appendix A - Common object stores](appendixes/object_stores.md).
+[AWS S3](object_stores.md#aws-s3),
+[Microsoft Azure Blob Storage](object_stores.md#azure-blob-storage),
+[Google Cloud Storage](object_stores.md#google-cloud-storage), or a compatible
+provider, please refer to [Appendix C - Common object stores for backups](object_stores.md).
 
-## Retention policies
+## WAL archiving
+
+WAL archiving is the process that feeds a [WAL archive](../backup.md#wal-archive)
+in CloudNativePG.
+
+The WAL archive is defined in the `.spec.backup.barmanObjectStore` stanza of
+a `Cluster` resource.
+
+!!! Info
+    Please refer to [`BarmanObjectStoreConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration)
+    in the barman-cloud API for a full list of options.
+
+If required, you can choose to compress WAL files as soon as they
+are uploaded and/or encrypt them:
+
+```yaml
+apiVersion: postgresql.cnpg.io/v1
+kind: Cluster
+[...]
+spec:
+  backup:
+    barmanObjectStore:
+      [...]
+      wal:
+        compression: gzip
+        encryption: AES256
+```
+
+You can configure the encryption directly in your bucket, and the operator
+will use it unless you override it in the cluster configuration.
+
+PostgreSQL implements a sequential archiving scheme, where the
+`archive_command` will be executed sequentially for every WAL
+segment to be archived.
 
 !!! Important
-    Retention policies are not currently available on volume snapshots.
+    By default, CloudNativePG sets `archive_timeout` to `5min`, ensuring
+    that WAL files, even in case of low workloads, are closed and archived
+    at least every 5 minutes, providing a deterministic time-based value for
+    your Recovery Point Objective ([RPO](../before_you_start.md#rpo)). Even though you change the value
+    of the [`archive_timeout` setting in the PostgreSQL configuration](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-ARCHIVE-TIMEOUT),
+    our experience suggests that the default value set by the operator is
+    suitable for most use cases.
+
+When the bandwidth between the PostgreSQL instance and the object
+store allows archiving more than one WAL file in parallel, you
+can use the parallel WAL archiving feature of the instance manager
+like in the following example:
+
+```yaml
+apiVersion: postgresql.cnpg.io/v1
+kind: Cluster
+[...]
+spec:
+  backup:
+    barmanObjectStore:
+      [...]
+      wal:
+        compression: gzip
+        maxParallel: 8
+        encryption: AES256
+```
+
+In the previous example, the instance manager optimizes the WAL
+archiving process by archiving in parallel at most eight ready
+WALs, including the one requested by PostgreSQL.
+
+When PostgreSQL will request the archiving of a WAL that has
+already been archived by the instance manager as an optimization,
+that archival request will be just dismissed with a positive status.
+
+## Retention policies
 
 CloudNativePG can manage the automated deletion of backup files from
 the backup object store, using **retention policies** based on the recovery
@@ -163,7 +233,7 @@ spec:
 You can append additional options to the `barman-cloud-backup` and `barman-cloud-wal-archive` commands by using
 the `additionalCommandArgs` property in the
 `.spec.backup.barmanObjectStore.data` and `.spec.backup.barmanObjectStore.wal` sections respectively.
-This properties are lists of strings that will be appended to the
+These properties are lists of strings that will be appended to the
 `barman-cloud-backup` and `barman-cloud-wal-archive` commands.
 
 For example, you can use the `--read-timeout=60` to customize the connection
@@ -209,3 +279,61 @@ spec:
         - "--max-concurrency=1"
         - "--read-timeout=60"
 ```
+
+## Recovery from an object store
+
+You can recover from a backup created by Barman Cloud and stored on a supported
+object store. After you define the external cluster, including all the required
+configuration in the `barmanObjectStore` section, you need to reference it in
+the `.spec.recovery.source` option.
+
+This example defines a recovery object store in a blob container in Azure:
+
+```yaml
+apiVersion: postgresql.cnpg.io/v1
+kind: Cluster
+metadata:
+  name: cluster-restore
+spec:
+  [...]
+
+  superuserSecret:
+    name: superuser-secret
+
+  bootstrap:
+    recovery:
+      source: clusterBackup
+
+  externalClusters:
+    - name: clusterBackup
+      barmanObjectStore:
+        destinationPath: https://STORAGEACCOUNTNAME.blob.core.windows.net/CONTAINERNAME/
+        azureCredentials:
+          storageAccount:
+            name: recovery-object-store-secret
+            key: storage_account_name
+          storageKey:
+            name: recovery-object-store-secret
+            key: storage_account_key
+        wal:
+          maxParallel: 8
+```
+
+The previous example assumes that the application database and its owning user
+are named `app` by default. If the PostgreSQL cluster being restored uses
+different names, you must specify these names before exiting the recovery phase,
+as documented in ["Configure the application database"](../recovery.md#configure-the-application-database).
+
+!!! Important
+    By default, the `recovery` method strictly uses the `name` of the
+    cluster in the `externalClusters` section as the name of the main folder
+    of the backup data within the object store. This name is normally reserved
+    for the name of the server. You can specify a different folder name
+    using the `barmanObjectStore.serverName` property.
+
+!!! Note
+    This example takes advantage of the parallel WAL restore feature,
+    dedicating up to 8 jobs to concurrently fetch the required WAL files from the
+    archive. This feature can appreciably reduce the recovery time. Make sure that
+    you plan ahead for this scenario and correctly tune the value of this parameter
+    for your environment. It will make a difference when you need it, and you will.
diff --git a/docs/src/backup_volumesnapshot.md b/docs/src/appendixes/backup_volumesnapshot.md
similarity index 91%
rename from docs/src/backup_volumesnapshot.md
rename to docs/src/appendixes/backup_volumesnapshot.md
index 814867cd40..6bf555f49b 100644
--- a/docs/src/backup_volumesnapshot.md
+++ b/docs/src/appendixes/backup_volumesnapshot.md
@@ -1,12 +1,10 @@
-# Backup on volume snapshots
+# Appendix A - Backup on volume snapshots
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 
-!!! 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.
+!!! 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.
 
 CloudNativePG is one of the first known cases of database operators that
 directly leverages the Kubernetes native Volume Snapshot API for both
@@ -53,18 +51,16 @@ volumes of a given storage class, and managed as `VolumeSnapshot` and
 !!! Important
     It is your responsibility to verify with the third party vendor
     that volume snapshots are supported. CloudNativePG only interacts
-    with the Kubernetes API on this matter and we cannot support issues
+    with the Kubernetes API on this matter, and we cannot support issues
     at the storage level for each specific CSI driver.
 
 ## How to configure Volume Snapshot backups
 
-<!-- TODO: Change before 1.26.0 -->
-
 CloudNativePG allows you to configure a given Postgres cluster for Volume
 Snapshot backups through the `backup.volumeSnapshot` stanza.
 
 !!! Info
-    Please refer to [`VolumeSnapshotConfiguration`](cloudnative-pg.v1.md#postgresql-cnpg-io-v1-VolumeSnapshotConfiguration)
+    Please refer to [`VolumeSnapshotConfiguration`](../cloudnative-pg.v1.md#postgresql-cnpg-io-v1-VolumeSnapshotConfiguration)
     in the API reference for a full list of options.
 
 A generic example with volume snapshots (assuming that PGDATA and WALs share
@@ -89,18 +85,21 @@ spec:
     # Volume snapshot backups
     volumeSnapshot:
        className: @VOLUME_SNAPSHOT_CLASS_NAME@
-    # WAL archive
-    barmanObjectStore:
-       # ...
+       
+  plugins:
+  - name: barman-cloud.cloudnative-pg.io
+    isWALArchiver: true
+    parameters:
+      barmanObjectName: @OBJECTSTORE_NAME@
 ```
 
 As you can see, the `backup` section contains both the `volumeSnapshot` stanza
 (controlling physical base backups on volume snapshots) and the
-`barmanObjectStore` one (controlling the [WAL archive](wal_archiving.md)).
+`plugins` one (controlling the [WAL archive](../wal_archiving.md)).
 
 !!! Info
-    Once you have defined the `barmanObjectStore`, you can decide to use
-    both volume snapshot and object store backup strategies simultaneously
+    Once you have defined the `plugin`, you can decide to use
+    both volume snapshot and plugin backup strategies simultaneously
     to take physical backups.
 
 The `volumeSnapshot.className` option allows you to reference the default
@@ -118,6 +117,13 @@ a `ScheduledBackup` resource that requests such backups on a periodic basis.
 
 ## Hot and cold backups
 
+!!! 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, making the cluster read-only during this
+    period. For safety, in a cluster already containing fenced instances, a cold
+    snapshot is rejected.
+
 By default, CloudNativePG requests an online/hot backup on volume snapshots, using the
 [PostgreSQL defaults of the low-level API for base backups](https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP):
 
@@ -335,8 +341,6 @@ spec:
 
 ## Example of Volume Snapshot Backup
 
-<!-- TODO: Change before 1.26.0 -->
-
 The following example shows how to configure volume snapshot base backups on an
 EKS cluster on AWS using the `ebs-sc` storage class and the `csi-aws-vsc`
 volume snapshot class.
@@ -349,7 +353,7 @@ volume snapshot class.
 
 The following manifest creates a `Cluster` that is ready to be used for volume
 snapshots and that stores the WAL archive in a S3 bucket via IAM role for the
-Service Account (IRSA, see [AWS S3](appendixes/object_stores.md#aws-s3)):
+Service Account (IRSA, see [AWS S3](object_stores.md#aws-s3)):
 
 ``` yaml
 apiVersion: postgresql.cnpg.io/v1
@@ -369,13 +373,12 @@ spec:
   backup:
     volumeSnapshot:
        className: csi-aws-vsc
-    barmanObjectStore:
-      destinationPath: s3://@BUCKET_NAME@/
-      s3Credentials:
-        inheritFromIAMRole: true
-      wal:
-        compression: gzip
-        maxParallel: 2
+
+  plugins:
+  - name: barman-cloud.cloudnative-pg.io
+    isWALArchiver: true
+    parameters:
+      barmanObjectName: @OBJECTSTORE_NAME@
 
   serviceAccountTemplate:
     metadata:
diff --git a/docs/src/appendixes/object_stores.md b/docs/src/appendixes/object_stores.md
index 5975e7ddd7..73e424abb9 100644
--- a/docs/src/appendixes/object_stores.md
+++ b/docs/src/appendixes/object_stores.md
@@ -1,11 +1,13 @@
-# Appendix A - Common object stores for backups
+# Appendix C - Common object stores for backups
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 
 !!! Warning
-    With the deprecation of native Barman Cloud support in CloudNativePG in
-    favor of the Barman Cloud Plugin, this page—and the backup and recovery
-    documentation—may undergo changes before the official release of version
-    1.26.0.
+    As of CloudNativePG 1.26, **native Barman Cloud support is deprecated** in
+    favor of the **Barman Cloud Plugin**. While the native integration remains
+    functional for now, we strongly recommend beginning a gradual migration to
+    the plugin-based interface after appropriate testing. The Barman Cloud
+    Plugin documentation describes
+    [how to use common object stores](https://cloudnative-pg.io/plugin-barman-cloud/docs/object_stores/).
 
 You can store the [backup](../backup.md) files in any service that is supported
 by the Barman Cloud infrastructure. That is:
@@ -348,125 +350,3 @@ Now the operator will use the credentials to authenticate against Google Cloud S
     This way of authentication will create a JSON file inside the container with all the needed
     information to access your Google Cloud Storage bucket, meaning that if someone gets access to the pod
     will also have write permissions to the bucket.
-
-## MinIO Gateway
-
-Optionally, you can use MinIO Gateway as a common interface which
-relays backup objects to other cloud storage solutions, like S3 or GCS.
-For more information, please refer to [MinIO official documentation](https://docs.min.io/).
-
-Specifically, the CloudNativePG cluster can directly point to a local
-MinIO Gateway as an endpoint, using previously created credentials and service.
-
-MinIO secrets will be used by both the PostgreSQL cluster and the MinIO instance.
-Therefore, you must create them in the same namespace:
-
-```sh
-kubectl create secret generic minio-creds \
-  --from-literal=MINIO_ACCESS_KEY=<minio access key here> \
-  --from-literal=MINIO_SECRET_KEY=<minio secret key here>
-```
-
-!!! Note
-    Cloud Object Storage credentials will be used only by MinIO Gateway in this case.
-
-!!! Important
-    In order to allow PostgreSQL to reach MinIO Gateway, it is necessary to create a
-    `ClusterIP` service on port `9000` bound to the MinIO Gateway instance.
-
-For example:
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: minio-gateway-service
-spec:
-  type: ClusterIP
-  ports:
-    - port: 9000
-      targetPort: 9000
-      protocol: TCP
-  selector:
-    app: minio
-```
-
-!!! Warning
-    At the time of writing this documentation, the official
-    [MinIO Operator](https://github.com/minio/minio-operator/issues/71)
-    for Kubernetes does not support the gateway feature. As such, we will use a
-    `deployment` instead.
-
-The MinIO deployment will use cloud storage credentials to upload objects to the
-remote bucket and relay backup files to different locations.
-
-Here is an example using AWS S3 as Cloud Object Storage:
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-[...]
-spec:
-  containers:
-  - name: minio
-    image: minio/minio:RELEASE.2020-06-03T22-13-49Z
-    args:
-    - gateway
-    - s3
-    env:
-    # MinIO access key and secret key
-    - name: MINIO_ACCESS_KEY
-      valueFrom:
-        secretKeyRef:
-          name: minio-creds
-          key: MINIO_ACCESS_KEY
-    - name: MINIO_SECRET_KEY
-      valueFrom:
-        secretKeyRef:
-          name: minio-creds
-          key: MINIO_SECRET_KEY
-    # AWS credentials
-    - name: AWS_ACCESS_KEY_ID
-      valueFrom:
-        secretKeyRef:
-          name: aws-creds
-          key: ACCESS_KEY_ID
-    - name: AWS_SECRET_ACCESS_KEY
-      valueFrom:
-        secretKeyRef:
-          name: aws-creds
-          key: ACCESS_SECRET_KEY
-# Uncomment the below section if session token is required
-#   - name: AWS_SESSION_TOKEN
-#     valueFrom:
-#       secretKeyRef:
-#         name: aws-creds
-#         key: ACCESS_SESSION_TOKEN
-        ports:
-        - containerPort: 9000
-```
-
-Proceed by configuring MinIO Gateway service as the `endpointURL` in the `Cluster`
-definition, then choose a bucket name to replace `BUCKET_NAME`:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-[...]
-spec:
-  backup:
-    barmanObjectStore:
-      destinationPath: s3://BUCKET_NAME/
-      endpointURL: http://minio-gateway-service:9000
-      s3Credentials:
-        accessKeyId:
-          name: minio-creds
-          key: MINIO_ACCESS_KEY
-        secretAccessKey:
-          name: minio-creds
-          key: MINIO_SECRET_KEY
-    [...]
-```
-
-Verify on `s3://BUCKET_NAME/` the presence of archived WAL files before
-proceeding with a backup.
diff --git a/docs/src/backup.md b/docs/src/backup.md
index 7a1196c7e9..99ee3f5e08 100644
--- a/docs/src/backup.md
+++ b/docs/src/backup.md
@@ -1,11 +1,42 @@
 # Backup
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 
-!!! Warning
-    With the deprecation of native Barman Cloud support in CloudNativePG in
-    favor of the Barman Cloud Plugin, this page—and the backup and recovery
-    documentation—may undergo changes before the official release of version
-    1.26.0.
+!!! 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
+    CloudNativePG. 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
+    CNPG-I plugins. This transition aligns with CloudNativePG's shift towards a
+    **backup-agnostic architecture**, enabled by its extensible
+    interface—**CNPG-I**—which standardizes the management of **WAL archiving**,
+    **physical base backups**, and corresponding **recovery processes**.
+
+CloudNativePG currently supports **physical backups of PostgreSQL clusters** in
+two main ways:
+
+- **Via [CNPG-I](https://github.com/cloudnative-pg/cnpg-i/) plugins**: the
+  CloudNativePG 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](appendixes/backup_barmanobjectstore.md)
+      *(although deprecated from 1.26 in favor of the Barman Cloud Plugin)*
+    - [Kubernetes Volume Snapshots](appendixes/backup_volumesnapshot.md), if
+      supported by the underlying storage class
+
+Before selecting a backup strategy with CloudNativePG, 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
 
 PostgreSQL natively provides first class backup and recovery capabilities based
 on file system level (physical) copy. These have been successfully used for
@@ -13,14 +44,6 @@ more than 15 years in mission critical production databases, helping
 organizations all over the world achieve their disaster recovery goals with
 Postgres.
 
-!!! Note
-    There's another way to backup databases in PostgreSQL, through the
-    `pg_dump` utility - which relies on logical backups instead of physical ones.
-    However, logical backups are not suitable for business continuity use cases
-    and as such are not covered by CloudNativePG (yet, at least).
-    If you want to use the `pg_dump` utility, let yourself be inspired by the
-    ["Troubleshooting / Emergency backup" section](troubleshooting.md#emergency-backup).
-
 In CloudNativePG, the backup infrastructure for each PostgreSQL cluster is made
 up of the following resources:
 
@@ -29,28 +52,11 @@ up of the following resources:
 - **Physical base backups**: a copy of all the files that PostgreSQL uses to
   store the data in the database (primarily the `PGDATA` and any tablespace)
 
-The WAL archive can only be stored on object stores at the moment.
-
-On the other hand, CloudNativePG supports two ways to store physical base backups:
-
-- on [object stores](backup_barmanobjectstore.md), as tarballs - optionally
-  compressed:
-    - Using the Barman Cloud plugin
-    - Natively via `.spec.backup.barmanObjectStore` (*deprecated, to be removed in CloudNativePG 1.28*)
-- on [Kubernetes Volume Snapshots](backup_volumesnapshot.md), if supported by
-  the underlying storage class
-
-!!! Important
-    Before choosing your backup strategy with CloudNativePG, it is important that
-    you take some time to familiarize with some basic concepts, like WAL archive,
-    hot and cold backups.
-
-!!! 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.
+CNPG-I provides a generic and extensible interface for managing WAL archiving
+(both archive and restore operations), as well as the base backup and
+corresponding restore processes.
 
-## WAL archive
+### WAL archive
 
 The WAL archive in PostgreSQL is at the heart of **continuous backup**, and it
 is fundamental for the following reasons:
@@ -58,7 +64,7 @@ is fundamental for the following reasons:
 - **Hot backups**: the possibility to take physical base backups from any
   instance in the Postgres cluster (either primary or standby) without shutting
   down the server; they are also known as online backups
-- **Point in Time recovery** (PITR): to possibility to recover at any point in
+- **Point in Time recovery** (PITR): the possibility to recover at any point in
   time from the first available base backup in your system
 
 !!! Warning
@@ -80,20 +86,20 @@ recovery, even across regions.
 
 !!! Important
     Our recommendation is to always setup the WAL archive in production.
-    There are known use cases - normally involving staging and development
-    environments - where none of the above benefits are needed and the WAL
+    There are known use cases — normally involving staging and development
+    environments — where none of the above benefits are needed and the WAL
     archive is not necessary. RPO in this case can be any value, such as
     24 hours (daily backups) or infinite (no backup at all).
 
-## Cold and Hot backups
+### Cold and Hot backups
 
 Hot backups have already been defined in the previous section. They require the
-presence of a WAL archive and they are the norm in any modern database management
-system.
+presence of a WAL archive, and they are the norm in any modern database
+management system.
 
 **Cold backups**, also known as offline backups, are instead physical base backups
 taken when the PostgreSQL instance (standby or primary) is shut down. They are
-consistent per definition and they represent a snapshot of the database at the
+consistent per definition, and they represent a snapshot of the database at the
 time it was shut down.
 
 As a result, PostgreSQL instances can be restarted from a cold backup without
@@ -105,78 +111,107 @@ In those situations with a higher RPO (for example, 1 hour or 24 hours), and
 shorter retention periods, cold backups represent a viable option to be considered
 for your disaster recovery plans.
 
-## Object stores or volume snapshots: which one to use?
+## Comparing Available Backup Options: Object Stores vs Volume Snapshots
+
+CloudNativePG currently supports two main approaches for physical backups:
+
+- **Object store–based backups**, via the [**Barman Cloud
+  Plugin**](https://cloudnative-pg.io/plugin-barman-cloud/) or the
+  [**deprecated native integration**](appendixes/backup_barmanobjectstore.md)
+- [**Volume Snapshots**](appendixes/backup_volumesnapshot.md), using the
+  Kubernetes CSI interface and supported storage classes
+
+!!! Important
+    CNPG-I is designed to enable third parties to build and integrate their own
+    backup plugins. Over time, we expect the ecosystem of supported backup
+    solutions to grow.
+
+### Object Store–Based Backups
+
+Backups to an object store (e.g. AWS S3, Azure Blob, GCS):
 
-In CloudNativePG, object store based backups:
+- Always require WAL archiving
+- Support hot backups only
+- Do not support incremental or differential copies
+- Support retention policies
 
-- always require the WAL archive
-- support hot backup only
-- don't support incremental copy
-- don't support differential copy
+### Volume Snapshots
 
-VolumeSnapshots instead:
+Native volume snapshots:
 
-- don't require the WAL archive, although in production it is always recommended
-- support incremental copy, depending on the underlying storage classes
-- support differential copy, depending on the underlying storage classes
-- also support cold backup
+- Do not require WAL archiving, though its use is still strongly
+  recommended in production
+- Support incremental and differential copies, depending on the
+  capabilities of the underlying storage class
+- Support both hot and cold backups
+- Do not support retention policies
 
-Which one to use depends on your specific requirements and environment,
-including:
+### Choosing Between the Two
 
-- availability of a viable object store solution in your Kubernetes cluster
-- availability of a trusted storage class that supports volume snapshots
-- size of the database: with object stores, the larger your database, the
-  longer backup and, most importantly, recovery procedures take (the latter
-  impacts [RTO](before_you_start.md#rto)); in presence of Very Large Databases
-  (VLDB), the general advice is to rely on Volume Snapshots as, thanks to
-  copy-on-write, they provide faster recovery
-- data mobility and possibility to store or relay backup files on a
-  secondary location in a different region, or any subsequent one
-- other factors, mostly based on the confidence and familiarity with the
-  underlying storage solutions
+The best approach depends on your environment and operational requirements.
+Consider the following factors:
 
-The summary table below highlights some of the main differences between the two
-available methods for storing physical base backups.
+- **Object store availability**: Ensure your Kubernetes cluster can access a
+  reliable object storage solution, including a stable networking layer.
+- **Storage class capabilities**: Confirm that your storage class supports CSI
+  volume snapshots with incremental/differential features.
+- **Database size**: For very large databases (VLDBs), **volume snapshots are
+  generally preferred** as they enable faster recovery due to copy-on-write
+  technology—this significantly improves your
+  [Recovery Time Objective (RTO)](before_you_start.md#rto).
+- **Data mobility**: Object store–based backups may offer greater flexibility
+  for replicating or storing backups across regions or environments.
+- **Operational familiarity**: Choose the method that aligns best with your
+  team's experience and confidence in managing storage.
 
-|                                   | Object store |   Volume Snapshots   |
+### Comparison Summary
+
+| Feature                           | Object Store |   Volume Snapshots   |
 |-----------------------------------|:------------:|:--------------------:|
-| **WAL archiving**                 |   Required   |    Recommended (1)   |
-| **Cold backup**                   |      ✗       |           ✓          |
-| **Hot backup**                    |      ✓       |           ✓          |
-| **Incremental copy**              |      ✗       |         ✓  (2)       |
-| **Differential copy**             |      ✗       |         ✓  (2)       |
-| **Backup from a standby**         |      ✓       |           ✓          |
-| **Snapshot recovery**             |    ✗ (3)     |           ✓          |
-| **Point In Time Recovery (PITR)** |      ✓       | Requires WAL archive |
-| **Underlying technology**         | Barman Cloud |   Kubernetes API     |
-
-
-> See the explanation below for the notes in the above table:
+| **WAL archiving**                 |   Required   |    Recommended^1^    |
+| **Cold backup**                   |      ❌       |          ✅           |
+| **Hot backup**                    |      ✅       |          ✅           |
+| **Incremental copy**              |      ❌       |         ✅^2^         |
+| **Differential copy**             |      ❌       |         ✅^2^         |
+| **Backup from a standby**         |      ✅       |          ✅           |
+| **Snapshot recovery**             |     ❌^3^     |          ✅           |
+| **Retention policies**            |      ✅       |          ❌           |
+| **Point-in-Time Recovery (PITR)** |      ✅       | Requires WAL archive |
+| **Underlying technology**         | Barman Cloud |    Kubernetes API    |
+
+---
+
+> **Notes:**
 >
-> 1. WAL archive must be on an object store at the moment
-> 2. If supported by the underlying storage classes of the PostgreSQL volumes
-> 3. Snapshot recovery can be emulated using the
->    `bootstrap.recovery.recoveryTarget.targetImmediate` option
+> 1. WAL archiving must currently use an object store through a plugin (or the
+>    deprecated native one).
+> 2. Availability of incremental and differential copies depends on the
+>    capabilities of the storage class used for PostgreSQL volumes.
+> 3. Snapshot recovery can be emulated by using the
+>    `bootstrap.recovery.recoveryTarget.targetImmediate` option.
 
-## Scheduled backups
+## Scheduled Backups
 
-Scheduled backups are the recommended way to configure your backup strategy in
-CloudNativePG. They are managed by the `ScheduledBackup` resource.
+Scheduled backups are the recommended way to implement a reliable backup
+strategy in CloudNativePG. They are defined using the `ScheduledBackup` custom
+resource.
 
 !!! Info
-    Please refer to [`ScheduledBackupSpec`](cloudnative-pg.v1.md#postgresql-cnpg-io-v1-ScheduledBackupSpec)
-    in the API reference for a full list of options.
+    For a complete list of configuration options, refer to the
+    [`ScheduledBackupSpec`](cloudnative-pg.v1.md#postgresql-cnpg-io-v1-ScheduledBackupSpec)
+    in the API reference.
+
+### Cron Schedule
 
-The `schedule` field allows you to define a *six-term cron schedule* specification,
-which includes seconds, as expressed in
-the [Go `cron` package format](https://pkg.go.dev/github.com/robfig/cron#hdr-CRON_Expression_Format).
+The `schedule` field defines **when** the backup should occur, using a
+*six-field cron expression* that includes seconds. This format follows the
+[Go `cron` package specification](https://pkg.go.dev/github.com/robfig/cron#hdr-CRON_Expression_Format).
 
 !!! Warning
-    Beware that this format accepts also the `seconds` field, and it is
-    different from the `crontab` format in Unix/Linux systems.
+    This format differs from the traditional Unix/Linux `crontab`—it includes a
+    **seconds** field as the first entry.
 
-This is an example of a scheduled backup:
+Example of a daily scheduled backup:
 
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
@@ -184,62 +219,73 @@ kind: ScheduledBackup
 metadata:
   name: backup-example
 spec:
-  schedule: "0 0 0 * * *"
+  schedule: "0 0 0 * * *"  # At midnight every day
   backupOwnerReference: self
   cluster:
     name: pg-backup
+  # method: plugin, volumeSnapshot, or barmanObjectStore (default)
 ```
 
-The above example will schedule a backup every day at midnight because the schedule
-specifies zero for the second, minute, and hour, while specifying wildcard, meaning all,
-for day of the month, month, and day of the week.
+The schedule `"0 0 0 * * *"` triggers a backup every day at midnight
+(00:00:00). In Kubernetes CronJobs, the equivalent expression would be `0 0 * * *`,
+since seconds are not supported.
 
-In Kubernetes CronJobs, the equivalent expression is `0 0 * * *` because seconds
-are not included.
+### Backup Frequency and RTO
 
 !!! Hint
-    Backup frequency might impact your recovery time objective ([RTO](before_you_start.md#rto)) after a
-    disaster which requires a full or Point-In-Time recovery operation. Our
-    advice is that you regularly test your backups by recovering them, and then
-    measuring the time it takes to recover from scratch so that you can refine
-    your RTO predictability. Recovery time is influenced by the size of the
-    base backup and the amount of WAL files that need to be fetched from the archive
-    and replayed during recovery (remember that WAL archiving is what enables
-    continuous backup in PostgreSQL!).
-    Based on our experience, a weekly base backup is more than enough for most
-    cases - while it is extremely rare to schedule backups more frequently than once
-    a day.
-
-You can choose whether to schedule a backup on a defined object store or a
-volume snapshot via the `.spec.method` attribute, by default set to
-`barmanObjectStore`. If you have properly defined
-[volume snapshots](backup_volumesnapshot.md#how-to-configure-volume-snapshot-backups)
-in the `backup` stanza of the cluster, you can set `method: volumeSnapshot`
-to start scheduling base backups on volume snapshots.
-
-ScheduledBackups can be suspended, if needed, by setting `.spec.suspend: true`.
-This will stop any new backup from being scheduled until the option is removed
-or set back to `false`.
-
-In case you want to issue a backup as soon as the ScheduledBackup resource is created
-you can set `.spec.immediate: true`.
+    The frequency of your backups directly impacts your **Recovery Time Objective**
+    ([RTO](before_you_start.md#rto)).
 
-!!! Note
-    `.spec.backupOwnerReference` indicates which ownerReference should be put inside
-    the created backup resources.
+To optimize your disaster recovery strategy based on continuous backup:
+
+- Regularly test restoring from your backups.
+- Measure the time required for a full recovery.
+- Account for the size of base backups and the number of WAL files that must be
+  retrieved and replayed.
+
+In most cases, a **weekly base backup** is sufficient. It is rare to schedule
+full backups more frequently than once per day.
+
+### Immediate Backup
+
+To trigger a backup immediately when the `ScheduledBackup` is created:
+
+```yaml
+spec:
+  immediate: true
+```
+
+### Pause Scheduled Backups
+
+To temporarily stop scheduled backups from running:
+
+```yaml
+spec:
+  suspend: true
+```
+
+### Backup Owner Reference (`.spec.backupOwnerReference`)
 
-    - *none:* no owner reference for created backup objects (same behavior as before the field was introduced)
-    - *self:* sets the Scheduled backup object as owner of the backup
-    - *cluster:* set the cluster as owner of the backup
+Controls which Kubernetes object is set as the owner of the backup resource:
 
-## On-demand backups
+- `none`: No owner reference (legacy behavior)
+- `self`: The `ScheduledBackup` object becomes the owner
+- `cluster`: The PostgreSQL cluster becomes the owner
+
+## On-Demand Backups
+
+On-demand backups allow you to manually trigger a backup operation at any time
+by creating a `Backup` resource.
 
 !!! Info
-    Please refer to [`BackupSpec`](cloudnative-pg.v1.md#postgresql-cnpg-io-v1-BackupSpec)
-    in the API reference for a full list of options.
+    For a full list of available options, see the
+    [`BackupSpec`](cloudnative-pg.v1.md#postgresql-cnpg-io-v1-BackupSpec) in the
+    API reference.
+
+### Example: Requesting an On-Demand Backup
 
-To request a new backup, you need to create a new `Backup` resource
-like the following one:
+To start an on-demand backup, apply a `Backup` request custom resource like the
+following:
 
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
@@ -252,20 +298,23 @@ spec:
     name: pg-backup
 ```
 
-In this case, the operator will start to orchestrate the cluster to take the
-required backup on an object store, using `barman-cloud-backup`. You can check
-the backup status using the plain `kubectl describe backup <name>` command:
+In this example, the operator will orchestrate the backup process using the
+`barman-cloud-backup` tool and store the backup in the configured object store.
+
+### Monitoring Backup Progress
+
+You can check the status of the backup using:
+
+```bash
+kubectl describe backup backup-example
+```
+
+While the backup is in progress, you'll see output similar to:
 
 ```text
 Name:         backup-example
 Namespace:    default
-Labels:       <none>
-Annotations:  API Version:  postgresql.cnpg.io/v1
-Kind:         Backup
-Metadata:
-  Creation Timestamp:  2020-10-26T13:57:40Z
-  Self Link:         /apis/postgresql.cnpg.io/v1/namespaces/default/backups/backup-example
-  UID:               ad5f855c-2ffd-454a-a157-900d5f1f6584
+...
 Spec:
   Cluster:
     Name:  pg-backup
@@ -275,59 +324,95 @@ Status:
 Events:        <none>
 ```
 
-When the backup has been completed, the phase will be `completed`
-like in the following example:
+Once the backup has successfully completed, the `phase` will be set to
+`completed`, and the output will include additional metadata:
 
 ```text
 Name:         backup-example
 Namespace:    default
-Labels:       <none>
-Annotations:  API Version:  postgresql.cnpg.io/v1
-Kind:         Backup
-Metadata:
-  Creation Timestamp:  2020-10-26T13:57:40Z
-  Self Link:         /apis/postgresql.cnpg.io/v1/namespaces/default/backups/backup-example
-  UID:               ad5f855c-2ffd-454a-a157-900d5f1f6584
-Spec:
-  Cluster:
-    Name:  pg-backup
+...
 Status:
   Backup Id:         20201026T135740
   Destination Path:  s3://backups/
   Endpoint URL:      http://minio:9000
   Phase:             completed
-  s3Credentials:
+  S3 Credentials:
     Access Key Id:
-      Key:   ACCESS_KEY_ID
       Name:  minio
+      Key:   ACCESS_KEY_ID
     Secret Access Key:
-      Key:      ACCESS_SECRET_KEY
-      Name:     minio
-  Server Name:  pg-backup
-  Started At:   2020-10-26T13:57:40Z
-  Stopped At:   2020-10-26T13:57:44Z
-Events:         <none>
+      Name:  minio
+      Key:   ACCESS_SECRET_KEY
+  Server Name:       pg-backup
+  Started At:        2020-10-26T13:57:40Z
+  Stopped At:        2020-10-26T13:57:44Z
 ```
 
-!!!Important
-    This feature will not backup the secrets for the superuser and the
-    application user. The secrets are supposed to be backed up as part of
-    the standard backup procedures for the Kubernetes cluster.
+---
 
-## Backup from a standby
+!!! Important
+    On-demand backups do **not** include Kubernetes secrets for the PostgreSQL
+    superuser or application user. You should ensure these secrets are included in
+    your broader Kubernetes cluster backup strategy.
 
-<!-- TODO: Adapt for Volume Snapshots -->
-Taking a base backup requires to scrape the whole data content of the
-PostgreSQL instance on disk, possibly resulting in I/O contention with the
-actual workload of the database.
+## Backup Methods
 
-For this reason, CloudNativePG allows you to take advantage of a
-feature which is directly available in PostgreSQL: **backup from a standby**.
+CloudNativePG currently supports the following backup methods for scheduled
+and on-demand backups:
 
-By default, backups will run on the most aligned replica of a `Cluster`. If
-no replicas are available, backups will run on the primary instance.
+- `plugin` – Uses a CNPG-I plugin (requires `.spec.pluginConfiguration`)
+- `volumeSnapshot` – Uses native [Kubernetes volume snapshots](appendixes/backup_volumesnapshot.md#how-to-configure-volume-snapshot-backups)
+- `barmanObjectStore` – Uses [Barman Cloud for object storage](appendixes/backup_barmanobjectstore.md)
+  *(deprecated starting with v1.26 in favor of the
+  [Barman Cloud Plugin](https://cloudnative-pg.io/plugin-barman-cloud/),
+  but still the default for backward compatibility)*
 
-!!! Info
+Specify the method using the `.spec.method` field (defaults to
+`barmanObjectStore`).
+
+If your cluster is configured to support volume snapshots, you can enable
+scheduled snapshot backups like this:
+
+```yaml
+spec:
+  method: volumeSnapshot
+```
+
+To use the Barman Cloud Plugin as the backup method, set `method: plugin` and
+configure the plugin accordingly. You can find an example in the
+["Performing a Base Backup" section of the plugin documentation](https://cloudnative-pg.io/plugin-barman-cloud/docs/usage/#performing-a-base-backup)
+
+## Backup from a Standby
+
+Taking a base backup involves reading the entire on-disk data set of a
+PostgreSQL instance, which can introduce I/O contention and impact the
+performance of the active workload.
+
+To reduce this impact, **CloudNativePG supports taking backups from a standby
+instance**, leveraging PostgreSQL’s built-in capability to perform backups from
+read-only replicas.
+
+By default, backups are performed on the **most up-to-date replica** in the
+cluster. If no replicas are available, the backup will fall back to the
+**primary instance**.
+
+!!! Note
+    The examples in this section are focused on backup target selection and do not
+    take the backup method (`spec.method`) into account, as it is not relevant to
+    the scope being discussed.
+
+### How It Works
+
+When `prefer-standby` is the target (the default behavior), CloudNativePG will
+attempt to:
+
+1. Identify the most synchronized standby node.
+2. Run the backup process on that standby.
+3. Fall back to the primary if no standbys are available.
+
+This strategy minimizes interference with the primary’s workload.
+
+!!! Warning
     Although the standby might not always be up to date with the primary,
     in the time continuum from the first available backup to the last
     archived WAL this is normally irrelevant. The base backup indeed
@@ -338,8 +423,10 @@ no replicas are available, backups will run on the primary instance.
     primary. This might produce unexpected results in the short term (before
     `archive_timeout` kicks in) in deployments with low write activity.
 
-If you prefer to always run backups on the primary, you can set the backup
-target to `primary` as outlined in the example below:
+### Forcing Backup on the Primary
+
+To always run backups on the primary instance, explicitly set the backup target
+to `primary` in the cluster configuration:
 
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
@@ -352,21 +439,16 @@ spec:
 ```
 
 !!! Warning
-    Beware of setting the target to primary when performing a cold backup
-    with volume snapshots, as this will shut down the primary for
-    the time needed to take the snapshot, impacting write operations.
-    This also applies to taking a cold backup in a single-instance cluster, even
-    if you did not explicitly set the primary as the target.
+    Be cautious when using `primary` as the target for **cold backups using
+    volume snapshots**, as this will require shutting down the primary instance
+    temporarily—interrupting all write operations. The same caution applies to
+    single-instance clusters, even if you haven't explicitly set the target.
 
-When the backup target is set to `prefer-standby`, such policy will ensure
-backups are run on the most up-to-date available secondary instance, or if no
-other instance is available, on the primary instance.
+### Overriding the Cluster-Wide Target
 
-By default, when not otherwise specified, target is automatically set to take
-backups from a standby.
-
-The backup target specified in the `Cluster` can be overridden in the `Backup`
-and `ScheduledBackup` types, like in the following example:
+You can override the cluster-level target on a per-backup basis, using either
+`Backup` or `ScheduledBackup` resources. Here's an example of an on-demand
+backup:
 
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
@@ -379,5 +461,24 @@ spec:
   target: "primary"
 ```
 
-In the previous example, CloudNativePG will invariably choose the primary
-instance even if the `Cluster` is set to prefer replicas.
+In this example, even if the cluster’s default target is `prefer-standby`, the
+backup will be taken from the primary instance.
+
+## Retention Policies
+
+CloudNativePG is evolving toward a **backup-agnostic architecture**, where
+backup responsibilities are delegated to external **CNPG-I plugins**. These
+plugins are expected to offer advanced and customizable data protection
+features, including sophisticated retention management, that go beyond the
+built-in capabilities and scope of CloudNativePG.
+
+As part of this transition, the `spec.backup.retentionPolicy` field in the
+`Cluster` resource is **deprecated** and will be removed in a future release.
+
+For more details on available retention features, refer to your chosen plugin’s documentation.
+For example: ["Retention Policies" with Barman Cloud Plugin](https://cloudnative-pg.io/plugin-barman-cloud/docs/retention/).
+
+!!! Important
+    Users are encouraged to rely on the retention mechanisms provided by the
+    backup plugin they are using. This ensures better flexibility and consistency
+    with the backup method in use.
diff --git a/docs/src/bootstrap.md b/docs/src/bootstrap.md
index ded39278c9..f074ced936 100644
--- a/docs/src/bootstrap.md
+++ b/docs/src/bootstrap.md
@@ -441,9 +441,9 @@ by `name` (our recommendation is to use the same `name` of the origin cluster).
     By default the `recovery` method strictly uses the `name` of the
     cluster in the `externalClusters` section to locate the main folder
     of the backup data within the object store, which is normally reserved
-    for the name of the server. You can specify a different one with the
-    `barmanObjectStore.serverName` property (by default assigned to the
-    value of `name` in the external cluster definition).
+    for the name of the server. Backup plugins provide ways to specify a
+    different one. For example, the Barman Cloud Plugin provides the [`serverName` parameter](https://cloudnative-pg.io/plugin-barman-cloud/docs/parameters/)
+    (by default assigned to the value of `name` in the external cluster definition).
 
 ### Bootstrap from a backup (`recovery`)
 
diff --git a/docs/src/index.md b/docs/src/index.md
index c1f8ef984a..540274a100 100644
--- a/docs/src/index.md
+++ b/docs/src/index.md
@@ -110,14 +110,22 @@ Additionally, the community provides images for the [PostGIS extension](postgis.
     - Support for Local Persistent Volumes with PVC templates.
     - Reuse of Persistent Volumes storage in Pods.
     - Separate volumes for WAL files and tablespaces.
-- Backup and recovery options, including:
-    - Integration with the [Barman Cloud plugin](https://github.com/cloudnative-pg/plugin-barman-cloud)
-      for continuous online backup via WAL archiving to AWS S3, S3-compatible
-      services, Azure Blob Storage, and Google Cloud Storage, with support for
-      retention policies based on a configurable recovery window.
-    - Backups using volume snapshots (where supported by storage classes).
-    - Full and Point-In-Time recovery from volume snapshots or object stores (via Barman Cloud plugin).
-    - Backup from standby replicas to reduce primary workload impact.
+- Backup and Recovery via CNPG-I Plugins:
+    - Pluggable architecture for continuous physical backup and recovery.
+    - Hot and cold base backups.
+    - WAL archiving.
+    - Full and Point-In-Time Recovery (PITR).
+    - Scheduled and on-demand backups.
+    - Backup from standbys to reduce primary load.
+- Community-Supported Barman Cloud Plugin:
+    - WAL archiving to object stores with support for full/PITR recovery.
+    - Retention policies based on configurable recovery windows.
+    - Supported as a CNPG-I plugin (recommended approach).
+- Native Backup Methods:
+    - Continuous backup and full/PITR recovery via volume snapshots (if
+      supported by the storage class).
+    - Native integration with Barman Cloud for object store backups via
+      `.spec.backup.barmanObjectStore` (*deprecated since v1.26*).
 - Offline in-place major upgrades of PostgreSQL
 - Offline and online import of PostgreSQL databases, including major upgrades:
     - *Offline Import*: Direct restore from existing databases.
diff --git a/docs/src/operator_capability_levels.md b/docs/src/operator_capability_levels.md
index b7eeb208dd..b69204c882 100644
--- a/docs/src/operator_capability_levels.md
+++ b/docs/src/operator_capability_levels.md
@@ -379,39 +379,37 @@ in the archive. In addition, `Instance Manager` checks
 the correctness of the archive destination by performing the `barman-cloud-check-wal-archive`
 command before beginning to ship the first set of WAL files.
 
-### PostgreSQL backups
+### PostgreSQL Backups
 
-The operator was designed to provide application-level backups using
-PostgreSQL’s native continuous hot backup technology based on
-physical base backups and continuous WAL archiving.
-Base backups can be saved on:
+CloudNativePG provides a pluggable interface (CNPG-I) for managing
+application-level backups using PostgreSQL’s native physical backup
+mechanisms—namely base backups and continuous WAL archiving. This
+design enables flexibility and extensibility while ensuring consistency and
+performance.
 
-- Kubernetes volume snapshots
-- Object stores (AWS S3 and S3-compatible, Azure Blob Storage, Google Cloud
-  Storage, and gateways like MinIO)
+The CloudNativePG Community officially supports the [Barman Cloud Plugin](https://cloudnative-pg.io/plugin-barman-cloud/),
+which enables continuous physical backups to object stores, along with full and
+Point-In-Time Recovery (PITR) capabilities.
 
-Base backups are defined at the cluster level, declaratively,
-through the `backup` parameter in the cluster definition.
+In addition to CNPG-I plugins, CloudNativePG also natively supports backups
+using Kubernetes volume snapshots, when supported by the underlying storage
+class and CSI driver.
 
-You can define base backups in two ways:
+You can initiate base backups in two ways:
 
-- On-demand, through the `Backup` custom resource definition
-- Scheduled, through the `ScheduledBackup`custom resource definition, using a cron-like syntax
+- On-demand, using the `Backup` custom resource
+- Scheduled, using the `ScheduledBackup` custom resource, with a cron-like
+  schedule format
 
-Volume snapshots rely directly on the Kubernetes API, which delegates this
-capability to the underlying storage classes and CSI drivers. Volume snapshot
-backups are suitable for very large database (VLDB) contexts.
+Volume snapshots leverage the Kubernetes API and are particularly effective for
+very large databases (VLDBs) due to their speed and storage efficiency.
 
-Object store backups rely on `barman-cloud-backup` for the job (distributed as
-part of the application container image) to relay backups in the same endpoint,
-alongside WAL files.
+Both volume snapshots and CNPG-I-based backups support:
 
-Both `barman-cloud-wal-restore` and `barman-cloud-backup` are distributed in
-the application container image under GNU GPL 3 terms.
-
-Object store backups and volume snapshot backups are taken while PostgreSQL is
-up and running (hot backups). Volume snapshots also support taking consistent
-database snapshots with cold backups.
+- Hot backups: Taken while PostgreSQL is running, ensuring minimal
+  disruption.
+- Cold backups: Performed by temporarily stopping PostgreSQL to ensure a
+  fully consistent snapshot, when required.
 
 ### Backups from a standby
 
@@ -423,8 +421,8 @@ operations.
 ### Full restore from a backup
 
 The operator enables you to bootstrap a new cluster (with its settings)
-starting from an existing and accessible backup, either on a volume snapshot
-or in an object store.
+starting from an existing and accessible backup, either on a volume snapshot,
+or in an object store, or via a plugin.
 
 Once the bootstrap process is completed, the operator initiates the instance in
 recovery mode. It replays all available WAL files from the specified archive,
diff --git a/docs/src/recovery.md b/docs/src/recovery.md
index 9f915aab31..5aba0eecc0 100644
--- a/docs/src/recovery.md
+++ b/docs/src/recovery.md
@@ -1,73 +1,86 @@
 # Recovery
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 
-!!! Warning
-    With the deprecation of native Barman Cloud support in CloudNativePG in
-    favor of the Barman Cloud Plugin, this page—and the backup and recovery
-    documentation—may undergo changes before the official release of version
-    1.26.0.
-
-In PostgreSQL terminology, recovery is the process of starting a PostgreSQL
-instance using an existing backup. The PostgreSQL recovery mechanism
-is very solid and rich. It also supports point-in-time recovery (PITR), which allows
-you to restore a given cluster up to any point in time, from the first available
-backup in your catalog to the last archived WAL. (The WAL
-archive is mandatory in this case.)
-
-In CloudNativePG, you can't perform recovery in place on an existing
-cluster. Recovery is instead a way to bootstrap a new Postgres cluster
-starting from an available physical backup.
+In PostgreSQL, **recovery** refers to the process of starting an instance from
+an existing physical backup. PostgreSQL's recovery system is robust and
+feature-rich, supporting **Point-In-Time Recovery (PITR)**—the ability to
+restore a cluster to any specific moment, from the earliest available backup to
+the latest archived WAL file.
+
+!!! Important
+    A valid WAL archive is required to perform PITR.
+
+In CloudNativePG, recovery is **not performed in-place** on an existing
+cluster. Instead, it is used to **bootstrap a new cluster** from a physical
+backup.
 
 !!! Note
-    For details on the `bootstrap` stanza, see
+    For more details on configuring the `bootstrap` stanza, refer to
     [Bootstrap](bootstrap.md).
 
-The `recovery` bootstrap mode lets you create a cluster from an existing
-physical base backup. You then reapply the WAL files containing the REDO log
-from the archive.
+The `recovery` bootstrap mode allows you to initialize a cluster from a
+physical base backup and replay the associated WAL files to bring the system to
+a consistent and optionally point-in-time state.
 
-WAL files are pulled from the defined *recovery object store*.
+CloudNativePG supports recovery via:
 
-Base backups can be taken either on object stores or using volume snapshots.
+- A **pluggable backup and recovery interface (CNPG-I)**, enabling integration
+  with external tools such as the [Barman Cloud Plugin](https://cloudnative-pg.io/plugin-barman-cloud/).
+- **Native recovery from volume snapshots**, where supported by the underlying
+  Kubernetes storage infrastructure.
+- **Native recovery from object stores via Barman Cloud**, which is
+  **deprecated** as of version 1.26 in favor of the plugin-based approach.
 
-!!! Info
-    Starting with version 1.25, CloudNativePG includes experimental support for
-    backup and recovery using plugins, such as the
-    [Barman Cloud plugin](https://github.com/cloudnative-pg/plugin-barman-cloud).
+With the deprecation of native Barman Cloud support in version 1.26, this
+section now focuses on two supported recovery methods: using the **Barman Cloud
+Plugin** for recovery from object stores, and the **native interface** for
+recovery from volume snapshots.
 
-You can achieve recovery from a *recovery object store* in two ways:
+!!! Important
+    For legacy documentation, see
+    [Appendix B – Recovery from an Object Store](appendixes/backup_barmanobjectstore.md#recovery-from-an-object-store).
 
-- We recommend using a recovery object store, that is, a backup of another cluster
-  created by Barman Cloud and defined by way of the `barmanObjectStore` option
-  in the `externalClusters` section.
-- Alternatively, you can use an existing `Backup` object in the same namespace.
+## Recovery from an Object Store with the Barman Cloud Plugin
 
-Both recovery methods enable either full recovery (up to the last
-available WAL) or up to a [point in time](#point-in-time-recovery-pitr).
-When performing a full recovery, you can also start the cluster
-in replica mode (see [replica clusters](replica_cluster.md) for reference).
+This section outlines how to recover a PostgreSQL cluster from an object store
+using the recommended Barman Cloud Plugin.
 
 !!! Important
-    If using replica mode, make sure that the PostgreSQL configuration
-    (`.spec.postgresql.parameters`) of the recovered cluster is compatible with
-    the original one from a physical replication standpoint.
-
-For recovery using *volume snapshots*:
+    The object store must contain backup data produced by a CloudNativePG
+    `Cluster`—either using the **deprecated native Barman Cloud integration** or
+    the **Barman Cloud Plugin**.
 
-- Use a consistent set of `VolumeSnapshot` objects that all belong to the
-  same backup and are identified by the same `cnpg.io/cluster` and
-  `cnpg.io/backupName` labels. Then, recover through the `volumeSnapshots`
-  option in the `.spec.bootstrap.recovery` stanza, as described in
-  [Recovery from `VolumeSnapshot` objects](#recovery-from-volumesnapshot-objects).
+!!! Info
+    For full details, refer to the
+    [“Recovery of a Postgres Cluster” section in the Barman Cloud Plugin documentation](https://cloudnative-pg.io/plugin-barman-cloud/docs/concepts/#recovery-of-a-postgres-cluster).
 
-## Recovery from an object store
+Begin by defining the object store that holds both your base backups and WAL
+files. The Barman Cloud Plugin uses a custom `ObjectStore` resource for this
+purpose. The following example shows how to configure one for Azure Blob
+Storage:
 
-You can recover from a backup created by Barman Cloud and stored on a supported
-object store. After you define the external cluster, including all the required
-configuration in the `barmanObjectStore` section, you need to reference it in
-the `.spec.recovery.source` option.
+```yaml
+apiVersion: barmancloud.cnpg.io/v1
+kind: ObjectStore
+metadata:
+  name: cluster-example-backup
+spec:
+  configuration:
+    destinationPath: https://STORAGEACCOUNTNAME.blob.core.windows.net/CONTAINERNAME/
+    azureCredentials:
+      storageAccount:
+        name: recovery-object-store-secret
+        key: storage_account_name
+      storageKey:
+        name: recovery-object-store-secret
+        key: storage_account_key
+    wal:
+      maxParallel: 8
+```
 
-This example defines a recovery object store in a blob container in Azure:
+Next, configure the `Cluster` resource to use the `ObjectStore` you defined. In
+the `bootstrap` section, specify the recovery source, and define an
+`externalCluster` entry that references the plugin:
 
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
@@ -82,55 +95,39 @@ spec:
 
   bootstrap:
     recovery:
-      source: clusterBackup
+      source: origin
 
   externalClusters:
-    - name: clusterBackup
-      barmanObjectStore:
-        destinationPath: https://STORAGEACCOUNTNAME.blob.core.windows.net/CONTAINERNAME/
-        azureCredentials:
-          storageAccount:
-            name: recovery-object-store-secret
-            key: storage_account_name
-          storageKey:
-            name: recovery-object-store-secret
-            key: storage_account_key
-        wal:
-          maxParallel: 8
+    - name: origin
+      plugin:
+        name: barman-cloud.cloudnative-pg.io
+        parameters:
+          barmanObjectName: cluster-example-backup
+          serverName: cluster-example
 ```
 
-The previous example assumes that the application database and its owning user
-are named `app` by default. If the PostgreSQL cluster being restored uses
-different names, you must specify these names before exiting the recovery phase,
-as documented in ["Configure the application database"](#configure-the-application-database).
-
-!!! Important
-    By default, the `recovery` method strictly uses the `name` of the
-    cluster in the `externalClusters` section as the name of the main folder
-    of the backup data within the object store. This name is normally reserved
-    for the name of the server. You can specify a different folder name
-    using the `barmanObjectStore.serverName` property.
-
-!!! Note
-    This example takes advantage of the parallel WAL restore feature,
-    dedicating up to 8 jobs to concurrently fetch the required WAL files from the
-    archive. This feature can appreciably reduce the recovery time. Make sure that
-    you plan ahead for this scenario and correctly tune the value of this parameter
-    for your environment. It will make a difference when you need it, and you will.
-
-## Recovery from `VolumeSnapshot` objects
+## Recovery from `VolumeSnapshot` Objects
 
 !!! Warning
-    When creating replicas after recovering the primary instance from
-    the volume snapshot, the operator might end up using `pg_basebackup`
-    to synchronize them. This behavior results in a slower process, depending
-    on the size of the database. This limitation will be lifted in the future when
-    support for online backups and PVC cloning are introduced.
-
-CloudNativePG can create a new cluster from a `VolumeSnapshot` of a PVC of an
-existing `Cluster` that's been taken using the declarative API for [volume
-snapshot backups](backup_volumesnapshot.md). You must specify the name of the
-snapshot, as in the following example:
+    When creating replicas after recovering a primary instance from a
+    `VolumeSnapshot`, the operator may fall back to using `pg_basebackup` to
+    synchronize them. This process can be significantly slower—especially for large
+    databases—because it involves a full base backup. This limitation will be
+    addressed in the future with support for online backups and PVC cloning in
+    the scale-up process.
+
+CloudNativePG allows you to create a new cluster from a `VolumeSnapshot` of a
+`PersistentVolumeClaim` (PVC) that belongs to an existing `Cluster`.
+These snapshots are created using the declarative API for
+[volume snapshot backups](appendixes/backup_volumesnapshot.md).
+
+To complete the recovery process, the new cluster must also reference an
+external cluster that provides access to the WAL archive needed to reapply
+changes and finalize the recovery.
+
+The following example shows a cluster being recovered using both a
+`VolumeSnapshot` for the base backup and a WAL archive accessed through the
+Barman Cloud Plugin:
 
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
@@ -142,11 +139,20 @@ spec:
 
   bootstrap:
     recovery:
+      source: origin
       volumeSnapshots:
         storage:
           name: <snapshot name>
           kind: VolumeSnapshot
           apiGroup: snapshot.storage.k8s.io
+
+  externalClusters:
+    - name: origin
+      plugin:
+        name: barman-cloud.cloudnative-pg.io
+        parameters:
+          barmanObjectName: cluster-example-backup
+          serverName: cluster-example
 ```
 
 In case the backed-up cluster was using a separate PVC to store the WAL files,
@@ -260,9 +266,9 @@ feature to work if you specify a recovery target.
 
 ### PITR from an object store
 
-This example uses a recovery object store in Azure that contains both
-the base backups and the WAL archive. The recovery target is based on a
-requested timestamp.
+This example uses the same recovery object store in Azure defined earlier for
+the Barman Cloud plugin, containing both the base backups and the WAL archive.
+The recovery target is based on a requested timestamp.
 
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
@@ -278,24 +284,18 @@ spec:
   bootstrap:
     recovery:
       # Recovery object store containing WAL archive and base backups
-      source: clusterBackup
+      source: origin
       recoveryTarget:
         # Time base target for the recovery
         targetTime: "2023-08-11 11:14:21.00000+02"
 
   externalClusters:
-    - name: clusterBackup
-      barmanObjectStore:
-        destinationPath: https://STORAGEACCOUNTNAME.blob.core.windows.net/CONTAINERNAME/
-        azureCredentials:
-          storageAccount:
-            name: recovery-object-store-secret
-            key: storage_account_name
-          storageKey:
-            name: recovery-object-store-secret
-            key: storage_account_key
-        wal:
-          maxParallel: 8
+    - name: origin
+      plugin:
+        name: barman-cloud.cloudnative-pg.io
+        parameters:
+          barmanObjectName: cluster-example-backup
+          serverName: cluster-example
 ```
 
 In this example, you had to specify only the `targetTime` in the form of a
@@ -320,17 +320,20 @@ the recovery as follows:
 - Otherwise, the operator selects the last available backup, in chronological
   order.
 
-### PITR from `VolumeSnapshot` objects
+### Point-in-Time Recovery (PITR) from `VolumeSnapshot` Objects
 
-The example that follows uses:
+The following example demonstrates how to perform a **Point-in-Time Recovery (PITR)** using:
 
-- A Kubernetes volume snapshot for the `PGDATA` containing the base backup from
-  which to start the recovery process. This snapshot is identified in the
-  `recovery.volumeSnapshots` section and called `test-snapshot-1`.
-- A recovery object store in MinIO containing the WAL archive. The object store is identified by
-  the `recovery.source` option in the form of an external cluster definition.
+- A Kubernetes `VolumeSnapshot` of the `PGDATA` directory, which provides the
+  base backup. This snapshot is specified in the `recovery.volumeSnapshots`
+  section and is named `test-snapshot-1`.
+- A recovery object store (in this case, MinIO) containing the archived WAL
+  files. The object store is defined via a Barman Cloud Plugin `ObjectStore`
+  resource (not shown here), and referenced using the `recovery.source` field,
+  which points to an external cluster configuration.
 
-The recovery target is based on a requested timestamp.
+The cluster will be restored to a specific point in time using the
+`recoveryTarget.targetTime` option.
 
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
@@ -341,7 +344,7 @@ spec:
   # ...
   bootstrap:
     recovery:
-      source: cluster-example-with-backup
+      source: origin
       volumeSnapshots:
         storage:
           name: test-snapshot-1
@@ -350,19 +353,18 @@ spec:
       recoveryTarget:
         targetTime: "2023-07-06T08:00:39"
   externalClusters:
-    - name: cluster-example-with-backup
-      barmanObjectStore:
-        destinationPath: s3://backups/
-        endpointURL: http://minio:9000
-        s3Credentials:
-          accessKeyId:
-            name: minio
-            key: ACCESS_KEY_ID
-          secretAccessKey:
-            name: minio
-            key: ACCESS_SECRET_KEY
+    - name: origin
+      plugin:
+        name: barman-cloud.cloudnative-pg.io
+        parameters:
+          barmanObjectName: minio-backup
+          serverName: cluster-example
 ```
 
+This setup enables CloudNativePG to restore the base data from a volume
+snapshot and apply WAL segments from the object store to reach the desired
+recovery target.
+
 !!! Note
     If the backed-up cluster had `walStorage` enabled, you also must specify
     the volume snapshot containing the `PGWAL` directory, as mentioned in
@@ -381,6 +383,11 @@ targetTime
    [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339) format.
    (The precise stopping point is also influenced by the `exclusive` option.)
 
+!!! Warning
+    PostgreSQL recovery will stop when it encounters the first transaction that
+    occurs after the specified time. If no such transaction exists after the
+    target time, the recovery process will fail.
+
 targetXID
 :  Transaction ID up to which recovery proceeds.
    (The precise stopping point is also influenced by the `exclusive` option.)
@@ -416,7 +423,7 @@ kind: Cluster
 [...]
   bootstrap:
     recovery:
-      source: clusterBackup
+      source: origin
       recoveryTarget:
         backupID: 20220616T142236
         targetName: 'restore_point_1'
@@ -451,25 +458,19 @@ spec:
 
   bootstrap:
     recovery:
-      source: clusterBackup
+      source: origin
       recoveryTarget:
         backupID: 20220616T142236
         targetName: "maintenance-activity"
         exclusive: true
 
   externalClusters:
-    - name: clusterBackup
-      barmanObjectStore:
-        destinationPath: https://STORAGEACCOUNTNAME.blob.core.windows.net/CONTAINERNAME/
-        azureCredentials:
-          storageAccount:
-            name: recovery-object-store-secret
-            key: storage_account_name
-          storageKey:
-            name: recovery-object-store-secret
-            key: storage_account_key
-        wal:
-          maxParallel: 8
+    - name: origin
+      plugin:
+        name: barman-cloud.cloudnative-pg.io
+        parameters:
+          barmanObjectName: cluster-example-backup
+          serverName: cluster-example
 ```
 
 ## Configure the application database
@@ -551,10 +552,10 @@ When the base backup recovery process is complete, the operator starts the
 Postgres instance in recovery mode. In this phase, PostgreSQL is up, though not
 able to accept connections, and the pod is healthy according to the
 liveness probe. By way of the `restore_command`, PostgreSQL starts fetching WAL
-files from the archive. (You can speed up this phase by setting the
-`maxParallel` option and enabling the parallel WAL restore capability.)
+files from the archive. You can speed up this phase by setting the
+`maxParallel` option and enabling the parallel WAL restore capability.
 
-This phase terminates when PostgreSQL reaches the target (either the end of the
+This phase terminates when PostgreSQL reaches the target, either the end of the
 WAL or the required target in case of PITR. You can optionally specify a
 `recoveryTarget` to perform a PITR. If left unspecified, the recovery continues
 up to the latest available WAL on the default target timeline (`latest`).
@@ -566,57 +567,28 @@ remaining instances join the cluster as replicas.
 The process is transparent for the user and is managed by the instance manager
 running in the pods.
 
-## Restoring into a cluster with a backup section
-
-<!-- TODO: do we need this section? -->
-
-A manifest for a cluster restore might include a `backup` section. This means
-that,after recovery, the new cluster starts archiving WALs and taking backups
-if configured to do so.
-
-For example, this section is part of a manifest for a cluster bootstrapping
-from the cluster `cluster-example-backup`. In the storage bucket, it creates a
-folder named `recoveredCluster`, where the base backups and WALs of the
-recovered cluster are stored.
-
-``` yaml
-  backup:
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio:9000
-      serverName: "recoveredCluster"
-      s3Credentials:
-        accessKeyId:
-          name: minio
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio
-          key: ACCESS_SECRET_KEY
-    retentionPolicy: "30d"
+## Restoring into a Cluster with a Backup Section
 
-  externalClusters:
-  - name: cluster-example-backup
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio:9000
-      s3Credentials:
-```
+When restoring a cluster, the manifest may include a `plugins` section with
+Barman Cloud plugin pointing to a *backup* object store resource. This enables
+the newly created cluster to begin archiving WAL files and taking backups
+immediately after recovery—provided backup policies are configured.
 
-Don't reuse the same `barmanObjectStore` configuration for different clusters.
-There might be cases where the existing information in the storage buckets
-could be overwritten by the new cluster.
+Avoid reusing the same `ObjectStore` configuration for both *backup* and
+*recovery* in the same cluster. If you must, ensure that each cluster uses a
+unique `serverName` to prevent accidental overwrites of backup or WAL archive
+data.
 
 !!! Warning
-    The operator includes a safety check to ensure a cluster doesn't overwrite
-    a storage bucket that contained information. A cluster that would overwrite
-    existing storage remains in the state `Setting up primary` with pods in an
-    error state. The pod logs show: `ERROR: WAL archive check failed for server
-    recoveredCluster: Expected empty archive`.
+    CloudNativePG includes a safety check to prevent a cluster from overwriting
+    existing data in a shared storage bucket. If a conflict is detected, the
+    cluster remains in the `Setting up primary` state, and the associated pods will
+    fail with an error. The pod logs will display:
+    `ERROR: WAL archive check failed for server recoveredCluster: Expected empty archive`.
 
 !!! Important
-    If you set the `cnpg.io/skipEmptyWalArchiveCheck` annotation to `enabled`
-    in the recovered cluster, you can skip the safety check. We don't recommend
-    skipping the check because, for the general use case, the check works fine.
-    Skip this check only if you're familiar with the PostgreSQL recovery system, as
-    severe data loss can occur.
-
+    You can bypass this safety check by setting the
+    `cnpg.io/skipEmptyWalArchiveCheck` annotation to `enabled` on the recovered
+    cluster. However, this is strongly discouraged unless you are highly
+    familiar with PostgreSQL's recovery process. Skipping the check incorrectly can
+    lead to severe data loss. Use with caution and only in expert scenarios.
diff --git a/docs/src/replica_cluster.md b/docs/src/replica_cluster.md
index 71fd23a594..13548b4530 100644
--- a/docs/src/replica_cluster.md
+++ b/docs/src/replica_cluster.md
@@ -1,12 +1,6 @@
 # Replica clusters
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 
-!!! Warning
-    With the deprecation of native Barman Cloud support in CloudNativePG in
-    favor of the Barman Cloud Plugin, this page—and the backup and recovery
-    documentation—may undergo changes before the official release of version
-    1.26.0.
-
 A replica cluster is a CloudNativePG `Cluster` resource designed to
 replicate data from another PostgreSQL instance, ideally also managed by
 CloudNativePG.
@@ -95,8 +89,8 @@ recovery. There are three main options:
    seamless data transfer.
 2. **WAL Archive**: Use the WAL (Write-Ahead Logging) archive stored in an
    object store. WAL files are regularly transferred from the source cluster to
-   the object store, from where the `barman-cloud-wal-restore` utility retrieves
-   them for the replica cluster.
+   the object store, from where a CNPG-I plugin like [Barman Cloud](https://cloudnative-pg.io/plugin-barman-cloud/)
+   retrieves them for the replica cluster via the `restore_command`.
 3. **Hybrid Approach**: Combine both streaming replication and WAL archive
    methods. PostgreSQL can manage and switch between these two approaches as
    needed to ensure data consistency and availability.
@@ -105,13 +99,14 @@ recovery. There are three main options:
 
 When configuring the external cluster, you have the following options:
 
-<!-- TODO: Change before 1.26.0 -->
+- **`plugin` section**:
+    - Enables bootstrapping the replica cluster using a [CNPG-I](https://github.com/cloudnative-pg/cnpg-i)
+      plugin that support the
+      [`restore_job`](https://github.com/cloudnative-pg/cnpg-i/blob/main/docs/protocol.md#restore_job-proto)
+      and the [`wal`](https://github.com/cloudnative-pg/cnpg-i/blob/main/docs/protocol.md#wal-proto) protocols.
+    - CloudNativePG supports the [Barman Cloud Plugin](https://cloudnative-pg.io/plugin-barman-cloud/docs/usage/#restoring-a-cluster)
+      to allow bootstrapping the replica cluster from an object store.
 
-- **`barmanObjectStore` section**:
-    - Enables use of the WAL archive, with CloudNativePG automatically setting
-      the `restore_command` in the designated primary instance.
-    - Allows bootstrapping the replica cluster from an object store using the
-      `recovery` section if volume snapshots are not feasible.
 - **`connectionParameters` section**:
     - Enables bootstrapping the replica cluster via streaming replication using
       the `pg_basebackup` section.
@@ -119,6 +114,13 @@ When configuring the external cluster, you have the following options:
       designated primary instance, initiating a WAL receiver process to connect
       to the source cluster and receive data.
 
+You still have access to the **`barmanObjectStore` section**, although deprecated:
+
+- Enables use of the WAL archive, with CloudNativePG automatically setting
+  the `restore_command` in the designated primary instance.
+- Allows bootstrapping the replica cluster from an object store using the
+ `recovery` section if volume snapshots are not feasible.
+
 ### Backup and Symmetric Architectures
 
 The replica cluster can perform backups to a reserved object store from the
@@ -204,19 +206,23 @@ replication with WAL shipping as a fallback—as described in the
 section.
 
 Here’s how you would configure the `externalClusters` section for both
-`Cluster` resources:
+`Cluster` resources, relying on Barman Cloud Plugin for the object store:
 
 ```yaml
 # Distributed topology configuration
 externalClusters:
   - name: cluster-eu-south
-    barmanObjectStore:
-      destinationPath: s3://cluster-eu-south/
-      # Additional configuration
+    plugin:
+      name: barman-cloud.cloudnative-pg.io
+      parameters:
+        barmanObjectName: cluster-eu-south
+        serverName: cluster-eu-south
   - name: cluster-eu-central
-    barmanObjectStore:
-      destinationPath: s3://cluster-eu-central/
-      # Additional configuration
+    plugin:
+      name: barman-cloud.cloudnative-pg.io
+      parameters:
+        barmanObjectName: cluster-eu-central
+        serverName: cluster-eu-central
 ```
 
 The `.spec.replica` stanza for the `cluster-eu-south` PostgreSQL primary
@@ -508,10 +514,12 @@ a backup of the source cluster has been created already.
 ```yaml
   externalClusters:
   - name: <MAIN-CLUSTER>
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio:9000
-      s3Credentials:
+    # Example with Barman Cloud Plugin
+    plugin:
+      name: barman-cloud.cloudnative-pg.io
+      parameters:
+        barmanObjectName: <MAIN-CLUSTER>
+        serverName: <MAIN-CLUSTER>
         …
     connectionParameters:
       host: <MAIN-CLUSTER>-rw.default.svc
diff --git a/docs/src/wal_archiving.md b/docs/src/wal_archiving.md
index 06872e6829..b82bfa2c5d 100644
--- a/docs/src/wal_archiving.md
+++ b/docs/src/wal_archiving.md
@@ -1,83 +1,51 @@
 # WAL archiving
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 
-!!! Warning
-    With the deprecation of native Barman Cloud support in CloudNativePG in
-    favor of the Barman Cloud Plugin, this page—and the backup and recovery
-    documentation—may undergo changes before the official release of version
-    1.26.0.
+Write-Ahead Log (WAL) archiving in CloudNativePG is the process of continuously
+shipping WAL files to a designated object store from the PostgreSQL primary.
+These archives are essential for enabling Point-In-Time Recovery (PITR) and are
+a foundational component for both object store and volume snapshot-based backup
+strategies.
 
-WAL archiving is the process that feeds a [WAL archive](backup.md#wal-archive)
-in CloudNativePG.
+## Plugin-Based Architecture
 
-!!! Important
-    CloudNativePG currently only supports WAL archives on object stores. Such
-    WAL archives serve for both object store backups and volume snapshot backups.
-
-The WAL archive is defined in the `.spec.backup.barmanObjectStore` stanza of
-a `Cluster` resource. Please proceed with the same instructions you find in
-the ["Backup on object stores" section](backup_barmanobjectstore.md) to set up
-the WAL archive.
+CloudNativePG supports WAL archiving through a **plugin-based mechanism**,
+defined via the [`spec.pluginConfiguration`](cloudnative-pg.v1.md#postgresql-cnpg-io-v1-ClusterSpec)
+section of the `Cluster` resource.
 
-!!! Info
-    Please refer to [`BarmanObjectStoreConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration)
-    in the barman-cloud API for a full list of options.
+Only **one plugin at a time** can be responsible for WAL archiving. This is
+configured by setting the `isWALArchiver` field to `true` within the plugin
+configuration.
 
-If required, you can choose to compress WAL files as soon as they
-are uploaded and/or encrypt them:
+## Supported Plugins
 
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-[...]
-spec:
-  backup:
-    barmanObjectStore:
-      [...]
-      wal:
-        compression: gzip
-        encryption: AES256
-```
+Currently, the **Barman Cloud Plugin** is the only officially supported WAL
+archiving plugin maintained by the CloudNativePG Community.
+For full documentation, configuration options, and best practices, see the
+[Barman Cloud Plugin documentation](https://cloudnative-pg.io/plugin-barman-cloud/docs/intro/).
 
-You can configure the encryption directly in your bucket, and the operator
-will use it unless you override it in the cluster configuration.
+## Deprecation Notice: Native Barman Cloud
 
-PostgreSQL implements a sequential archiving scheme, where the
-`archive_command` will be executed sequentially for every WAL
-segment to be archived.
+CloudNativePG still supports WAL archiving natively through the
+`.spec.backup.barmanObjectStore` field. While still functional, **this
+interface is deprecated** and will be removed in a future release.
 
 !!! Important
-    By default, CloudNativePG sets `archive_timeout` to `5min`, ensuring
-    that WAL files, even in case of low workloads, are closed and archived
-    at least every 5 minutes, providing a deterministic time-based value for
-    your Recovery Point Objective ([RPO](before_you_start.md#rpo)). Even though you change the value
-    of the [`archive_timeout` setting in the PostgreSQL configuration](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-ARCHIVE-TIMEOUT),
-    our experience suggests that the default value set by the operator is
-    suitable for most use cases.
+    All new deployments are strongly encouraged to adopt the plugin-based
+    architecture, which offers a more flexible and maintainable approach.
 
-When the bandwidth between the PostgreSQL instance and the object
-store allows archiving more than one WAL file in parallel, you
-can use the parallel WAL archiving feature of the instance manager
-like in the following example:
+If you are currently using the native `.spec.backup.barmanObjectStore`
+approach, refer to the official guide for a smooth transition:
+[Migrating from Built-in CloudNativePG Backup](https://cloudnative-pg.io/plugin-barman-cloud/docs/migration/).
 
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-[...]
-spec:
-  backup:
-    barmanObjectStore:
-      [...]
-      wal:
-        compression: gzip
-        maxParallel: 8
-        encryption: AES256
-```
+## About the archive timeout
 
-In the previous example, the instance manager optimizes the WAL
-archiving process by archiving in parallel at most eight ready
-WALs, including the one requested by PostgreSQL.
+By default, CloudNativePG sets `archive_timeout` to `5min`, ensuring
+that WAL files, even in case of low workloads, are closed and archived
+at least every 5 minutes, providing a deterministic time-based value for
+your Recovery Point Objective ([RPO](before_you_start.md#rpo)).
 
-When PostgreSQL will request the archiving of a WAL that has
-already been archived by the instance manager as an optimization,
-that archival request will be just dismissed with a positive status.
+Even though you change the value of the
+[`archive_timeout` setting in the PostgreSQL configuration](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-ARCHIVE-TIMEOUT),
+our experience suggests that the default value set by the operator is suitable
+for most use cases.


Reviews:
user: login: smiyc
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-20T19:16:50Z
user: login: smiyc
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-20T19:18:29Z
user: login: smiyc
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-20T19:21:08Z
user: login: fcanovai
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-05-21T16:21:53Z
user: login: mnencia
state: APPROVED
author_association: MEMBER
submitted_at: 2025-05-21T17:48:11Z

Review comments:
diff_hunk: @@ -34,23 +37,91 @@ as it is composed of a community PostgreSQL image and the latest
 
 A backup is performed from a primary or a designated primary instance in a
 `Cluster` (please refer to
-[replica clusters](replica_cluster.md)
+[replica clusters](../replica_cluster.md)
 for more information about designated primary instances), or alternatively
-on a [standby](backup.md#backup-from-a-standby).
+on a [standby](../backup.md#backup-from-a-standby).
 
 ## Common object stores
 
 If you are looking for a specific object store such as
-[AWS S3](appendixes/object_stores.md#aws-s3),
-[Microsoft Azure Blob Storage](appendixes/object_stores.md#azure-blob-storage),
-[Google Cloud Storage](appendixes/object_stores.md#google-cloud-storage), or
-[MinIO Gateway](appendixes/object_stores.md#minio-gateway), or a compatible
-provider, please refer to [Appendix A - Common object stores](appendixes/object_stores.md).
+[AWS S3](object_stores.md#aws-s3),
+[Microsoft Azure Blob Storage](object_stores.md#azure-blob-storage),
+[Google Cloud Storage](object_stores.md#google-cloud-storage), or
+[MinIO Gateway](object_stores.md#minio-gateway), or a compatible
+provider, please refer to [Appendix C - Common object stores for backups](object_stores.md).
 
-## Retention policies
+## WAL archiving
+
+WAL archiving is the process that feeds a [WAL archive](../backup.md#wal-archive)
+in CloudNativePG.
+
+The WAL archive is defined in the `.spec.backup.barmanObjectStore` stanza of
+a `Cluster` resource.
+
+!!! Info
+    Please refer to [`BarmanObjectStoreConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration)
+    in the barman-cloud API for a full list of options.
+
+If required, you can choose to compress WAL files as soon as they
+are uploaded and/or encrypt them:
+
+```yaml
+apiVersion: postgresql.cnpg.io/v1
+kind: Cluster
+[...]
+spec:
+  backup:
+    barmanObjectStore:
+      [...]
+      wal:
+        compression: gzip
+        encryption: AES256
+```
+
+You can configure the encryption directly in your bucket, and the operator
+will use it unless you override it in the cluster configuration.
+
+PostgreSQL implements a sequential archiving scheme, where the
+`archive_command` will be executed sequentially for every WAL
+segment to be archived.
 
 !!! Important
-    Retention policies are not currently available on volume snapshots.
+    By default, CloudNativePG sets `archive_timeout` to `5min`, ensuring
+    that WAL files, even in case of low workloads, are closed and archived
+    at least every 5 minutes, providing a deterministic time-based value for
+    your Recovery Point Objective ([RPO](before_you_start.md#rpo)). Even though you change the value
path: docs/src/appendixes/backup_barmanobjectstore.md
user: login: smiyc
body: ../before_you_start.md#rpo)
created_at: 2025-05-20T19:16:50Z
author_association: CONTRIBUTOR
diff_hunk: @@ -209,3 +280,62 @@ spec:
         - "--max-concurrency=1"
         - "--read-timeout=60"
 ```
+
+## Recovery from an object store
+
+You can recover from a backup created by Barman Cloud and stored on a supported
+object store. After you define the external cluster, including all the required
+configuration in the `barmanObjectStore` section, you need to reference it in
+the `.spec.recovery.source` option.
+
+This example defines a recovery object store in a blob container in Azure:
+
+```yaml
+apiVersion: postgresql.cnpg.io/v1
+kind: Cluster
+metadata:
+  name: cluster-restore
+spec:
+  [...]
+
+  superuserSecret:
+    name: superuser-secret
+
+  bootstrap:
+    recovery:
+      source: clusterBackup
+
+  externalClusters:
+    - name: clusterBackup
+      barmanObjectStore:
+        destinationPath: https://STORAGEACCOUNTNAME.blob.core.windows.net/CONTAINERNAME/
+        azureCredentials:
+          storageAccount:
+            name: recovery-object-store-secret
+            key: storage_account_name
+          storageKey:
+            name: recovery-object-store-secret
+            key: storage_account_key
+        wal:
+          maxParallel: 8
+```
+
+The previous example assumes that the application database and its owning user
+are named `app` by default. If the PostgreSQL cluster being restored uses
+different names, you must specify these names before exiting the recovery phase,
+as documented in ["Configure the application database"](#configure-the-application-database).
path: docs/src/appendixes/backup_barmanobjectstore.md
user: login: smiyc
body: ../recovery.md#configure-the-application-database
created_at: 2025-05-20T19:18:29Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,73 +1,86 @@
 # Recovery
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 
-!!! Warning
-    With the deprecation of native Barman Cloud support in CloudNativePG in
-    favor of the Barman Cloud Plugin, this page—and the backup and recovery
-    documentation—may undergo changes before the official release of version
-    1.26.0.
-
-In PostgreSQL terminology, recovery is the process of starting a PostgreSQL
-instance using an existing backup. The PostgreSQL recovery mechanism
-is very solid and rich. It also supports point-in-time recovery (PITR), which allows
-you to restore a given cluster up to any point in time, from the first available
-backup in your catalog to the last archived WAL. (The WAL
-archive is mandatory in this case.)
-
-In CloudNativePG, you can't perform recovery in place on an existing
-cluster. Recovery is instead a way to bootstrap a new Postgres cluster
-starting from an available physical backup.
+In PostgreSQL, **recovery** refers to the process of starting an instance from
+an existing physical backup. PostgreSQL's recovery system is robust and
+feature-rich, supporting **Point-In-Time Recovery (PITR)**—the ability to
+restore a cluster to any specific moment, from the earliest available backup to
+the latest archived WAL file.
+
+!!! Important
+    A valid WAL archive is required to perform PITR.
+
+In CloudNativePG, recovery is **not performed in-place** on an existing
+cluster. Instead, it is used to **bootstrap a new cluster** from a physical
+backup.
 
 !!! Note
-    For details on the `bootstrap` stanza, see
+    For more details on configuring the `bootstrap` stanza, refer to
     [Bootstrap](bootstrap.md).
 
-The `recovery` bootstrap mode lets you create a cluster from an existing
-physical base backup. You then reapply the WAL files containing the REDO log
-from the archive.
+The `recovery` bootstrap mode allows you to initialize a cluster from a
+physical base backup and replay the associated WAL files to bring the system to
+a consistent and optionally point-in-time state.
 
-WAL files are pulled from the defined *recovery object store*.
+CloudNativePG supports recovery via:
 
-Base backups can be taken either on object stores or using volume snapshots.
+- A **pluggable backup and recovery interface (CNPG-I)**, enabling integration
+  with external tools such as the [Barman Cloud Plugin](https://cloudnative-pg.io/plugin-barman-cloud/).
+- **Native recovery from volume snapshots**, where supported by the underlying
+  Kubernetes storage infrastructure.
+- **Native recovery from object stores via Barman Cloud**, which is
+  **deprecated** as of version 1.26 in favor of the plugin-based approach.
 
-!!! Info
-    Starting with version 1.25, CloudNativePG includes experimental support for
-    backup and recovery using plugins, such as the
-    [Barman Cloud plugin](https://github.com/cloudnative-pg/plugin-barman-cloud).
+With the deprecation of native Barman Cloud support in version 1.26, this
+section now focuses on two supported recovery methods: using the **Barman Cloud
+Plugin** for recovery from object stores, and the **native interface** for
+recovery from volume snapshots.
 
-You can achieve recovery from a *recovery object store* in two ways:
+!!! Important
+    For legacy documentation, see
+    [Appendix B – Recovery from an Object Store](backup_barmanobjectstore.md#recovery-from-an-object-store).
path: docs/src/recovery.md
user: login: smiyc
body: appendixes/backup_barmanobjectstore.md#recovery-from-an-object-store
created_at: 2025-05-20T19:21:08Z
author_association: CONTRIBUTOR

PR comments:
user: login: github-actions[bot]
created_at: 2025-05-19T05:53:50Z
body: :exclamation: By default, the pull request is configured to backport to all release branches.

- To stop backporting this pr, remove the label:  backport-requested :arrow_backward: or add the label 'do not backport'
- To stop backporting this pr to a certain release branch, remove the specific branch label: release-x.y
author_association: CONTRIBUTOR
user: login: smiyc
created_at: 2025-05-20T19:10:34Z
body: @gbartolini  3 links are not working
I'll comment it in your commit

author_association: CONTRIBUTOR
user: login: gbartolini
created_at: 2025-05-21T06:08:16Z
body: > @gbartolini 3 links are not working I'll comment it in your commit

Thanks! Fixed.
author_association: CONTRIBUTOR
user: login: mnencia
created_at: 2025-05-21T17:48:32Z
body: /ok-to-merge docs only
author_association: MEMBER