backup fails despite plugins are available

[Rammurthy5]

i got the plugin showing up. facing two errors even after referring the troubleshooting guide.

found two issues:

1. continous backup status is OK . tried basebackup and got requested plugin is not available: barman-cloud.cloudnative-pg.io error. plugin status show as below on cnpg status for the cluster.

Name Version Status Reported Operator Capabilities

---

barman-cloud.cloudnative-pg.io 0.9.0 N/A Reconciler Hooks, Lifecycle Service

2. adding retentionPolicy on barmanstore Yaml and tried to rid off No recovery window information found in ObjectStore 'db-backupstore' for server 'fusdb' error. it does not make a difference.

cloudnative PG v1.27.1

[dosubot]

Hi @Rammurthy5! I'm Dosu and I’m helping the plugin-barman-cloud team.

Your issues are both common with the Barman Cloud plugin and CloudNativePG v1.27.1. Here’s what’s happening and what you can do:

1. "Requested plugin is not available" error:
   Even if the plugin shows up in kubectl cnpg status, if the status is N/A, the operator cannot communicate with the plugin or the plugin is not fully registered. This can happen if the plugin deployment is not healthy, not in the same namespace as the operator, or if the plugin name in your Cluster/ScheduledBackup spec does not exactly match barman-cloud.cloudnative-pg.io (case-sensitive) source. Also, make sure your ScheduledBackup or Backup resource uses method: plugin and references the plugin name in pluginConfiguration source.

   • Check the plugin deployment:

     kubectl rollout status deployment -n cnpg-system barman-cloud
     

   • Make sure all pods are running the correct sidecar image (v0.9.0) and have no restarts.
   • If the plugin status remains N/A, try annotating your Cluster to trigger a rollout, or restart the pods source.

2. Retention policy and "No recovery window information found":
   Retention policies must be set in the ObjectStore resource, not in the Cluster spec. If you add retentionPolicy to the ObjectStore and still see this error, it usually means the backup metadata is missing or incomplete—often because no successful base backup has been taken yet, or the plugin cannot write/read metadata due to misconfiguration source.

   • Double-check that your ObjectStore YAML has retentionPolicy at the top level of the spec, not under configuration.
   • For S3-compatible storage (like MinIO), add these to spec.instanceSidecarConfiguration.env in your ObjectStore:

     - name: AWS_REQUEST_CHECKSUM_CALCULATION
       value: when_required
     - name: AWS_RESPONSE_CHECKSUM_VALIDATION
       value: when_required

     source
   • Make sure the barmanObjectName in your Cluster/ScheduledBackup matches the ObjectStore name and exists in the same namespace source.
   • If you’re using MinIO or another S3-compatible store, use the service name (not pod name) in endpointURL, and consider adding region: us-east-1 and usePathStyle: true under configuration source.

If you’ve checked all the above and still have issues, please share your Cluster, ObjectStore, and ScheduledBackup YAMLs, and the logs from the plugin sidecar and operator during the failed backup. This will help pinpoint any subtle misconfigurations.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[Rammurthy5]

@dosu tried the above steps and does not make a difference. here are my YAMLs

cluster

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: fusdb
  namespace: fus
spec:
  instances: 2
  imageName: <pulledimageForCNPG_FromECR>
  imagePullSecrets:
    - name: regcred
  imagePullPolicy: Always
  storage:
    size: 5Gi
    storageClass: "openebs-hostpath"
  primaryUpdateStrategy: unsupervised
  postgresql:
    shared_preload_libraries:
      - pg_partman_bgw
      - pg_cron
    parameters:
      shared_buffers: 256MB
      pg_stat_statements.max: '10000'
      auto_explain.log_min_duration: '10s'
      cron.database_name: 'firmware_rds'
    pg_hba:
      - host all all 10.244.0.0/16 md5
  bootstrap:
    initdb:
      database: <fillin>
      owner: <fillin>
      secret:
        name: dbsecret
  enableSuperuserAccess: true
  plugins:
    - name: barman-cloud.cloudnative-pg.io
      isWALArchiver: true
      parameters:
        barmanObjectName: db-backupstore

