[Bug]: firstRecoverabilityPoint not populated via Barman backup plugin

[centaurea-riba]

Is there an existing issue already for this bug?

• I have searched for an existing issue, and could not find anything. I believe this is a new bug.

I have read the troubleshooting guide

• I have read the troubleshooting guide and I think this is a new bug.

I am running a supported version of CloudNativePG

• I have read the troubleshooting guide and I think this is a new bug.

Contact Details

No response

Version

1.28 (latest patch)

What version of Kubernetes are you using?

1.34

What is your Kubernetes environment?

Other

How did you install the operator?

Helm

What happened?

A regression (kind of) has been identified in the CNPG metrics pipeline affecting two critical backup-related fields: firstRecoverabilityPoint and lastSuccessfulBackupTime.

Previously, these fields were populated directly on the Cluster CR status, making them consistently available to the metrics exporter. However, after adopting the Barman plugin, these fields are now sourced from the ObjectStore CR instead. As a result, the metrics exporter no longer exposes them correctly, causing silent data gaps in observability tooling.

Cluster resource

kubectl get objectstore minio-storage -n sonarqube -o json | jq '.status'
{
  "serverRecoveryWindow": {
    "sonarqube-cnpg-cluster": {
      "firstRecoverabilityPoint": "2026-04-14T13:37:23Z",
      "lastSuccessfulBackupTime": "2026-04-16T00:00:01Z"
    }
  }
}

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[dosubot]

Hi @centaurea-riba! I'm Dosu and I’m helping the cloudnative-pg team.

This is a previously reported issue that affects CloudNativePG 1.26+ when using the Barman Cloud plugin. The root cause is that the metrics exporter still reads firstRecoverabilityPoint and lastSuccessfulBackup from the Cluster CR status, but plugin-based backups now store these fields in the ObjectStore CR status instead [1] [2]. Related issues include #8902 [3] and #7812 [4].

The fix was introduced in CloudNativePG 1.27.0 + Barman Cloud plugin 0.7.0, which added a plugin-based metrics framework [5]. The Barman Cloud plugin now exposes replacement metrics directly from the ObjectStore CR [6]:

• barman_cloud_cloudnative_pg_io_first_recoverability_point
• barman_cloud_cloudnative_pg_io_last_available_backup_timestamp
• barman_cloud_cloudnative_pg_io_last_failed_backup_timestamp

These replace the deprecated cnpg_collector_* equivalents [4].

On 1.28, if you're not seeing these new metrics, make sure:

1. isWALArchiver: true is set in the plugin configuration — this is required for the plugin to inject the metrics sidecar [7]:

   spec:
     backup:
       barmanObjectStore:
         plugin:
           name: barman-cloud.cloudnative-pg.io
           parameters:
             isWALArchiver: "true"

2. Your monitoring stack is scraping the new metric names (the old cnpg_collector_* names will remain stale/zero).

3. You can verify metrics are being exposed by port-forwarding to a pod and curling the metrics endpoint:

   kubectl port-forward <pod-name> 9187:9187
   curl http://localhost:9187/metrics | grep barman_cloud_cloudnative_pg_io

Since you're on 1.28, the fix should already be available — it's likely a configuration or scraping issue on your end. If the new metrics still don't appear after the above checks, there may be PodMonitor/ServiceMonitor configuration gaps depending on your installation method [8].

To reply, just mention @dosu.

---

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

[centaurea-riba]

@dosu Ok. Why official dashboard not use new metrics instead?

[dosubot]

The official Grafana dashboard has actually been updated to query both the deprecated and new metric names using regex patterns. For example, the "First Recoverability Point" panel uses:

max({__name__=~"cnpg_collector_first_recoverability_point|barman_cloud_cloudnative_pg_io_first_recoverability_point", ...})

[1]

So the dashboard itself should work — it picks up whichever metric is available. The more likely reason the panels appear broken is one of these:

1. The new plugin metrics aren't being exposed at all. This happens when isWALArchiver is not set to "true" in the Barman Cloud plugin config — without it, the plugin doesn't inject the metrics sidecar, so only the stale/zero deprecated metrics exist in Prometheus [2].

2. You're using a cached or older version of the dashboard. If your dashboard was imported before the regex queries were added, it will only reference cnpg_collector_* names. Reimporting the latest JSON from the grafana-dashboards repo should fix that.

3. Stale deprecated metrics interfere. Even with the plugin working, the old cnpg_collector_* metrics may still be exposed with stale/zero values. The max() in the query can pick up the stale value instead of the correct plugin value, depending on which is larger.

I'd suggest verifying the new metrics are actually present by curling the pod's metrics endpoint and grepping for barman_cloud_cloudnative_pg_io. If they're missing, the isWALArchiver flag is the most common culprit.

To reply, just mention @dosu.

---

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

[centaurea-riba]

Dashboard on Grafana site is outdated, use direct url