feat(infra): cut backups over to the Barman Cloud Plugin + restore-drill docs (all envs)

What this does

Cuts every CNPG cluster’s backups over from the in-tree barmanObjectStore to the Barman Cloud Plugin, and ships the matching recovery docs in the same change:

1. Cutover — flips …backup.plugin.enabled to true in all envs at once: tuist main cluster (values-managed-{staging,canary,production}.yaml) and tuist-ops (values.yaml).
2. Restore-drill docs — updates infra/cnpg/README.md so the restore drill recovers through the plugin (bootstrap.recovery + externalClusters[].plugin → the rendered ObjectStore by barmanObjectName, serverName pinned to the cluster name), with the in-tree shape kept for the transition. This is pepicrft’s gating follow-up from the #11544 review — folding it in here means the recovery docs land exactly when the flip happens (closes #11563).
3. Minor: corrects the plugin deployment name in the README (platform-plugin-barman-cloud, release-prefixed as a subchart).

The plugin itself is already installed fleet-wide and idle (#11544, confirmed platform-plugin-barman-cloud Running 1/1 on canary + prod). This is the flip that puts it to work.

What merging does

Each cluster’s Cluster spec swaps .spec.backup.barmanObjectStore for .spec.plugins (+ an ObjectStore CR, ScheduledBackup method: plugin). That’s an atomic Cluster change, so it triggers a rolling update + primary switchover per cluster — same shape as an operator bump. Merge in a low-traffic window. The production-deployment cascade flips canary first, runs acceptance tests, then production, so it’s naturally canary-gated despite being one PR (staging flips via its own deploy path).

Continuity & safety

• serverName stays pinned to the cluster name (the in-tree default) and the bucket/destinationPath is unchanged, so the plugin continues the same archive prefix — no new base backup, no orphaned PITR. Verified by helm template: production renders plugins (serverName tuist-tuist-pg, ObjectStore tuist-tuist-pg-backup-store) + method: plugin, no barmanObjectStore.
• Reversible: flip back to false and the in-tree path resumes (still supported on 1.29).
• Fallback: the in-tree backups taken up to the cutover remain in the same bucket.

After merge (verify)

1. Watch canary roll, then prod — confirm instances converge with a primary elected.
2. Confirm WAL archiving continues on the plugin path: primary pod logs show Archived WAL file to the same s3://…/<serverName> path, no persistent errors, pg_wal not piling.
3. Run the restore-validation drill (now documented for the plugin) from a plugin-written backup.
4. Repoint backup observability: metrics rename cnpg_collector_* -> barman_cloud_cloudnative_pg_io_*.

🤖 Generated with Claude Code

No GitHub comments yet.