ObjectStore

plugins:
    - name: barman-cloud.cloudnative-pg.io
      isWALArchiver: true
      parameters:
        barmanObjectName: db-backupstore

Backup

apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  name: backup-example
  namespace: fus
spec:
  cluster:
    name: fusdb
  method: plugin
  pluginConfiguration:
    name: barman-cloud.cloudnative-pg.io

cnpg-status

Cluster Summary
Name                     fus/fusdb
System ID:               7569292432933662741
PostgreSQL Image:        830849038177.dkr.ecr.eu-west-2.amazonaws.com/fusdb:15
Primary instance:        fusdb-1
Primary promotion time:  2025-11-05 17:20:36 +0000 UTC (123h40m3s)
Status:                  Cluster in healthy state
Instances:               2
Ready instances:         2
Size:                    868M
Current Write LSN:       0/41000000 (Timeline: 1 - WAL File: 000000010000000000000040)

Continuous Backup status (Barman Cloud Plugin)
No recovery window information found in ObjectStore 'db-backupstore' for server 'fusdb'
Working WAL archiving:        OK
WALs waiting to be archived:  0
Last Archived WAL:            000000010000000000000040   @   2025-11-07T13:06:12.26557Z
Last Failed WAL:              -

Streaming Replication status
Replication Slots Enabled
Name     Sent LSN    Write LSN   Flush LSN   Replay LSN  Write Lag  Flush Lag  Replay Lag  State      Sync State  Sync Priority  Replication Slot
----     --------    ---------   ---------   ----------  ---------  ---------  ----------  -----      ----------  -------------  ----------------
fusdb-2  0/41000000  0/41000000  0/41000000  0/41000000  00:00:00   00:00:00   00:00:00    streaming  async       0              active

Instances status
Name     Current LSN  Replication role  Status  QoS         Manager Version  Node
----     -----------  ----------------  ------  ---         ---------------  ----
fusdb-1  0/41000000   Primary           OK      BestEffort  1.27.1           ip-10-192-128-68
fusdb-2  0/41000000   Standby (async)   OK      BestEffort  1.27.1           ip-10-192-128-81

Plugins status
Name                            Version  Status  Reported Operator Capabilities
----                            -------  ------  ------------------------------
barman-cloud.cloudnative-pg.io  0.9.0    N/A     Reconciler Hooks, Lifecycle Service

[dosubot]

Your symptoms—plugin status stuck at "N/A", "No recovery window information found", and backup failures—are common with the barman-cloud plugin on CloudNativePG 1.27.x and usually point to plugin registration or deployment issues, not just configuration.

Here’s what’s most likely happening and what you should check next:

• The "N/A" status means the operator can't communicate with the plugin or the plugin isn't fully registered. This can happen if the plugin deployment isn't healthy, the operator hasn't detected the plugin, or the plugin name/namespace doesn't match exactly. After deploying or upgrading the plugin, you must restart the CloudNativePG operator (controller-manager) to force it to detect the plugin—otherwise, the status will remain "N/A" even if the plugin is running. See this issue and this doc.

• The "No recovery window information found" error means the ObjectStore is missing backup metadata, usually because no successful base backup has been taken, or the plugin can't write/read metadata due to misconfiguration. This can also happen if the ObjectStore resource is missing required fields (like retentionPolicy, endpointURL, credentials, or environment variables for S3 compatibility), or if the referenced ObjectStore is in the wrong namespace or not named exactly as in your plugin parameters. See this doc and this issue.

• For S3-compatible storage (like MinIO), you must set AWS_REQUEST_CHECKSUM_CALCULATION and AWS_RESPONSE_CHECKSUM_VALIDATION to "when_required" in your ObjectStore's instanceSidecarConfiguration.env. Missing these can cause silent failures even if the status looks OK. See this issue.

