Repository navigation
Unable to cluster:/spec/bootstrap/recovery/backup when backup is a plugin-barman-cloud #510
Description
cnpg version 1.27
plugin-barman-cloud v0.6.0
Given a backup
apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
labels:
cnpg.io/cluster: db1
name: db1-20250903144632
namespace: db-staging
spec:
cluster:
name: db1
method: plugin
pluginConfiguration:
name: barman-cloud.cloudnative-pg.io
I want to bootstrap a cluster
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: db2
namespace: db-staging
spec:
backup:
volumeSnapshot:
className: nodebound-storage-snapclass
bootstrap:
recovery:
backup:
name: db1-20250903144632
[...]
I get errors
{
"level":"error",
"ts":"2025-09-04T08:22:02.392371161Z",
"msg":"restore error",
"logging_pod":"db2-1-full-recovery",
"error":"while restoring cluster: missing Azure credentials",
"stacktrace":"github.com/cloudnative-pg/machinery/pkg/log.(*logger).Error\n\tpkg/mod/github.com/cloudnative-pg/machinery@v0.3.1/pkg/log/log.go:125\ngithub.com/cloudnative-pg/cloudnative-pg/internal/cmd/manager/instance/restore.NewCmd.func1\n\tinternal/cmd/manager/instance/restore/cmd.go:101\ngithub.com/spf13/cobra.(*Command).execute\n\tpkg/mod/github.com/spf13/cobra@v1.9.1/command.go:1015\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\tpkg/mod/github.com/spf13/cobra@v1.9.1/command.go:1148\ngithub.com/spf13/cobra.(*Command).Execute\n\tpkg/mod/github.com/spf13/cobra@v1.9.1/command.go:1071\nmain.main\n\tcmd/manager/main.go:71\nruntime.main\n\t/opt/hostedtoolcache/go/1.24.6/x64/src/runtime/proc.go:283"
}
- The backup manifest does not contain a reference to the ObjectStore.
- Adding a
/spec/pluginssection to the Cluster does not work - Adding an
externalClustersentry does not work as the bootstrap-recovery-backup spec only allows name
Is there a way to use an existing Backup object to bootstrap a Cluster ?
Reacted by Lars Tobias Skjong-Børsting and mlec
Activity
dosubot commentedon Sep 4, 2025
Hi @pvbiesen! I'm Dosu and I’m helping the plugin-barman-cloud team.
Restoring a cluster from a plugin-barman-cloud backup requires using the
externalClusterssection with the correct plugin and object store credentials. Referencing the backup by name in.spec.bootstrap.recovery.backup.nameis not sufficient for plugin-based backups, because it does not provide the necessary object store configuration or credentials, which leads to errors like "missing Azure credentials" during restore.The supported method is to use
.spec.bootstrap.recovery.sourceand define anexternalClustersentry with the plugin name, parameters (such asbarmanObjectNameandserverName), and credentials for the object store. This is documented as the required approach for plugin-barman-cloud restores, and there are no documented workarounds for using.spec.bootstrap.recovery.backup.namewith plugin-based backups. The backup manifest itself does not contain object store references; these must be supplied in the Cluster spec viaexternalClustersfor the restore to succeed. Adding/spec/pluginsonly enables WAL archiving for the running cluster and does not affect restore operations reference.To resolve your issue, switch to the documented restore workflow using
.spec.bootstrap.recovery.sourceand configureexternalClusterswith the required plugin and credentials reference.To reply, just mention @dosu.
Docs are dead. Just use Dosu.
pvbiesen commentedon Sep 4, 2025
Ok, so the answer is 'no'.
I was just wondering now if
.spec.bootstrap.recovery.backupwas going to be deprecated or fixed.dosubot commentedon Sep 4, 2025
There's no indication in the official documentation or recent release notes that
.spec.bootstrap.recovery.backupis going to be deprecated or fixed to support plugin-based backups. It remains a supported method for restoring from Backup objects in non-plugin scenarios, but for plugin-barman-cloud restores, the documented and supported workflow is still to use.spec.bootstrap.recovery.sourcewithexternalClustersfor credentials and configuration reference.To reply, just mention @dosu.
Docs are dead. Just use Dosu.
siegenthalerroger commentedon Sep 4, 2025
Seeing as the issue seems to be more rooted in CNPG's CRs (not the plugin's ones), a link to an issue with the same problems: #510