• The ObjectStore YAML you posted is incomplete. Please double-check that your ObjectStore resource includes retentionPolicy at the top level, correct endpointURL, credentials, and the required environment variables. All referenced secrets must be in the same namespace as the cluster.

• If you recently upgraded the plugin or operator, make sure all pods are running the correct sidecar image (v0.9.0), and manually restart the operator deployment to refresh plugin registration.

• If you want the status output to show "configured", add an empty backup: {} section to your Cluster spec. This is a workaround for the status reporting bug in 1.27.x (details).

If you still see issues after these checks, please share your full ObjectStore YAML (with sensitive info redacted), the output of kubectl get pods -n and kubectl get objectstore -n , and logs from the barman-cloud sidecar and operator during a backup attempt. This will help pinpoint any subtle misconfigurations or deployment issues.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[Rammurthy5]

@dosu i updated my barmanobjectstore YAML. did not help.

apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
  name: db-backupstore
  namespace: fus
spec:
  retentionPolicy: "3d"
  configuration:
    destinationPath: s3://mybucket/
    endpointURL: http://minio.fus.svc.cluster.local:9000/
    s3Credentials:
      accessKeyId:
        name: miniocreds
        key: ACCESS_KEY_ID
      secretAccessKey:
        name: miniocreds
        key: ACCESS_SECRET_KEY
    wal:
      compression: gzip
  instanceSidecarConfiguration:
    env:
      - name: AWS_REQUEST_CHECKSUM_CALCULATION
        value: when_required
      - name: AWS_RESPONSE_CHECKSUM_VALIDATION
        value: when_required

[dosubot]

Your ObjectStore YAML looks correct, but since updating it didn’t help, the issue is likely with plugin registration or deployment—not just configuration.

Here’s what to check next:

• Restart the CloudNativePG operator (controller-manager) after any plugin or ObjectStore changes. The operator only detects plugins at startup, so if you haven’t restarted it, the plugin status will stay “N/A” even if everything else is correct. Run:

  kubectl rollout restart deployment -n cnpg-system cnpg-controller-manager
  

  (or use your operator’s actual deployment name)
  Reference

• Use the MinIO service name in endpointURL, not the pod DNS name. Change:

  endpointURL: http://minio.fus.svc.cluster.local:9000/
  

  to something like:

  endpointURL: http://minio-service:9000/
  

  This avoids connectivity issues with S3-compatible storage.
  Reference

• Check RBAC resource migration: If you upgraded the plugin recently, RBAC roles and bindings now use the barman-plugin- prefix. If you haven’t deleted old resources and applied the new manifest, plugin registration may fail. See the Resource Name Migration Guide.

• Verify secrets and permissions: Make sure the miniocreds secret is in the same namespace as your cluster and ObjectStore, and that the plugin has permission to access it.

• Review pod logs: Look for errors in the barman-cloud sidecar and operator logs, especially around plugin registration, RPC, or S3 connectivity. Errors like MissingContentLength or permission denied can indicate deeper issues.

If you’ve done all this and the plugin status is still “N/A”, share the output of kubectl get pods -n fus, kubectl get objectstore -n fus, and any relevant logs from the plugin sidecar and operator during a backup attempt. This will help pinpoint the root cause.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[sbozkayajc]

@dosu i'm also having same issue

cluster

  bootstrap:
    initdb:
      database: xxxxx
      owner: xxxxxxxxx
      secret:
        name: <image>
      dataChecksums: true
      recovery:
        source: genesis
  externalClusters:
    - name: genesis
      plugin:
        name: barman-cloud.cloudnative-pg.io
        enabled: true
        isWALArchiver: false
        parameters:
          barmanObjectName:  genesis-objstore
          serverName: gensis-store

objectStore:

apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
  namespace: cloudnative-pg
  name: genesis-objstore
spec:
  configuration:
    destinationPath: s3://backup-path
    endpointURL: https://s3.us-west-2.amazonaws.com
    s3Credentials:
      inheritFromIAMRole: true
    wal:
      compression: gzip
      maxParallel: 8
  retentionPolicy: "30d"