ci(e2e): migrate e2e test to kind cluster

Signed-off-by: Tao Li <tao.li@enterprisedb.com>

.github/workflows/ci.yml

@@ -52,7 +52,7 @@ jobs:
           curl -L https://dl.dagger.io/dagger/install.sh | BIN_DIR=$HOME/.local/bin sh
       - name: Run CI task
         run: |
-          task ci
+          task all:ci
 
   publish:
     runs-on: ${{ vars.CI_RUNNERS || 'ubuntu-latest' }}
@@ -76,7 +76,7 @@ jobs:
           curl -L https://dl.dagger.io/dagger/install.sh | BIN_DIR=$HOME/.local/bin sh
       - name: Write manifest
         run: |
-          task manifest
+          task core:manifest
       - name: Publish images
         if: |
           github.event_name == 'workflow_dispatch' ||
@@ -85,9 +85,65 @@ jobs:
           REGISTRY_USER: ${{ github.actor }}
           REGISTRY_PASSWORD: ${{ secrets.GITHUB_TOKEN }}
         run: |
-          task publish
+          task core:publish
       - name: Attach manifest to workflow run
         uses: actions/upload-artifact@v7
         with:
           name: manifest.yaml
           path: ./manifest.yaml
+
+  integration-tests:
+    name: Integration Tests
+    runs-on: ${{ vars.CI_RUNNERS || 'ubuntu-latest' }}
+    permissions:
+      contents: read
+    steps:
+      - name: Cleanup Disk
+        if: vars.CI_RUNNERS == '' || vars.CI_RUNNERS == 'ubuntu-latest'
+        uses: jlumbroso/free-disk-space@v1.3.1
+        with:
+          android: true
+          dotnet: true
+          haskell: true
+          tool-cache: true
+          large-packages: false
+          swap-storage: false
+      - name: Cleanup docker cache
+        if: vars.CI_RUNNERS == '' || vars.CI_RUNNERS == 'ubuntu-latest'
+        run: |
+          docker system prune -a -f
+      - name: Checkout plugin-barman-cloud
+        uses: actions/checkout@v7.0.1
+        with:
+          fetch-depth: 0
+          ref: ${{ github.event.pull_request.head.sha }}
+      - name: Checkout CloudNativePG
+        uses: actions/checkout@v7.0.1
+        with:
+          repository: cloudnative-pg/cloudnative-pg
+          path: cloudnativepg
+          fetch-depth: 0
+      - name: Install Task
+        uses: arduino/setup-task@v3.0.0
+      - name: Install Dagger
+        env:
+          # renovate: datasource=github-tags depName=dagger/dagger versioning=semver
+          DAGGER_VERSION: 0.21.8
+        run: |
+          curl -L https://dl.dagger.io/dagger/install.sh | BIN_DIR=$HOME/.local/bin sh
+      - name: Setup Go
+        uses: actions/setup-go@v5
+        with:
+          go-version-file: cloudnativepg/go.mod
+      - name: Start Kind cluster
+        id: kind-cluster
+        working-directory: cloudnativepg
+        run: |
+          hack/setup-cluster.sh create load deploy
+          CLUSTERS=$(kind get clusters)
+          echo "clusters=$CLUSTERS" >> "$GITHUB_OUTPUT"
+      - name: Run integration tests
+        env:
+          KIND_CLUSTER_NAME: ${{ steps.kind-cluster.outputs.clusters }}
+        run: |
+          task integration:e2e

.github/workflows/release-please.yml

@@ -39,8 +39,8 @@ jobs:
           REGISTRY_USER: ${{ github.actor }}
           REGISTRY_PASSWORD: ${{ secrets.GITHUB_TOKEN }}
         run: |
-          task publish
+          task core:publish
-          task manifest
+          task core:manifest
       - name: Attach manifest to workflow run
         uses: actions/upload-artifact@v7
         with:

.github/workflows/release-publish.yml

@@ -29,10 +29,10 @@ jobs:
           REGISTRY_USER: ${{ github.actor }}
           REGISTRY_PASSWORD: ${{ secrets.GITHUB_TOKEN }}
         run: |
-          task publish
+          task core:publish
-          task manifest
+          task core:manifest
       - name: Attach manifest to release
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: |
-          task upload-manifest-to-release
+          task core:upload-manifest-to-release

Makefile

@@ -1,200 +0,0 @@
-# Image URL to use all building/pushing image targets
-IMG ?= plugin-barman-cloud:latest
-# ENVTEST_K8S_VERSION refers to the version of kubebuilder assets to be downloaded by envtest binary.
-ENVTEST_K8S_VERSION = 1.31.0
-
-# Get the currently used golang install path (in GOPATH/bin, unless GOBIN is set)
-ifeq (,$(shell go env GOBIN))
-GOBIN=$(shell go env GOPATH)/bin
-else
-GOBIN=$(shell go env GOBIN)
-endif
-
-# CONTAINER_TOOL defines the container tool to be used for building images.
-# Be aware that the target commands are only tested with Docker which is
-# scaffolded by default. However, you might want to replace it to use other
-# tools. (i.e. podman)
-CONTAINER_TOOL ?= docker
-
-# Setting SHELL to bash allows bash commands to be executed by recipes.
-# Options are set to exit when a recipe line exits non-zero or a piped command fails.
-SHELL = /usr/bin/env bash -o pipefail
-.SHELLFLAGS = -ec
-
-.PHONY: all
-all: build
-
-##@ General
-
-# The help target prints out all targets with their descriptions organized
-# beneath their categories. The categories are represented by '##@' and the
-# target descriptions by '##'. The awk command is responsible for reading the
-# entire set of makefiles included in this invocation, looking for lines of the
-# file as xyz: ## something, and then pretty-format the target and help. Then,
-# if there's a line with ##@ something, that gets pretty-printed as a category.
-# More info on the usage of ANSI control characters for terminal formatting:
-# https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_parameters
-# More info on the awk command:
-# http://linuxcommand.org/lc3_adv_awk.php
-
-.PHONY: help
-help: ## Display this help.
-	@awk 'BEGIN {FS = ":.*##"; printf "\nUsage:\n  make \033[36m<target>\033[0m\n"} /^[a-zA-Z_0-9-]+:.*?##/ { printf "  \033[36m%-15s\033[0m %s\n", $$1, $$2 } /^##@/ { printf "\n\033[1m%s\033[0m\n", substr($$0, 5) } ' $(MAKEFILE_LIST)
-
-##@ Development
-
-.PHONY: manifests
-manifests: controller-gen ## Generate WebhookConfiguration, ClusterRole and CustomResourceDefinition objects.
-	$(CONTROLLER_GEN) rbac:roleName=plugin-barman-cloud crd webhook paths="./api/..." paths="./internal/controller/..." output:crd:artifacts:config=config/crd/bases
-
-.PHONY: generate
-generate: controller-gen ## Generate code containing DeepCopy, DeepCopyInto, and DeepCopyObject method implementations.
-	$(CONTROLLER_GEN) object:headerFile="hack/boilerplate.go.txt" paths="./api/..."
-
-.PHONY: fmt
-fmt: ## Run go fmt against code.
-	go fmt ./...
-
-.PHONY: vet
-vet: ## Run go vet against code.
-	go vet ./...
-
-.PHONY: test
-test: manifests generate fmt vet envtest ## Run tests.
-	KUBEBUILDER_ASSETS="$(shell $(ENVTEST) use $(ENVTEST_K8S_VERSION) --bin-dir $(LOCALBIN) -p path)" go test $$(go list ./... | grep -v /e2e) -coverprofile cover.out
-
-# Utilize Kind or modify the e2e tests to load the image locally, enabling compatibility with other vendors.
-.PHONY: test-e2e  # Run the e2e tests against a Kind k8s instance that is spun up.
-test-e2e:
-	go test ./test/e2e/ -v -ginkgo.v
-
-.PHONY: lint
-lint: golangci-lint ## Run golangci-lint linter
-	$(GOLANGCI_LINT) run
-
-.PHONY: lint-fix
-lint-fix: golangci-lint ## Run golangci-lint linter and perform fixes
-	$(GOLANGCI_LINT) run --fix
-
-##@ Build
-
-.PHONY: build
-build: manifests generate fmt vet ## Build manager binary.
-	go build -o bin/manager cmd/main.go
-
-.PHONY: run
-run: manifests generate fmt vet ## Run a controller from your host.
-	go run ./cmd/main.go
-
-# If you wish to build the manager image targeting other platforms you can use the --platform flag.
-# (i.e. docker build --platform linux/arm64). However, you must enable docker buildKit for it.
-# More info: https://docs.docker.com/develop/develop-images/build_enhancements/
-.PHONY: docker-build
-docker-build: ## Build docker image with the manager.
-	$(CONTAINER_TOOL) build -t ${IMG} .
-
-.PHONY: docker-push
-docker-push: ## Push docker image with the manager.
-	$(CONTAINER_TOOL) push ${IMG}
-
-# PLATFORMS defines the target platforms for the manager image be built to provide support to multiple
-# architectures. (i.e. make docker-buildx IMG=myregistry/mypoperator:0.0.1). To use this option you need to:
-# - be able to use docker buildx. More info: https://docs.docker.com/build/buildx/
-# - have enabled BuildKit. More info: https://docs.docker.com/develop/develop-images/build_enhancements/
-# - be able to push the image to your registry (i.e. if you do not set a valid value via IMG=<myregistry/image:<tag>> then the export will fail)
-# To adequately provide solutions that are compatible with multiple platforms, you should consider using this option.
-PLATFORMS ?= linux/arm64,linux/amd64,linux/s390x,linux/ppc64le
-.PHONY: docker-buildx
-docker-buildx: ## Build and push docker image for the manager for cross-platform support
-	# copy existing Dockerfile and insert --platform=${BUILDPLATFORM} into Dockerfile.cross, and preserve the original Dockerfile
-	sed -e '1 s/\(^FROM\)/FROM --platform=\$$\{BUILDPLATFORM\}/; t' -e ' 1,// s//FROM --platform=\$$\{BUILDPLATFORM\}/' Dockerfile > Dockerfile.cross
-	- $(CONTAINER_TOOL) buildx create --name plugin-barman-cloud-builder
-	$(CONTAINER_TOOL) buildx use plugin-barman-cloud-builder
-	- $(CONTAINER_TOOL) buildx build --push --platform=$(PLATFORMS) --tag ${IMG} -f Dockerfile.cross .
-	- $(CONTAINER_TOOL) buildx rm plugin-barman-cloud-builder
-	rm Dockerfile.cross
-
-.PHONY: build-installer
-build-installer: manifests generate kustomize ## Generate a consolidated YAML with CRDs and deployment.
-	mkdir -p dist
-	cd config/manager && $(KUSTOMIZE) edit set image controller=${IMG}
-	$(KUSTOMIZE) build config/default > dist/install.yaml
-
-##@ Deployment
-
-ifndef ignore-not-found
-  ignore-not-found = false
-endif
-
-.PHONY: install
-install: manifests kustomize ## Install CRDs into the K8s cluster specified in ~/.kube/config.
-	$(KUSTOMIZE) build config/crd | $(KUBECTL) apply -f -
-
-.PHONY: uninstall
-uninstall: manifests kustomize ## Uninstall CRDs from the K8s cluster specified in ~/.kube/config. Call with ignore-not-found=true to ignore resource not found errors during deletion.
-	$(KUSTOMIZE) build config/crd | $(KUBECTL) delete --ignore-not-found=$(ignore-not-found) -f -
-
-.PHONY: deploy
-deploy: manifests kustomize ## Deploy controller to the K8s cluster specified in ~/.kube/config.
-	cd config/manager && $(KUSTOMIZE) edit set image controller=${IMG}
-	$(KUSTOMIZE) build config/default | $(KUBECTL) apply -f -
-
-.PHONY: undeploy
-undeploy: kustomize ## Undeploy controller from the K8s cluster specified in ~/.kube/config. Call with ignore-not-found=true to ignore resource not found errors during deletion.
-	$(KUSTOMIZE) build config/default | $(KUBECTL) delete --ignore-not-found=$(ignore-not-found) -f -
-
-##@ Dependencies
-
-## Location to install dependencies to
-LOCALBIN ?= $(shell pwd)/bin
-$(LOCALBIN):
-	mkdir -p $(LOCALBIN)
-
-## Tool Binaries
-KUBECTL ?= kubectl
-KUSTOMIZE ?= $(LOCALBIN)/kustomize
-CONTROLLER_GEN ?= $(LOCALBIN)/controller-gen
-ENVTEST ?= $(LOCALBIN)/setup-envtest
-GOLANGCI_LINT = $(LOCALBIN)/golangci-lint
-
-## Tool Versions
-KUSTOMIZE_VERSION ?= v5.4.3
-CONTROLLER_TOOLS_VERSION ?= v0.16.1
-ENVTEST_VERSION ?= release-0.19
-GOLANGCI_LINT_VERSION ?= v1.64.8
-
-.PHONY: kustomize
-kustomize: $(KUSTOMIZE) ## Download kustomize locally if necessary.
-$(KUSTOMIZE): $(LOCALBIN)
-	$(call go-install-tool,$(KUSTOMIZE),sigs.k8s.io/kustomize/kustomize/v5,$(KUSTOMIZE_VERSION))
-
-.PHONY: controller-gen
-controller-gen: $(CONTROLLER_GEN) ## Download controller-gen locally if necessary.
-$(CONTROLLER_GEN): $(LOCALBIN)
-	$(call go-install-tool,$(CONTROLLER_GEN),sigs.k8s.io/controller-tools/cmd/controller-gen,$(CONTROLLER_TOOLS_VERSION))
-
-.PHONY: envtest
-envtest: $(ENVTEST) ## Download setup-envtest locally if necessary.
-$(ENVTEST): $(LOCALBIN)
-	$(call go-install-tool,$(ENVTEST),sigs.k8s.io/controller-runtime/tools/setup-envtest,$(ENVTEST_VERSION))
-
-.PHONY: golangci-lint
-golangci-lint: $(GOLANGCI_LINT) ## Download golangci-lint locally if necessary.
-$(GOLANGCI_LINT): $(LOCALBIN)
-	$(call go-install-tool,$(GOLANGCI_LINT),github.com/golangci/golangci-lint/cmd/golangci-lint,$(GOLANGCI_LINT_VERSION))
-
-# go-install-tool will 'go install' any package with custom target and name of binary, if it doesn't exist
-# $1 - target path with name of binary
-# $2 - package url which can be installed
-# $3 - specific version of package
-define go-install-tool
-@[ -f "$(1)-$(3)" ] || { \
-set -e; \
-package=$(2)@$(3) ;\
-echo "Downloading $${package}" ;\
-rm -f $(1) || true ;\
-GOBIN=$(LOCALBIN) go install $${package} ;\
-mv $(1) $(1)-$(3) ;\
-} ;\
-ln -sf $(1)-$(3) $(1)
-endef

Taskfile.yml

@@ -12,18 +12,148 @@ vars:
   E2E_KUBERNETES_VERSION: v1.36.1
   E2E_CLUSTER_NAME: barman-cloud-plugin-e2e-{{.E2E_KUBERNETES_VERSION}}
   REGISTRY_NETWORK: barman-cloud-plugin
-  REGISTRY_NAME: registry.barman-cloud-plugin
+  REGISTRY_NAME: '{{ .REGISTRY_NAME | default "registry.dev" }}'
-  REGISTRY_PORT: 5000
+  REGISTRY_PORT: '{{ .REGISTRY_PORT | default 5000 }}'
+  GITHUB_REPOSITORY: '{{.GITHUB_REPOSITORY | default "cloudnative-pg/plugin-barman-cloud"}}'
   DAGGER_ENGINE_CONTAINER_NAME: e2e-dagger-engine
 
+
 tasks:
-  lint:
+
+  ####################################
+  ## ALL
+  ####################################
+
+  all:ci:
+    desc: Run the CI pipeline
+    deps:
+      - core:ci
+
+  ####################################
+  ## CORE
+  ####################################
+
+  core:ci:
+    desc: Run the CI core pipeline
+    deps:
+      - internal:spellcheck
+      - internal:commitlint
+      - internal:uncommitted
+      - internal:lint
+      - internal:go-test
+      - documentation:docusaurus-build-test
+      - documentation:docusaurus-version-is-aligned
+
+  # run the go linters
+  core:lint:
+    desc: Run the linters
+    deps:
+      - internal:lint
+
+    # run the go linters
+  core:uncommitted:
+    desc: Check for uncommitted changes
+    deps:
+      - internal:uncommitted
+
+    # run the spellcheck
+  core:spellcheck:
+    desc: Run the spellcheck
+    deps:
+      - internal:spellcheck
+
+  # Generate the manifest from the current branch
+  core:manifest:
+    desc: Generate the manifest to be uploaded to the release or as a workflow artifact
+    deps:
+      - internal:controller-gen
+    vars:
+      GITHUB_REPOSITORY: '{{.GITHUB_REPOSITORY | default "cloudnative-pg/plugin-barman-cloud"}}'
+      CURRENT_BRANCH:
+        sh: git rev-parse --abbrev-ref HEAD
+      GITHUB_REF: '{{.GITHUB_REF | default (printf "refs/heads/%s" .CURRENT_BRANCH)}}'
+      GITHUB_REF_NAME: '{{.GITHUB_REF_NAME | default .CURRENT_BRANCH}}'
+    cmds:
+      - task: internal:manifest
+        vars:
+          GITHUB_REPOSITORY: '{{.GITHUB_REPOSITORY}}'
+          GITHUB_REF: '{{.GITHUB_REF}}'
+          GITHUB_REF_NAME: '{{.GITHUB_REF_NAME}}'
+
+  core:go-test:
+    desc: Run the Go tests
+    deps:
+      - internal:go-test
+
+  core:publish:
+    desc: Publish the container images
+    requires:
+      # We expect this to run in a GitHub workflow, so we put a few GitHub-specific vars here
+      # to prevent running this task locally by accident.
+      vars:
+        - CI
+        - REGISTRY_USER
+        - REGISTRY_PASSWORD
+    vars:
+      GITHUB_REPOSITORY: '{{.GITHUB_REPOSITORY | default "cloudnative-pg/plugin-barman-cloud"}}'
+      CURRENT_BRANCH:
+        sh: git rev-parse --abbrev-ref HEAD
+      GITHUB_REF: '{{.GITHUB_REF | default (printf "refs/heads/%s" .CURRENT_BRANCH)}}'
+      GITHUB_REF_NAME: '{{.GITHUB_REF_NAME | default .CURRENT_BRANCH}}'
+    cmds:
+      - task: internal:publish
+        vars:
+          GITHUB_REPOSITORY: '{{.GITHUB_REPOSITORY}}'
+          GITHUB_REF: '{{.GITHUB_REF}}'
+          GITHUB_REF_NAME: '{{.GITHUB_REF_NAME}}'
+          REGISTRY_USER: '{{.REGISTRY_USER}}'
+          REGISTRY_PASSWORD: '{{.REGISTRY_PASSWORD}}'
+
+  core:upload-manifest-to-release:
+    desc: Upload the manifest to the release
+    requires:
+      # We expect this to run in a GitHub workflow, so we put a few GitHub-specific vars here
+      # to prevent running this task locally by accident.
+      vars:
+        - CI
+        - GITHUB_TOKEN
+    env:
+      # renovate: datasource=git-refs depName=gh lookupName=https://github.com/sagikazarmark/daggerverse
+      DAGGER_GH_SHA: ff27cd50f6b4eed2e3753c520632cd6099e1ce52
+    preconditions:
+      - sh: "[[ {{.GITHUB_REF}} =~ 'refs/tags/v.*' ]]"
+        msg: not a tag, failing
+    vars:
+      GITHUB_REPOSITORY: '{{.GITHUB_REPOSITORY | default "cloudnative-pg/plugin-barman-cloud"}}'
+      CURRENT_BRANCH:
+        sh: git rev-parse --abbrev-ref HEAD
+      GITHUB_REF: '{{.GITHUB_REF | default (printf "refs/heads/%s" .CURRENT_BRANCH)}}'
+      GITHUB_REF_NAME: '{{.GITHUB_REF_NAME | default .CURRENT_BRANCH}}'
+    cmds:
+        - >
+          GITHUB_REF= dagger -s call -m github.com/sagikazarmark/daggerverse/gh@${DAGGER_GH_SHA}
+          with-source --source .
+          run --repo {{.GITHUB_REPOSITORY}} --token env:GITHUB_TOKEN
+          --cmd "release upload {{.GITHUB_REF_NAME}} manifest.yaml"
+
+  core:build-images:
+    desc: Build the container images for the plugin
+    deps:
+      - internal:build-plugin-image
+      - internal:build-sidecar-image
+
+  ####################################
+  ## INTERNAL
+  ####################################
+
+  internal:lint:
     desc: Run golangci-lint
     env:
       # renovate: datasource=git-refs depName=golangci-lint lookupName=https://github.com/sagikazarmark/daggerverse currentValue=main
       DAGGER_GOLANGCI_LINT_SHA: ff27cd50f6b4eed2e3753c520632cd6099e1ce52
-      # renovate: datasource=docker depName=golangci/golangci-lint versioning=semver
+      # renovate: datasource=docker depName=golangci/golangci-lint versioning=docker
-      GOLANGCI_LINT_VERSION: v2.12.2
+      GOLANGCI_LINT_VERSION: v2.12.2@sha256:5cceeef04e53efe1470638d4b4b4f5ceefd574955ab3941b2d9a68a8c9ad5240
+    internal: true
     cmds:
       - >
         GITHUB_REF= dagger -sc "github.com/sagikazarmark/daggerverse/golangci-lint@${DAGGER_GOLANGCI_LINT_SHA}
@@ -32,21 +162,23 @@ tasks:
     sources:
       - ./**/*.go
 
-  wordlist-ordered:
+  internal:wordlist-ordered:
     desc: Order the word list file
+    internal: true
     cmds:
       - LANG=C LC_ALL=C sort .wordlist.txt > .wordlist.txt.new
       - mv -f .wordlist.txt.new .wordlist.txt
     sources:
       - .wordlist.txt
 
-  spellcheck:
+  internal:spellcheck:
     desc: Run spellcheck
     deps:
-      - wordlist-ordered
+      - internal:wordlist-ordered
     env:
       # renovate: datasource=git-refs depName=spellcheck lookupName=https://github.com/cloudnative-pg/daggerverse currentValue=main
       DAGGER_SPELLCHECK_SHA: 7174b66d283da487638a98b431b7707b311a9a32
+    internal: true
     cmds:
       - >
         GITHUB_REF= dagger -s call -m github.com/cloudnative-pg/daggerverse/spellcheck@${DAGGER_SPELLCHECK_SHA}
@@ -56,84 +188,44 @@ tasks:
       - .spellcheck.yaml
       - .wordlist.txt
 
-  commitlint:
+  internal:commitlint:
     desc: Check for conventional commits
     env:
       # renovate: datasource=git-refs depName=commitlint lookupName=https://github.com/cloudnative-pg/daggerverse currentValue=main
       DAGGER_COMMITLINT_SHA: 7174b66d283da487638a98b431b7707b311a9a32
+    internal: true
     cmds:
       - >
         GITHUB_REF= dagger -s call -m github.com/cloudnative-pg/daggerverse/commitlint@${DAGGER_COMMITLINT_SHA}
         lint --source . --args "--from=origin/main" stdout
 
-  uncommitted:
+  internal:uncommitted:
     desc: Check for uncommitted changes
     deps:
-      - manifest-main
+      - task: internal:manifest
-      - apidoc
+        vars:
-      - wordlist-ordered
+          GITHUB_REPOSITORY: cloudnative-pg/plugin-barman-cloud
+          GITHUB_REF: main
+          GITHUB_REF_NAME: main
+      - documentation:apidoc
+      - internal:wordlist-ordered
     env:
       # renovate: datasource=git-refs depName=uncommitted lookupName=https://github.com/cloudnative-pg/daggerverse currentValue=main
       DAGGER_UNCOMMITTED_SHA: 7174b66d283da487638a98b431b7707b311a9a32
+    internal: true
     cmds:
       - GITHUB_REF= dagger -s call -m github.com/cloudnative-pg/daggerverse/uncommitted@${DAGGER_UNCOMMITTED_SHA} check-uncommitted --source . stdout
     sources:
       - ./**
 
-  apidoc:
+  internal:go-test:
-    desc: Update the API Reference section of the documentation
-    deps:
-      - controller-gen
-    env:
-      # renovate: datasource=git-refs depName=crd-gen-refs lookupName=https://github.com/cloudnative-pg/daggerverse currentValue=main
-      DAGGER_CRDGENREF_SHA: 7174b66d283da487638a98b431b7707b311a9a32
-      # renovate: datasource=go depName=github.com/elastic/crd-ref-docs
-      CRDREFDOCS_VERSION: v0.3.0
-    cmds:
-      - >
-        GITHUB_REF= dagger -s call -m github.com/cloudnative-pg/daggerverse/crd-ref-docs@${DAGGER_CRDGENREF_SHA}
-        --version ${CRDREFDOCS_VERSION}
-        generate
-        --src .
-        --source-path api/v1
-        --config-file hack/crd-gen-refs/config.yaml
-        --renderer markdown
-        --templates-dir hack/crd-gen-refs/markdown
-        file --path out.md
-        export --path web/docs/plugin-barman-cloud.v1.md
-    sources:
-      - ./api/**/*.go
-      - ./hack/docs/crd-gen-refs/**/*
-      - ./Taskfile.yml
-
-  docusaurus-build-test:
-    desc: Check that the documentation builds
-    deps:
-    - apidoc
-    env:
-      # renovate: datasource=git-refs depName=docusaurus lookupName=https://github.com/levlaz/daggerverse currentValue=main
-      DAGGER_DOCUSAURUS_SHA: 93f57fccbd5afd22fa917107ab7697f3e7db0e5a
-    cmds:
-      - GITHUB_REF= dagger -s call -m github.com/levlaz/daggerverse/docusaurus@${DAGGER_DOCUSAURUS_SHA}
-        --src web --yarn build
-    src:
-      - ./web/**/*
-
-  docusaurus-version-is-aligned:
-    desc: Verify that a documentation version exists for the current version of the plugin
-    cmds:
-      - $(GITHUB_REF= dagger -s call -m dagger/check-doc-version has-version-documentation --src .)
-    src:
-      - .release-please-manifest.json
-      - ./web/versions.json
-
-  go-test:
     desc: Run go test
     env:
-      # renovate: datasource=git-refs depname=kubernetes packageName=https://github.com/kubernetes/kubernetes versioning=semver
+      # renovate: datasource=git-refs depName=kubernetes packageName=https://github.com/kubernetes/kubernetes versioning=semver
       K8S_VERSION: 1.31.0
       # renovate: datasource=git-refs depName=controller-runtime packageName=https://github.com/kubernetes-sigs/controller-runtime versioning=semver
       SETUP_ENVTEST_VERSION: 0.24.1
+    internal: true
     cmds:
       - >
         GITHUB_REF= dagger -s call -m ./dagger/gotest
@@ -145,11 +237,12 @@ tasks:
     sources:
       - ./**/*.go
 
-  generate-certs:
+  internal:generate-certs:
     desc: Generate certificates for the local registry
+    internal: true
     run: once
     cmds:
-      - > 
+      - >
           mkdir -p certs &&
           docker volume create certs &&
           docker run -v certs:/certs -w /certs --name certs --entrypoint=/bin/sh alpine/openssl -c '
@@ -168,20 +261,22 @@ tasks:
       - docker volume inspect certs
       - test -f certs/ca.pem
 
-  start-build-network:
+  internal:start-build-network:
     desc: Create a docker network for image building used by the dagger engine and the registry
     run: once
+    internal: true
     cmds:
       - docker network create {{ .REGISTRY_NETWORK}}
     status:
       - docker network inspect {{ .REGISTRY_NETWORK }}
 
-  start-registry:
+  internal:start-registry:
     desc: Start a container registry
     run: once
+    internal: true
     deps:
-      - generate-certs
+      - internal:generate-certs
-      - start-build-network
+      - internal:start-build-network
     env:
       # renovate: datasource=docker depName=registry versioning=semver
       REGISTRY_VERSION: 2
@@ -196,160 +291,47 @@ tasks:
     status:
       - \[ "$(docker inspect -f {{`'{{.State.Running}}'`}} "{{ .REGISTRY_NAME }}" 2> /dev/null )" == 'true' \]
 
-
+  internal:registry-network-connect:
-  # Start a dagger engine that mounts the CA certificate for the local registry.
+    desc: Make sure the registry is connected to the registry network
-  start-dagger-engine-for-local-builds:
+    summary: If we started the registry on our own, it should already be connected. However, if the registry was started
-    desc: Start a dagger engine mounting the CA
+      somewhere else, it may not be on the expected network.
-    run: once
+    internal: true
     deps:
-      - generate-certs
+      - internal:start-registry
-      - start-build-network
+    run: once
-    vars:
-      # renovate: datasource=github-tags depName=dagger/dagger versioning=semver
-      DAGGER_VERSION: 0.21.8
-      DAGGER_ENGINE_IMAGE: registry.dagger.io/engine:v{{ .DAGGER_VERSION }}
     cmds:
-      - >
+      - docker network connect {{ .REGISTRY_NETWORK }} {{ .REGISTRY_NAME }} || true
-        docker run -d -v /var/lib/dagger --name "{{ .DAGGER_ENGINE_CONTAINER_NAME }}"
-        --network={{ .REGISTRY_NETWORK }}
-        -v certs:/usr/local/share/ca-certificates/
-        --privileged {{ .DAGGER_ENGINE_IMAGE }}
     status:
-      - \[ "$(docker inspect -f {{`'{{.State.Running}}'`}} "{{ .DAGGER_ENGINE_CONTAINER_NAME }}" 2> /dev/null )" == 'true' \]
+      - docker network inspect {{ .REGISTRY_NETWORK }} -f '{{ range .Containers }}{{ .Name }} {{ end }}' | grep "{{ .REGISTRY_NAME }}"
 
   # We build an image and push it to a local registry.
   # The name is always `plugin-barman-cloud:testing`.
-  build-plugin-image:
+  internal:build-plugin-image:
-    desc: Build the operator container image for the plugin
+    desc: Build the operator container image for the plugin using the local Docker engine
+    internal: true
     deps:
-      - start-registry
+      - internal:registry-network-connect
-      - start-dagger-engine-for-local-builds
-    env:
-      # renovate: datasource=git-refs depName=docker lookupName=https://github.com/purpleclay/daggerverse currentValue=main
-      DAGGER_DOCKER_SHA: ee12c1a4a2630e194ec20c5a9959183e3a78c192
-      _EXPERIMENTAL_DAGGER_RUNNER_HOST: docker-container://{{ .DAGGER_ENGINE_CONTAINER_NAME }}
     cmds:
       - >
-        GITHUB_REF= dagger -s call -m github.com/purpleclay/daggerverse/docker@${DAGGER_DOCKER_SHA}
+        dagger run docker buildx build -f containers/Dockerfile.plugin --build-arg GO_VERSION={{.GO_VERSION}}
-        build --dir . --file containers/Dockerfile.plugin --args GO_VERSION={{.GO_VERSION}} --platform linux/amd64
+        --tag localhost:{{.REGISTRY_PORT}}/plugin-barman-cloud:testing --push .
-        publish --ref {{ .REGISTRY_NAME }}:{{ .REGISTRY_PORT }}/plugin-barman-cloud --tags testing
 
   # We build an image and push it to a local registry.
   # The name is always `sidecar-barman-cloud:testing`.
-  build-sidecar-image:
+  internal:build-sidecar-image:
-    desc: Build the sidecar container image for the plugin
+    desc: Build the sidecar container image for the plugin using the local Docker engine
+    internal: true
     deps:
-      - start-registry
+      - internal:registry-network-connect
-      - start-dagger-engine-for-local-builds
-    env:
-      # renovate: datasource=git-refs depName=docker lookupName=https://github.com/purpleclay/daggerverse currentValue=main
-      DAGGER_DOCKER_SHA: ee12c1a4a2630e194ec20c5a9959183e3a78c192
-      _EXPERIMENTAL_DAGGER_RUNNER_HOST: docker-container://{{ .DAGGER_ENGINE_CONTAINER_NAME }}
     cmds:
       - >
-        GITHUB_REF= dagger -s call -m github.com/purpleclay/daggerverse/docker@${DAGGER_DOCKER_SHA}
+        dagger run docker buildx build -f containers/Dockerfile.sidecar --build-arg GO_VERSION={{.GO_VERSION}}
-        build --dir . --file containers/Dockerfile.sidecar --args GO_VERSION={{.GO_VERSION}} --platform linux/amd64
+        --tag localhost:{{.REGISTRY_PORT}}/sidecar-barman-cloud:testing --push .
-        publish --ref {{ .REGISTRY_NAME }}:{{ .REGISTRY_PORT }}/sidecar-barman-cloud --tags testing
 
-  build-images:
+  internal:publish:
-    desc: Build the container images for the plugin
-    deps:
-      - build-plugin-image
-      - build-sidecar-image
-
-  # Install kind if not at the expected version.
-  install-kind:
-    desc: Install kind
-    run: once
-    vars:
-      # renovate: datasource=git-refs depName=kind lookupName=https://github.com/kubernetes-sigs/kind versioning=semver
-      KIND_VERSION: v0.32.0
-    cmds:
-      - go install sigs.k8s.io/kind@{{.KIND_VERSION}}
-      - kind version | grep -q {{.KIND_VERSION}}
-    status:
-        - kind version | grep -q {{.KIND_VERSION}}
-
-  start-kind-cluster:
-    desc: Start a kind cluster
-    deps:
-      - install-kind
-      - start-build-network
-      - generate-certs
-    run: once
-    cmds:
-      - >
-        kind create cluster --name {{ .E2E_CLUSTER_NAME }}
-        --image kindest/node:{{ .E2E_KUBERNETES_VERSION }}
-        --config hack/kind-config.yaml
-        --wait 5m
-      - >
-        for node in $(kind get nodes --name {{ .E2E_CLUSTER_NAME }} ); do
-          docker network connect {{ .REGISTRY_NETWORK }} $node;
-          docker exec $node sh -c "update-ca-certificates";
-        done
-    status:
-      - kind get clusters | grep -q {{ .E2E_CLUSTER_NAME }}
-
-  # TODO: see if it is possible to daggerize this. It will have to manage docker to make kind work.
-  # TODO: add a task to clean up the kind cluster for new test runs.
-  # Run the e2e tests. This task will start a kind cluster, deploy the plugin, and run the tests.
-  # Running the e2e tests requires:
-  # * The registry to have a valid TLS certificate.
-  # * The registry to be in the same network of the dagger-engine.
-  # * The dagger-engine to mount the CA.
-  # * The kind cluster to mount the CA.
-  e2e-external-kind:
-    desc: Run e2e tests in a local kind cluster
-    deps:
-      - build-images
-      - start-kind-cluster
-    vars:
-      KUBECONFIG_PATH:
-        sh: mktemp -t kubeconfig-XXXXX
-    env:
-      _EXPERIMENTAL_DAGGER_RUNNER_HOST: docker-container://{{ .DAGGER_ENGINE_CONTAINER_NAME }}
-    cmds:
-      - kind get kubeconfig --internal --name {{ .E2E_CLUSTER_NAME }} > {{ .KUBECONFIG_PATH }}
-      - >
-        GITHUB_REF= dagger call -m  dagger/e2e/ run
-        --source .
-        --kubeconfig {{.KUBECONFIG_PATH}}
-        --go-version {{.GO_VERSION}}
-
-  e2e-ephemeral:
-    desc: Run e2e tests in an ephemeral k3s cluster
-    deps:
-      - build-images
-    env:
-      _EXPERIMENTAL_DAGGER_RUNNER_HOST: docker-container://{{ .DAGGER_ENGINE_CONTAINER_NAME }}
-    cmds:
-      - >
-        GITHUB_REF= dagger call -m  dagger/e2e/ run-ephemeral
-        --source .
-        --ca certs/ca.pem
-        --registry {{.REGISTRY_NAME}}:{{.REGISTRY_PORT}}
-        --go-version {{.GO_VERSION}}
-
-  ci:
-    desc: Run the CI pipeline
-    deps:
-      - spellcheck
-      - commitlint
-      - uncommitted
-      - lint
-      - go-test
-      - e2e-ephemeral
-      - docusaurus-build-test
-      - docusaurus-version-is-aligned
-
-  publish:
     desc: Build and publish a container image for the plugin
     requires:
-      # We expect this to run in a GitHub workflow, so we put a few GitHub-specific vars here
-      # to prevent running this task locally by accident.
       vars:
-        - CI
         - GITHUB_REPOSITORY
         - GITHUB_REF
         - GITHUB_REF_NAME
@@ -366,6 +348,7 @@ tasks:
     env:
       # renovate: datasource=git-refs depName=docker lookupName=https://github.com/purpleclay/daggerverse currentValue=main
       DAGGER_DOCKER_SHA: ee12c1a4a2630e194ec20c5a9959183e3a78c192
+    internal: true
     cmds:
       - >
         GITHUB_REF= dagger call -m github.com/purpleclay/daggerverse/docker@${DAGGER_DOCKER_SHA}
@@ -378,12 +361,13 @@ tasks:
         build --dir . --file containers/Dockerfile.sidecar --args GO_VERSION={{.GO_VERSION}} --platform linux/amd64 --platform linux/arm64
         publish --ref {{.SIDECAR_IMAGE_NAME}} --tags {{.IMAGE_VERSION}}
 
-  controller-gen:
+  internal:controller-gen:
     desc: Run controller-gen
     run: once
     env:
       # renovate: datasource=git-refs depName=controller-gen lookupName=https://github.com/cloudnative-pg/daggerverse currentValue=main
       DAGGER_CONTROLLER_GEN_SHA: 7174b66d283da487638a98b431b7707b311a9a32
+    internal: true
     cmds:
       - >
         GITHUB_REF= dagger -s call -m github.com/cloudnative-pg/daggerverse/controller-gen@${DAGGER_CONTROLLER_GEN_SHA}
@@ -404,41 +388,7 @@ tasks:
       - ./config/rbac/role.yaml
       - ./config/crd/bases/*.yaml
 
-  manifest-main:
+  internal:manifest:
-    deps:
-      - controller-gen
-    desc: Generate the manifest for the main branch
-    vars:
-      GITHUB_REPOSITORY: cloudnative-pg/plugin-barman-cloud
-      GITHUB_REF: main
-      GITHUB_REF_NAME: main
-    cmds:
-      - task: manifest-internal
-        vars:
-          GITHUB_REPOSITORY: '{{.GITHUB_REPOSITORY}}'
-          GITHUB_REF: '{{.GITHUB_REF}}'
-          GITHUB_REF_NAME: '{{.GITHUB_REF_NAME}}'
-
-  manifest:
-    desc: Generate the manifest to be uploaded to the release or as a workflow artifact
-    deps:
-      - controller-gen
-    requires:
-      # We expect this to run in a GitHub workflow, so we put a few GitHub-specific vars here
-      # to prevent running this task locally by accident.
-      vars:
-        - CI
-        - GITHUB_REPOSITORY
-        - GITHUB_REF
-        - GITHUB_REF_NAME
-    cmds:
-      - task: manifest-internal
-        vars:
-          GITHUB_REPOSITORY: '{{.GITHUB_REPOSITORY}}'
-          GITHUB_REF: '{{.GITHUB_REF}}'
-          GITHUB_REF_NAME: '{{.GITHUB_REF_NAME}}'
-
-  manifest-internal:
     desc: Update the image in the Kustomization
     label: manifest-internal-{{.GITHUB_REF_NAME}}
     internal: true
@@ -474,31 +424,145 @@ tasks:
     generates:
       - ./manifest.yaml
 
-  upload-manifest-to-release:
+  internal:clean:
-    desc: Upload the manifest to the release
-    requires:
-      # We expect this to run in a GitHub workflow, so we put a few GitHub-specific vars here
-      # to prevent running this task locally by accident.
-      vars:
-        - CI
-        - GITHUB_REPOSITORY
-        - GITHUB_REF
-        - GITHUB_REF_NAME
-        - GITHUB_TOKEN
-    env:
-      # renovate: datasource=git-refs depName=gh lookupName=https://github.com/sagikazarmark/daggerverse
-      DAGGER_GH_SHA: ff27cd50f6b4eed2e3753c520632cd6099e1ce52
-    preconditions:
-      - sh: "[[ {{.GITHUB_REF}} =~ 'refs/tags/v.*' ]]"
-        msg: not a tag, failing
-    cmds:
-        - >
-            GITHUB_REF= dagger -s call -m github.com/sagikazarmark/daggerverse/gh@${DAGGER_GH_SHA}
-            with-source --source .
-            run --repo {{.GITHUB_REPOSITORY}} --token env:GITHUB_TOKEN
-            --cmd "release upload {{.GITHUB_REF_NAME}} manifest.yaml"
-
-  clean:
     desc: Remove autogenerated artifacts
+    internal: true
     cmds:
       - rm -rf .task/
+
+  ####################################
+  ## DOCUMENTATION
+  ####################################
+
+  documentation:apidoc:
+    desc: Update the API Reference section of the documentation
+    deps:
+      - internal:controller-gen
+    env:
+      # renovate: datasource=git-refs depName=crd-gen-refs lookupName=https://github.com/cloudnative-pg/daggerverse currentValue=main
+      DAGGER_CRDGENREF_SHA: 7174b66d283da487638a98b431b7707b311a9a32
+      # renovate: datasource=go depName=github.com/elastic/crd-ref-docs
+      CRDREFDOCS_VERSION: v0.3.0
+    cmds:
+      - >
+        GITHUB_REF= dagger -s call -m github.com/cloudnative-pg/daggerverse/crd-ref-docs@${DAGGER_CRDGENREF_SHA}
+        --version ${CRDREFDOCS_VERSION}
+        generate
+        --src .
+        --source-path api/v1
+        --config-file hack/crd-gen-refs/config.yaml
+        --renderer markdown
+        --templates-dir hack/crd-gen-refs/markdown
+        file --path out.md
+        export --path web/docs/plugin-barman-cloud.v1.md
+    sources:
+      - ./api/**/*.go
+      - ./hack/docs/crd-gen-refs/**/*
+      - ./Taskfile.yml
+
+  documentation:docusaurus-build-test:
+    desc: Check that the documentation builds
+    deps:
+    - documentation:apidoc
+    env:
+      # renovate: datasource=git-refs depName=docusaurus lookupName=https://github.com/levlaz/daggerverse currentValue=main
+      DAGGER_DOCUSAURUS_SHA: 93f57fccbd5afd22fa917107ab7697f3e7db0e5a
+    cmds:
+      - GITHUB_REF= dagger -s call -m github.com/levlaz/daggerverse/docusaurus@${DAGGER_DOCUSAURUS_SHA}
+        --src web --yarn build
+    sources:
+      - ./web/**/*
+
+  documentation:docusaurus-version-is-aligned:
+    desc: Verify that a documentation version exists for the current version of the plugin
+    cmds:
+      - $(GITHUB_REF= dagger -s call -m dagger/check-doc-version has-version-documentation --src .)
+    sources:
+      - .release-please-manifest.json
+      - ./web/versions.json
+
+
+  ####################################
+  ## integration
+  ####################################
+
+  # Deploy the plugin-barman-cloud to kind cluster
+  # To use KIND_CLUSTER_NAME=pg-operator-e2e-v1-33-1 task integration:deploy-to-kind
+  integration:deploy-to-kind:
+    desc: Deploy the operator on a kind cluster generated by the CNPG hack setup script
+    summary: |
+      Deploys the plugin-barman-cloud operator to a Kind cluster for integration testing. This task assumes a
+      Kind cluster has been previously created by the CloudNativePG hack/setup-cluster.sh script. It loads
+      the appropriate kubeconfig and applies the operator manifest via kustomize.
+    deps:
+      - internal:build-plugin-image
+      - internal:build-sidecar-image
+    run: once
+    requires:
+      vars:
+        - KIND_CLUSTER_NAME
+    vars:
+      KUBECONFIG_PATH:
+        sh: mktemp -t kubeconfig-XXXXX
+      KIND_HOSTPORT:
+        # This command extracts the host port for the control plane of the Kind cluster.
+        # Redundant curly braces are used to escape the template syntax in Taskfile.
+        sh: docker inspect --format '{{"{{"}} (index (index .HostConfig.PortBindings "6443/tcp") 0).HostPort {{"}}"}}' {{ .KIND_CLUSTER_NAME }}-control-plane
+      PLUGIN_IMAGE_REPOSITORY: '{{ .PLUGIN_IMAGE_REPOSITORY | default (printf "%s:%s/plugin-barman-cloud" .REGISTRY_NAME .REGISTRY_PORT) }}'
+      PLUGIN_IMAGE_TAG: '{{ .PLUGIN_IMAGE_TAG | default "testing" }}'
+      SIDECAR_IMAGE_REPOSITORY: '{{ .SIDECAR_IMAGE_REPOSITORY | default (printf "%s:%s/sidecar-barman-cloud" .REGISTRY_NAME .REGISTRY_PORT) }}'
+      SIDECAR_IMAGE_TAG: '{{ .SIDECAR_IMAGE_TAG | default "testing" }}'
+      # renovate: datasource=docker depName=alpine/k8s versioning=docker
+      ALPINE_K8S_VERSION: 1.36.2@sha256:44ef4942e171939b9c665a4a84beb80e2dcdb9a24330d4651cfdfd2e9deecc47
+      # renovate: datasource=github-releases depName=cert-manager/cert-manager versioning=semver
+      CERT_MANAGER_VERSION: v1.21.1
+      # Cache busting timestamp to prevent Dagger from caching the deployment steps
+      CACHE_BUST:
+        sh: date +%s
+    cmds:
+      - kind get kubeconfig --name {{ .KIND_CLUSTER_NAME }} > {{ .KUBECONFIG_PATH }}
+      - |
+        dagger shell << "."
+        container | from alpine/k8s:{{ .ALPINE_K8S_VERSION }} | with-mounted-file /kube/.config $(host | file {{ .KUBECONFIG_PATH }}) |
+        with-directory /src . |
+        with-env-variable KUBECONFIG /kube/.config |
+        with-service-binding localhost tcp://127.0.0.1:{{ .KIND_HOSTPORT }} |
+        with-exec -- sh -c "kubectl config set-cluster kind-{{ .KIND_CLUSTER_NAME }} --server=https://localhost:{{ .KIND_HOSTPORT }}" |
+        with-exec -- sh -c "kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/{{ .CERT_MANAGER_VERSION }}/cert-manager.yaml" |
+        with-exec -- sh -c "kubectl wait --for=condition=Available --timeout=120s -n cert-manager deployment --all" |
+        with-env-variable CACHE_BUST {{ .CACHE_BUST }} |
+        with-workdir /src/kubernetes |
+        with-exec -- sh -c "kustomize edit set image plugin-barman-cloud={{ .PLUGIN_IMAGE_REPOSITORY }}:{{ .PLUGIN_IMAGE_TAG }}" |
+        with-exec -- sh -c "kustomize edit set secret plugin-barman-cloud --from-literal=SIDECAR_IMAGE={{ .SIDECAR_IMAGE_REPOSITORY }}:{{ .SIDECAR_IMAGE_TAG }}" |
+        with-exec -- sh -c "kustomize build . | kubectl apply -f -"
+        .
+      - rm -f {{ .KUBECONFIG_PATH }}
+
+  integration:e2e:
+    desc: Run the e2e tests
+    deps:
+      - integration:deploy-to-kind
+    run: once
+    requires:
+      vars:
+        - KIND_CLUSTER_NAME
+    vars:
+      KUBECONFIG_PATH:
+        sh: mktemp -t kubeconfig-XXXXX
+      KIND_HOSTPORT:
+        # This command extracts the host port for the control plane of the Kind cluster.
+        # Redundant curly braces are used to escape the template syntax in Taskfile.
+        sh: docker inspect --format '{{"{{"}} (index (index .HostConfig.PortBindings "6443/tcp") 0).HostPort {{"}}"}}' {{ .KIND_CLUSTER_NAME }}-control-plane
+    cmds:
+      - kind get kubeconfig --name {{ .KIND_CLUSTER_NAME }} > {{ .KUBECONFIG_PATH }}
+      # kind writes the external server address as https://127.0.0.1:<port>, which is only valid on
+      # the host. Rewrite it to the "kubernetes" alias that --svc below binds inside the dagger container.
+      - >
+        sed -i.bak "s#server: https://[^:]*:[0-9]*#server: https://kubernetes:{{ .KIND_HOSTPORT }}#" {{ .KUBECONFIG_PATH }}
+      - >
+        GITHUB_REF= dagger call -m dagger/e2e/ run
+        --source .
+        --kubeconfig {{.KUBECONFIG_PATH}}
+        --svc tcp://127.0.0.1:{{.KIND_HOSTPORT}}
+        --go-version {{.GO_VERSION}}
+      - rm -f {{ .KUBECONFIG_PATH }} {{ .KUBECONFIG_PATH }}.bak

dagger/e2e/main.go

@@ -72,7 +72,7 @@ func (m *E2E) RunEphemeral(
 	source *dagger.Directory,
 	// registry is a private registry
 	// +optional
-	// +default="registry.barman-cloud-plugin:5000"
+	// +default="registry.dev:5000"
 	registry string,
 	// ca is the certificate authority for the registry
 	// +optional

test/e2e/e2e_suite_test.go

@@ -64,7 +64,7 @@ var _ = SynchronizedBeforeSuite(func(ctx SpecContext) []byte {
 		Images: []kustomizeTypes.Image{
 			{
 				Name:    "ghcr.io/cloudnative-pg/plugin-barman-cloud-testing",
-				NewName: "registry.barman-cloud-plugin:5000/plugin-barman-cloud",
+				NewName: "registry.dev:5000/plugin-barman-cloud",
 				NewTag:  "testing",
 			},
 		},
@@ -74,7 +74,7 @@ var _ = SynchronizedBeforeSuite(func(ctx SpecContext) []byte {
 					Name:     "plugin-barman-cloud",
 					Behavior: "replace",
 					KvPairSources: kustomizeTypes.KvPairSources{
-						LiteralSources: []string{"SIDECAR_IMAGE=registry.barman-cloud-plugin:5000/sidecar-barman-cloud:testing"},
+						LiteralSources: []string{"SIDECAR_IMAGE=registry.dev:5000/sidecar-barman-cloud:testing"},
 					},
 				},
 			},

test/e2e/internal/e2etestenv/main.go

@@ -98,7 +98,7 @@ func WithIgnoreExistingResources(ignore bool) SetupOption {
 
 func defaultSetupOptions() SetupOptions {
 	return SetupOptions{
-		CertManagerVersion: certmanager.DefaultVersion,
+		// CertManagerVersion: certmanager.DefaultVersion,
 	}
 }
 

web/versioned_docs/version-0.10.0/compression.md

@@ -1,43 +0,0 @@
----
-sidebar_position: 80
----
-
-# Compression
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-By default, backups and WAL files are archived **uncompressed**. However, the
-Barman Cloud Plugin supports multiple compression algorithms via
-`barman-cloud-backup` and `barman-cloud-wal-archive`, allowing you to optimize
-for space, speed, or a balance of both.
-
-### Supported Compression Algorithms
-
-- `bzip2`
-- `gzip`
-- `lz4` (WAL only)
-- `snappy`
-- `xz` (WAL only)
-- `zstd` (WAL only)
-
-Compression settings for base backups and WAL archives are configured
-independently. For implementation details, refer to the corresponding API
-definitions:
-
-- [`DataBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#DataBackupConfiguration)
-- [`WALBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#WalBackupConfiguration)
-
-:::important
-Compression impacts both performance and storage efficiency. Choose the right
-algorithm based on your recovery time objectives (RTO), storage capacity, and
-network throughput.
-:::
-
-## Compression Benchmark (on MinIO)
-
-| Compression | Backup Time (ms) | Restore Time (ms) | Uncompressed Size (MB) | Compressed Size (MB) | Ratio |
-| ----------- | ---------------- | ----------------- | ---------------------- | -------------------- | ----- |
-| None        | 10,927           | 7,553             | 395                    | 395                  | 1.0:1 |
-| bzip2       | 25,404           | 13,886            | 395                    | 67                   | 5.9:1 |
-| gzip        | 116,281          | 3,077             | 395                    | 91                   | 4.3:1 |
-| snappy      | 8,134            | 8,341             | 395                    | 166                  | 2.4:1 |

web/versioned_docs/version-0.10.0/concepts.md

@@ -1,177 +0,0 @@
----
-sidebar_position: 10
----
-
-# Main Concepts
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-:::important
-Before proceeding, make sure to review the following sections of the
-CloudNativePG documentation:
-
-- [**Backup**](https://cloudnative-pg.io/documentation/current/backup/)
-- [**WAL Archiving**](https://cloudnative-pg.io/documentation/current/wal_archiving/)
-- [**Recovery**](https://cloudnative-pg.io/documentation/current/recovery/)
-:::
-
-The **Barman Cloud Plugin** enables **hot (online) backups** of PostgreSQL
-clusters in CloudNativePG through [`barman-cloud`](https://pgbarman.org),
-supporting continuous physical backups and WAL archiving to an **object
-store**—without interrupting write operations.
-
-It also supports both **full recovery** and **Point-in-Time Recovery (PITR)**
-of a PostgreSQL cluster.
-
-## The Object Store
-
-At the core is the [`ObjectStore` custom resource (CRD)](plugin-barman-cloud.v1.md#objectstorespec),
-which acts as the interface between the PostgreSQL cluster and the target
-object storage system. It allows you to configure:
-
-- **Authentication and bucket location** via the `.spec.configuration` section
-- **WAL archiving** settings—such as compression type, parallelism, and
-  server-side encryption—under `.spec.configuration.wal`
-- **Base backup options**—with similar settings for compression, concurrency,
-  and encryption—under `.spec.configuration.data`
-- **Retention policies** to manage the life-cycle of archived WALs and backups
-  via `.spec.configuration.retentionPolicy`
-
-WAL files are archived in the `wals` directory, while base backups are stored
-as **tarballs** in the `base` directory, following the
-[Barman Cloud convention](https://docs.pgbarman.org/cloud/latest/usage/#object-store-layout).
-
-The plugin also offers advanced capabilities, including
-[backup tagging](misc.md#backup-object-tagging) and
-[extra options for backups and WAL archiving](misc.md#extra-options-for-backup-and-wal-archiving).
-
-:::tip
-For details, refer to the
-[API reference for the `ObjectStore` resource](plugin-barman-cloud.v1.md#objectstorespec).
-:::
-
-## Integration with a CloudNativePG Cluster
-
-CloudNativePG can delegate continuous backup and recovery responsibilities to
-the **Barman Cloud Plugin** by configuring the `.spec.plugins` section of a
-`Cluster` resource. This setup requires a corresponding `ObjectStore` resource
-to be defined.
-
-:::important
-While it is technically possible to reuse the same `ObjectStore` for multiple
-`Cluster` resources within the same namespace, it is strongly recommended to
-dedicate one object store per PostgreSQL cluster to ensure data isolation and
-operational clarity.
-:::
-
-The following example demonstrates how to configure a CloudNativePG cluster
-named `cluster-example` to use a previously defined `ObjectStore` (also named
-`cluster-example`) in the same namespace. Setting `isWALArchiver: true` enables
-WAL archiving through the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  # Other cluster settings...
-  plugins:
-    - name: barman-cloud.cloudnative-pg.io
-      isWALArchiver: true
-      parameters:
-        barmanObjectName: cluster-example
-```
-
-## Backup of a Postgres Cluster
-
-Once the object store is defined and the `Cluster` is configured to use the
-Barman Cloud Plugin, **WAL archiving is activated immediately** on the
-PostgreSQL primary.
-
-Physical base backups are seamlessly managed by CloudNativePG using the
-`Backup` and `ScheduledBackup` resources, respectively for
-[on-demand](https://cloudnative-pg.io/documentation/current/backup/#on-demand-backups)
-and
-[scheduled](https://cloudnative-pg.io/documentation/current/backup/#scheduled-backups)
-backups.
-
-To use the Barman Cloud Plugin, you must set the `method` to `plugin` and
-configure the `pluginConfiguration` section as shown:
-
-```yaml
-[...]
-spec:
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-  [...]
-```
-
-With this configuration, CloudNativePG supports:
-
-- Backups from both **primary** and **standby** instances
-- Backups from **designated primaries** in a distributed topology using
-  [replica clusters](https://cloudnative-pg.io/documentation/current/replica_cluster/)
-
-:::tip
-For details on how to back up from a standby, refer to the official documentation:
-[Backup from a standby](https://cloudnative-pg.io/documentation/current/backup/#backup-from-a-standby).
-:::
-
-:::important
-Both backup and WAL archiving operations are executed by sidecar containers
-running in the same pod as the PostgreSQL `Cluster` primary instance—except
-when backups are taken from a standby, in which case the sidecar runs alongside
-the standby pod.
-The sidecar containers use a [dedicated container image](images.md) that
-includes only the supported version of Barman Cloud.
-:::
-
-## Recovery of a Postgres Cluster
-
-In PostgreSQL, *recovery* refers to the process of starting a database instance
-from an existing backup.  The Barman Cloud Plugin integrates with CloudNativePG
-to support both **full recovery** and **Point-in-Time Recovery (PITR)** from an
-object store.
-
-Recovery in this context is *not in-place*: it bootstraps a brand-new
-PostgreSQL cluster from a backup and replays the necessary WAL files to reach
-the desired recovery target.
-
-To perform a recovery, define an *external cluster* that references the
-appropriate `ObjectStore`, and use it as the source in the `bootstrap` section
-of the target cluster:
-
-```yaml
-[...]
-spec:
-  [...]
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: cluster-example
-        serverName: cluster-example
-  [...]
-```
-
-The critical element here is the `externalClusters` section of the `Cluster`
-resource, where the `plugin` stanza instructs CloudNativePG to use the Barman
-Cloud Plugin to access the object store for recovery.
-
-This same mechanism can be used for a variety of scenarios enabled by the
-CloudNativePG API, including:
-
-* **Full cluster recovery** from the latest backup
-* **Point-in-Time Recovery (PITR)**
-* Bootstrapping **replica clusters** in a distributed topology
-
-:::tip
-For complete instructions and advanced use cases, refer to the official
-[Recovery documentation](https://cloudnative-pg.io/documentation/current/recovery/).
-:::

web/versioned_docs/version-0.10.0/images.md

@@ -1,37 +0,0 @@
----
-sidebar_position: 99
----
-
-# Container Images
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin is distributed using two container images:
-
-- One for deploying the plugin components
-- One for the sidecar that runs alongside each PostgreSQL instance in a
-  CloudNativePG `Cluster` using the plugin
-
-## Plugin Container Image
-
-The plugin image contains the logic required to operate the Barman Cloud Plugin
-within your Kubernetes environment with CloudNativePG. It is published on the
-GitHub Container Registry at `ghcr.io/cloudnative-pg/plugin-barman-cloud`.
-
-This image is built from the
-[`Dockerfile.plugin`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.plugin)
-in the plugin repository.
-
-## Sidecar Container Image
-
-The sidecar image is used within each PostgreSQL pod in the cluster. It
-includes the latest supported version of Barman Cloud and is responsible for
-performing WAL archiving and backups on behalf of CloudNativePG.
-
-It is available at `ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar` and is
-built from the
-[`Dockerfile.sidecar`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.sidecar).
-
-These sidecar images are designed to work seamlessly with the
-[`minimal` PostgreSQL container images](https://github.com/cloudnative-pg/postgres-containers?tab=readme-ov-file#minimal-images)
-maintained by the CloudNativePG Community.

web/versioned_docs/version-0.10.0/installation.mdx

@@ -1,109 +0,0 @@
----
-sidebar_position: 20
----
-
-# Installation
-
-:::important
-1. The plugin **must** be installed in the same namespace as the CloudNativePG
-   operator (typically `cnpg-system`).
-
-2. Keep in mind that the operator's **listening namespaces** may differ from its
-   installation namespace. Double-check this to avoid configuration issues.
-:::
-
-## Verifying the Requirements
-
-Before installing the plugin, make sure the [requirements](intro.md#requirements) are met.
-
-### CloudNativePG Version
-
-Ensure you're running a version of CloudNativePG that is compatible with the
-plugin. If installed in the default `cnpg-system` namespace, you can verify the
-version with:
-
-```sh
-kubectl get deployment -n cnpg-system cnpg-controller-manager \
-  -o jsonpath="{.spec.template.spec.containers[*].image}"
-```
-
-Example output:
-
-```output
-ghcr.io/cloudnative-pg/cloudnative-pg:1.26.0
-```
-
-The version **must be 1.26 or newer**.
-
-### cert-manager
-
-Use the [cmctl](https://cert-manager.io/docs/reference/cmctl/#installation)
-tool to confirm that `cert-manager` is installed and available:
-
-```sh
-cmctl check api
-```
-
-Example output:
-
-```output
-The cert-manager API is ready
-```
-
-Both checks are required before proceeding with the installation.
-
-## Installing the Barman Cloud Plugin
-
-import { InstallationSnippet } from '@site/src/components/Installation';
-
-Install the plugin using `kubectl` by applying the manifest for the latest
-release:
-
-<InstallationSnippet />
-
-Example output:
-
-```output
-customresourcedefinition.apiextensions.k8s.io/objectstores.barmancloud.cnpg.io created
-serviceaccount/plugin-barman-cloud created
-role.rbac.authorization.k8s.io/leader-election-role created
-clusterrole.rbac.authorization.k8s.io/metrics-auth-role created
-clusterrole.rbac.authorization.k8s.io/metrics-reader created
-clusterrole.rbac.authorization.k8s.io/objectstore-editor-role created
-clusterrole.rbac.authorization.k8s.io/objectstore-viewer-role created
-clusterrole.rbac.authorization.k8s.io/plugin-barman-cloud created
-rolebinding.rbac.authorization.k8s.io/leader-election-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/metrics-auth-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/plugin-barman-cloud-binding created
-secret/plugin-barman-cloud-8tfddg42gf created
-service/barman-cloud created
-deployment.apps/barman-cloud configured
-certificate.cert-manager.io/barman-cloud-client created
-certificate.cert-manager.io/barman-cloud-server created
-issuer.cert-manager.io/selfsigned-issuer created
-```
-
-Finally, check that the deployment is up and running:
-
-```sh
-kubectl rollout status deployment \
-  -n cnpg-system barman-cloud
-```
-
-Example output:
-
-```output
-deployment "barman-cloud" successfully rolled out
-```
-
-This confirms that the plugin is deployed and ready to use.
-
-## Testing the latest development snapshot
-
-You can also test the latest development snapshot of the plugin with the
-following command:
-
-```sh
-kubectl apply -f \
-  https://raw.githubusercontent.com/cloudnative-pg/plugin-barman-cloud/refs/heads/main/manifest.yaml
-```

web/versioned_docs/version-0.10.0/intro.md

@@ -1,86 +0,0 @@
----
-sidebar_position: 1
-sidebar_label: "Introduction"
----
-
-# Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The **Barman Cloud Plugin** for [CloudNativePG](https://cloudnative-pg.io/)
-enables online continuous physical backups of PostgreSQL clusters to object storage
-using the `barman-cloud` suite from the [Barman](https://docs.pgbarman.org/release/latest/)
-project.
-
-:::important
-If you plan to migrate your existing CloudNativePG cluster to the new
-plugin-based approach using the Barman Cloud Plugin, see
-["Migrating from Built-in CloudNativePG Backup"](migration.md)
-for detailed instructions.
-:::
-
-## Requirements
-
-Before using the Barman Cloud Plugin, ensure that the following components are
-installed and properly configured:
-
-- [CloudNativePG](https://cloudnative-pg.io) version 1.26 or later
-
-  - We strongly recommend version 1.27.0 or later, which includes improved
-    error handling and status reporting for the plugin.
-  - If you are running an earlier release, refer to the
-    [upgrade guide](https://cloudnative-pg.io/documentation/current/installation_upgrade).
-
-- [cert-manager](https://cert-manager.io/)
-
-  - The recommended way to enable secure TLS communication between the plugin
-    and the operator.
-  - Alternatively, you can provide your own certificate bundles. See the
-    [CloudNativePG documentation on TLS configuration](https://cloudnative-pg.io/documentation/current/cnpg_i/#configuring-tls-certificates).
-
-- [`kubectl-cnpg`](https://cloudnative-pg.io/documentation/current/kubectl-plugin/)
-  plugin (optional but recommended)
-
-  - Simplifies debugging and monitoring with additional status and inspection
-    commands.
-  - Multiple installation options are available in the
-    [installation guide](https://cloudnative-pg.io/documentation/current/kubectl-plugin/#install).
-
-## Key Features
-
-This plugin provides the following capabilities:
-
-- Physical online backup of the data directory
-- Physical restore of the data directory
-- Write-Ahead Log (WAL) archiving
-- WAL restore
-- Full cluster recovery
-- Point-in-Time Recovery (PITR)
-- Seamless integration with replica clusters for bootstrap and WAL restore from archive
-
-:::important
-The Barman Cloud Plugin is designed to **replace the in-tree object storage support**
-previously provided via the `.spec.backup.barmanObjectStore` section in the
-`Cluster` resource.
-Backups created using the in-tree approach are fully supported and compatible
-with this plugin.
-:::
-
-## Supported Object Storage Providers
-
-The plugin works with all storage backends supported by `barman-cloud`, including:
-
-- **Amazon S3**
-- **Google Cloud Storage**
-- **Microsoft Azure Blob Storage**
-
-In addition, the following S3-compatible and simulator solutions have been
-tested and verified:
-
-- [MinIO](https://min.io/) – An S3-compatible storage solution
-- [Azurite](https://github.com/Azure/Azurite) – A simulator for Azure Blob Storage
-- [fake-gcs-server](https://github.com/fsouza/fake-gcs-server) – A simulator for Google Cloud Storage
-
-:::tip
-For more details, refer to [Object Store Providers](object_stores.md).
-:::

web/versioned_docs/version-0.10.0/migration.md

@@ -1,274 +0,0 @@
----
-sidebar_position: 40
----
-
-# Migrating from Built-in CloudNativePG Backup
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The in-tree support for Barman Cloud in CloudNativePG is **deprecated starting
-from version 1.26** and will be removed in a future release.
-
-If you're currently relying on the built-in Barman Cloud integration, you can
-migrate seamlessly to the new **plugin-based architecture** using the Barman
-Cloud Plugin, without data loss. Follow these steps:
-
-- [Install the Barman Cloud Plugin](installation.mdx)
-- Create an `ObjectStore` resource by translating the contents of the
-  `.spec.backup.barmanObjectStore` section from your existing `Cluster`
-  definition
-- Modify the `Cluster` resource in a single atomic change to switch from
-  in-tree backup to the plugin
-- Update any `ScheduledBackup` resources to use the plugin
-- Update the `externalClusters` configuration, where applicable
-
-:::tip
-For a working example, refer to [this commit](https://github.com/cloudnative-pg/cnpg-playground/commit/596f30e252896edf8f734991c3538df87630f6f7)
-from the [CloudNativePG Playground project](https://github.com/cloudnative-pg/cnpg-playground),
-which demonstrates a full migration.
-:::
-
----
-
-## Step 1: Define the `ObjectStore`
-
-Begin by creating an `ObjectStore` resource in the same namespace as your
-PostgreSQL `Cluster`.
-
-There is a **direct mapping** between the `.spec.backup.barmanObjectStore`
-section in CloudNativePG and the `.spec.configuration` field in the
-`ObjectStore` CR. The conversion is mostly mechanical, with one key difference:
-
-:::warning
-In the plugin architecture, retention policies are defined as part of the `ObjectStore`.
-In contrast, the in-tree implementation defined them at the `Cluster` level.
-:::
-
-If your `Cluster` used `.spec.backup.retentionPolicy`, move that configuration
-to `.spec.retentionPolicy` in the `ObjectStore`.
-
----
-
-### Example
-
-Here’s an excerpt from a traditional in-tree CloudNativePG backup configuration
-taken from the CloudNativePG Playground project:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-eu
-spec:
-  # [...]
-  backup:
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-This configuration translates to the following `ObjectStore` resource for the
-plugin:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-As you can see, the contents of `barmanObjectStore` have been copied directly
-under the `configuration` field of the `ObjectStore` resource, using the same
-secret references.
-
-## Step 2: Update the `Cluster` for plugin WAL archiving
-
-Once the `ObjectStore` resource is in place, update the `Cluster` resource as
-follows in a single atomic change:
-
-- Remove the `.spec.backup.barmanObjectStore` section
-- Remove `.spec.backup.retentionPolicy` if it was defined (as it is now in the
-  `ObjectStore`)
-- Remove the entire `spec.backup` section if it is now empty
-- Add `barman-cloud.cloudnative-pg.io` to the `plugins` list, as described in
-  [Configuring WAL archiving](usage.md#configuring-wal-archiving)
-
-This will trigger a rolling update of the `Cluster`, switching continuous
-backup from the in-tree implementation to the plugin-based approach.
-
-### Example
-
-The updated `pg-eu` cluster will have this configuration instead of the
-previous `backup` section:
-
-```yaml
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-eu
-```
-
----
-
-## Step 3: Update the `ScheduledBackup`
-
-After switching the `Cluster` to use the plugin, update your `ScheduledBackup`
-resources to match.
-
-Set the backup `method` to `plugin` and reference the plugin name via
-`pluginConfiguration`, as shown in ["Performing a base backup"](usage.md#performing-a-base-backup).
-
-### Example
-
-Original in-tree `ScheduledBackup`:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-```
-
-Updated version using the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
----
-
-## Step 4: Update the `externalClusters` configuration
-
-If your `Cluster` relies on one or more external clusters that use the in-tree
-Barman Cloud integration, you need to update those configurations to use the
-plugin-based architecture.
-
-When a replica cluster fetches WAL files or base backups from an external
-source that used the built-in backup method, follow these steps:
-
-1. Create a corresponding `ObjectStore` resource for the external cluster, as
-   shown in [Step 1](#step-1-define-the-objectstore)
-2. Update the `externalClusters` section of your replica cluster to use the
-   plugin instead of the in-tree `barmanObjectStore` field
-
-### Example
-
-Consider the original configuration using in-tree Barman Cloud:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      serverName: pg-eu
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-Create the `ObjectStore` resource for the external cluster:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-    accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-    secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-Update the external cluster configuration to use the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-eu
-        serverName: pg-eu
-```
-
-## Step 5: Verify your metrics
-
-When migrating from the in-core solution to the plugin-based approach, you need
-to monitor a different set of metrics, as described in the
-["Observability"](observability.md) section.
-
-The table below summarizes the name changes between the old in-core metrics and
-the new plugin-based ones:
-
-| Old metric name                                  | New metric name                                                  |
-| ------------------------------------------------ | ---------------------------------------------------------------- |
-| `cnpg_collector_last_failed_backup_timestamp`    | `barman_cloud_cloudnative_pg_io_last_failed_backup_timestamp`    |
-| `cnpg_collector_last_available_backup_timestamp` | `barman_cloud_cloudnative_pg_io_last_available_backup_timestamp` |
-| `cnpg_collector_first_recoverability_point`      | `barman_cloud_cloudnative_pg_io_first_recoverability_point`      |

web/versioned_docs/version-0.10.0/misc.md

@@ -1,97 +0,0 @@
----
-sidebar_position: 90
----
-
-# Miscellaneous
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-## Backup Object Tagging
-
-You can attach key-value metadata tags to backup artifacts—such as base
-backups, WAL files, and history files—via the `.spec.configuration` section of
-the `ObjectStore` resource.
-
-- `tags`: applied to base backups and WAL files
-- `historyTags`: applied to history files only
-
-### Example
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    [...]
-    tags:
-      backupRetentionPolicy: "expire"
-    historyTags:
-      backupRetentionPolicy: "keep"
-  [...]
-```
-
-## Extra Options for Backup and WAL Archiving
-
-You can pass additional command-line arguments to `barman-cloud-backup` and
-`barman-cloud-wal-archive` using the `additionalCommandArgs` field in the
-`ObjectStore` configuration.
-
-- `.spec.configuration.data.additionalCommandArgs`: for `barman-cloud-backup`
-- `.spec.configuration.wal.archiveAdditionalCommandArgs`: for `barman-cloud-wal-archive`
-
-Each field accepts a list of string arguments. If an argument is already
-configured elsewhere in the plugin, the duplicate will be ignored.
-
-### Example: Extra Backup Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    data:
-      additionalCommandArgs:
-        - "--min-chunk-size=5MB"
-        - "--read-timeout=60"
-```
-
-### Example: Extra WAL Archive Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    wal:
-      archiveAdditionalCommandArgs:
-        - "--max-concurrency=1"
-        - "--read-timeout=60"
-```
-
-For a complete list of supported options, refer to the
-[official Barman Cloud documentation](https://docs.pgbarman.org/release/latest/).
-
-## Enable the pprof debug server for the sidecar
-
-You can enable the instance sidecar's pprof debug HTTP server by adding the `--pprof-server=<address>` flag to the container's
-arguments via `.spec.instanceSidecarConfiguration.additionalContainerArgs`.
-
-Pass a bind address in the form `<host>:<port>` (for example, `0.0.0.0:6061`).
-An empty value disables the server (disabled by default).
-
-### Example
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  instanceSidecarConfiguration:
-    additionalContainerArgs:
-      - "--pprof-server=0.0.0.0:6061"
-```

web/versioned_docs/version-0.10.0/object_stores.md

@@ -1,454 +0,0 @@
----
-sidebar_position: 50
----
-
-# Object Store Providers
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin enables the storage of PostgreSQL cluster backup files
-in any object storage service supported by the
-[Barman Cloud infrastructure](https://docs.pgbarman.org/release/latest/).
-
-Currently, Barman Cloud supports the following providers:
-
-- [Amazon S3](#aws-s3)
-- [Microsoft Azure Blob Storage](#azure-blob-storage)
-- [Google Cloud Storage](#google-cloud-storage)
-
-You may also use any S3- or Azure-compatible implementation of the above
-services.
-
-To configure object storage with Barman Cloud, you must define an
-[`ObjectStore` object](plugin-barman-cloud.v1.md#objectstore), which
-establishes the connection between your PostgreSQL cluster and the object
-storage backend.
-
-Configuration details — particularly around authentication — will vary depending on
-the specific object storage provider you are using.
-
-The following sections detail the setup for each.
-
----
-
-## AWS S3
-
-[AWS Simple Storage Service (S3)](https://aws.amazon.com/s3/) is one of the
-most widely adopted object storage solutions.
-
-The Barman Cloud plugin for CloudNativePG integrates with S3 through two
-primary authentication mechanisms:
-
-- [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) —
-  recommended for clusters running on EKS
-- Access keys — using `ACCESS_KEY_ID` and `ACCESS_SECRET_KEY` credentials
-
-### Access Keys
-
-To authenticate using access keys, you’ll need:
-
-- `ACCESS_KEY_ID`: the public key used to authenticate to S3
-- `ACCESS_SECRET_KEY`: the corresponding secret key
-- `ACCESS_SESSION_TOKEN`: (optional) a temporary session token, if required
-
-These credentials must be stored securely in a Kubernetes secret:
-
-```sh
-kubectl create secret generic aws-creds \
-  --from-literal=ACCESS_KEY_ID=<access key here> \
-  --from-literal=ACCESS_SECRET_KEY=<secret key here>
-# --from-literal=ACCESS_SESSION_TOKEN=<session token here> # if required
-```
-
-The credentials will be encrypted at rest if your Kubernetes environment
-supports it.
-
-You can then reference the secret in your `ObjectStore` definition:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: aws-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    s3Credentials:
-      accessKeyId:
-        name: aws-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: aws-creds
-        key: ACCESS_SECRET_KEY
-  [...]
-```
-
-### IAM Role for Service Account (IRSA)
-
-To use IRSA with EKS, configure the service account of the PostgreSQL cluster
-with the appropriate annotation:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  [...]
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        eks.amazonaws.com/role-arn: arn:[...]
-        [...]
-```
-
-### S3 Lifecycle Policy
-
-Barman Cloud uploads backup files to S3 but does not modify them afterward.
-To enhance data durability and protect against accidental or malicious loss,
-it's recommended to implement the following best practices:
-
-- Enable object versioning
-- Enable object locking to prevent objects from being deleted or overwritten
-  for a defined period or indefinitely (this provides an additional layer of
-  protection against accidental deletion and ransomware attacks)
-- Set lifecycle rules to expire current versions a few days after your Barman
-  retention window
-- Expire non-current versions after a longer period
-
-These strategies help you safeguard backups without requiring broad delete
-permissions, ensuring both security and compliance with minimal operational
-overhead.
-
-
-### S3-Compatible Storage Providers
-
-You can use S3-compatible services like **MinIO**, **Linode (Akamai) Object Storage**,
-or **DigitalOcean Spaces** by specifying a custom `endpointURL`.
-
-Example with Linode (Akamai) Object Storage (`us-east1`):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: linode-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/"
-    endpointURL: "https://us-east1.linodeobjects.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-Recent changes to the [boto3 implementation](https://github.com/boto/boto3/issues/4392)
-of [Amazon S3 Data Integrity Protections](https://docs.aws.amazon.com/sdkref/latest/guide/feature-dataintegrity.html)
-may lead to the `x-amz-content-sha256` error when using the Barman Cloud
-Plugin.
-
-If you encounter this issue (see [GitHub issue #393](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/393)),
-you can apply the following workaround by setting specific environment
-variables in the `ObjectStore` resource:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: linode-store
-spec:
-  instanceSidecarConfiguration:
-    env:
-      - name: AWS_REQUEST_CHECKSUM_CALCULATION
-        value: when_required
-      - name: AWS_RESPONSE_CHECKSUM_VALIDATION
-        value: when_required
-  [...]
-```
-
-These settings ensure that checksum calculations and validations are only
-applied when explicitly required, avoiding compatibility issues with certain
-S3-compatible storage providers.
-
-Example with DigitalOcean Spaces (SFO3, path-style):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: digitalocean-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    endpointURL: "https://sfo3.digitaloceanspaces.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-### Using Object Storage with a Private CA
-
-For object storage services (e.g., MinIO) that use HTTPS with certificates
-signed by a private CA, set the `endpointCA` field in the `ObjectStore`
-definition. Unless you already have it, create a Kubernetes `Secret` with the
-CA bundle:
-
-```sh
-kubectl create secret generic my-ca-secret --from-file=ca.crt
-```
-
-Then reference it:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    endpointURL: <myEndpointURL>
-    endpointCA:
-      name: my-ca-secret
-      key: ca.crt
-  [...]
-```
-
-<!-- TODO: does this also apply to the plugin? -->
-:::note
-If you want `ConfigMaps` and `Secrets` to be **automatically** reloaded by
-instances, you can add a label with the key `cnpg.io/reload` to the
-`Secrets`/`ConfigMaps`. Otherwise, you will have to reload the instances using the
-`kubectl cnpg reload` subcommand.
-:::
-
----
-
-## Azure Blob Storage
-
-[Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/)
-is Microsoft’s cloud-based object storage solution.
-
-Barman Cloud supports the following authentication methods:
-
-- [Connection String](https://learn.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string)
-- Storage Account Name + [Access Key](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage)
-- Storage Account Name + [SAS Token](https://learn.microsoft.com/en-us/azure/storage/blobs/sas-service-create)
-- [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/introduction.html)
-
-### Azure AD Workload Identity
-
-This method avoids storing credentials in Kubernetes via the
-`.spec.configuration.inheritFromAzureAD` option:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      inheritFromAzureAD: true
-  [...]
-```
-
-### Access Key, SAS Token, or Connection String
-
-Store credentials in a Kubernetes secret:
-
-```sh
-kubectl create secret generic azure-creds \
-  --from-literal=AZURE_STORAGE_ACCOUNT=<storage account name> \
-  --from-literal=AZURE_STORAGE_KEY=<storage account key> \
-  --from-literal=AZURE_STORAGE_SAS_TOKEN=<SAS token> \
-  --from-literal=AZURE_STORAGE_CONNECTION_STRING=<connection string>
-```
-
-Then reference the required keys in your `ObjectStore`:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      connectionString:
-        name: azure-creds
-        key: AZURE_CONNECTION_STRING
-      storageAccount:
-        name: azure-creds
-        key: AZURE_STORAGE_ACCOUNT
-      storageKey:
-        name: azure-creds
-        key: AZURE_STORAGE_KEY
-      storageSasToken:
-        name: azure-creds
-        key: AZURE_STORAGE_SAS_TOKEN
-  [...]
-```
-
-For Azure Blob, the destination path format is:
-
-```
-<http|https>://<account-name>.<service-name>.core.windows.net/<container>/<blob>
-```
-
-### Azure-Compatible Providers
-
-If you're using a different implementation (e.g., Azurite or emulator):
-
-```
-<http|https>://<local-machine-address>:<port>/<account-name>/<container>/<blob>
-```
-
----
-
-## Google Cloud Storage
-
-[Google Cloud Storage](https://cloud.google.com/storage/) is supported with two
-authentication modes:
-
-- **GKE Workload Identity** (recommended inside Google Kubernetes Engine)
-- **Service Account JSON key** via the `GOOGLE_APPLICATION_CREDENTIALS` environment variable
-
-### GKE Workload Identity
-
-Use the [Workload Identity authentication](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
-when running in GKE:
-
-1. Set `googleCredentials.gkeEnvironment` to `true` in the `ObjectStore`
-   resource
-2. Annotate the `serviceAccountTemplate` in the `Cluster` resource with the GCP
-   service account
-
-For example, in the `ObjectStore` resource:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      gkeEnvironment: true
-```
-
-And in the `Cluster` resource:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        iam.gke.io/gcp-service-account: [...].iam.gserviceaccount.com
-```
-
-### Service Account JSON Key
-
-Follow Google’s [authentication setup](https://cloud.google.com/docs/authentication/getting-started),
-then:
-
-```sh
-kubectl create secret generic backup-creds --from-file=gcsCredentials=gcs_credentials_file.json
-```
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      applicationCredentials:
-        name: backup-creds
-        key: gcsCredentials
-  [...]
-```
-
-:::important
-This authentication method generates a JSON file within the container
-with all the credentials required to access your Google Cloud Storage
-bucket. As a result, if someone gains access to the `Pod`, they will also have
-write permissions to the bucket.
-:::
-
----
-
-
-## MinIO Object Store
-
-In order to use the Tenant resource you first need to deploy the
-[MinIO operator](https://docs.min.io/community/minio-object-store/operations/deployments/installation.html).
-For the latest documentation of MinIO, please refer to the
-[MinIO official documentation](https://docs.min.io/community/minio-object-store/).
-
-MinIO Object Store's API is compatible with S3, and the default configuration of the Tenant
-will create these services:
-- `<tenant>-console` on port 9090 (with autocert) or 9443 (without autocert)
-- `<tenant>-hl` on port 9000
-Where `<tenant>` is the `metadata.name` you assigned to your Tenant resource.
-
-:::note
-The `<tenant>-console` service will only be available if you have enabled the
-[MinIO Console](https://docs.min.io/community/minio-object-store/administration/minio-console.html).
-
-For example, the following Tenant:
-```yml
-apiVersion: minio.min.io/v2
-kind: Tenant
-metadata:
-  name: cnpg-backups
-spec:
-  [...]
-```
-would have services called `cnpg-backups-console` and `cnpg-backups-hl` respectively.
-
-The `console` service is for managing the tenant, while the `hl` service exposes the S3
-compatible API. If your tenant is configured with `requestAutoCert` you will communicate
-to these services over HTTPS, if not you will use HTTP.
-
-For authentication you can use your username and password, or create an access key.
-Whichever method you choose, it has to be stored as a secret.
-
-```sh
-kubectl create secret generic minio-creds \
-  --from-literal=MINIO_ACCESS_KEY=<minio access key or username> \
-  --from-literal=MINIO_SECRET_KEY=<minio secret key or password>
-```
-
-Finally, create the Barman ObjectStore:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    destinationPath: s3://BUCKET_NAME/
-    endpointURL: http://<tenant>-hl:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio-creds
-        key: MINIO_ACCESS_KEY
-      secretAccessKey:
-        name: minio-creds
-        key: MINIO_SECRET_KEY
-  [...]
-```
-
-:::important
-Verify on `s3://BUCKET_NAME/` the presence of archived WAL files before
-proceeding with a backup.
-:::
-
----

web/versioned_docs/version-0.10.0/observability.md

@@ -1,24 +0,0 @@
----
-sidebar_position: 55
----
-
-# Observability
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin exposes the following metrics through the native
-Prometheus exporter of the instance manager:
-
-- `barman_cloud_cloudnative_pg_io_last_failed_backup_timestamp`:
-  the UNIX timestamp of the most recent failed backup.
-
-- `barman_cloud_cloudnative_pg_io_last_available_backup_timestamp`:
-  the UNIX timestamp of the most recent successfully available backup.
-
-- `barman_cloud_cloudnative_pg_io_first_recoverability_point`:
-  the UNIX timestamp representing the earliest point in time from which the
-  cluster can be recovered.
-
-These metrics supersede the previously available in-core metrics that used the
-`cnpg_collector` prefix. The new metrics are exposed under the
-`barman_cloud_cloudnative_pg_io` prefix instead.

web/versioned_docs/version-0.10.0/parameters.md

@@ -1,19 +0,0 @@
----
-sidebar_position: 100
----
-
-# Parameters
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The following parameters are available for the Barman Cloud Plugin:
-
-- `barmanObjectName`: references the `ObjectStore` resource to be used by the
-  plugin.
-- `serverName`: Specifies the server name in the object store.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::

web/versioned_docs/version-0.10.0/plugin-barman-cloud.v1.md

@@ -1,108 +0,0 @@
-# API Reference
-
-## Packages
-- [barmancloud.cnpg.io/v1](#barmancloudcnpgiov1)
-
-
-## barmancloud.cnpg.io/v1
-
-Package v1 contains API Schema definitions for the barmancloud v1 API group
-
-### Resource Types
-- [ObjectStore](#objectstore)
-
-
-
-#### InstanceSidecarConfiguration
-
-
-
-InstanceSidecarConfiguration defines the configuration for the sidecar that runs in the instance pods.
-
-
-
-_Appears in:_
-- [ObjectStoreSpec](#objectstorespec)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `env` _[EnvVar](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#envvar-v1-core) array_ | The environment to be explicitly passed to the sidecar |  |  |  |
-| `retentionPolicyIntervalSeconds` _integer_ | The retentionCheckInterval defines the frequency at which the<br />system checks and enforces retention policies. |  | 1800 |  |
-| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | Resources define cpu/memory requests and limits for the sidecar that runs in the instance pods. |  |  |  |
-| `additionalContainerArgs` _string array_ | AdditionalContainerArgs is an optional list of command-line arguments<br />to be passed to the sidecar container when it starts.<br />The provided arguments are appended to the container’s default arguments. |  |  |  |
-| `logLevel` _string_ | The log level for PostgreSQL instances. Valid values are: `error`, `warning`, `info` (default), `debug`, `trace` |  | info | Enum: [error warning info debug trace] <br /> |
-
-
-#### ObjectStore
-
-
-
-ObjectStore is the Schema for the objectstores API.
-
-
-
-
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `apiVersion` _string_ | `barmancloud.cnpg.io/v1` | True | | |
-| `kind` _string_ | `ObjectStore` | True | | |
-| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | True |  |  |
-| `spec` _[ObjectStoreSpec](#objectstorespec)_ | Specification of the desired behavior of the ObjectStore.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status | True |  |  |
-| `status` _[ObjectStoreStatus](#objectstorestatus)_ | Most recently observed status of the ObjectStore. This data may not be up to<br />date. Populated by the system. Read-only.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status |  |  |  |
-
-
-#### ObjectStoreSpec
-
-
-
-ObjectStoreSpec defines the desired state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `configuration` _[BarmanObjectStoreConfiguration](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration)_ | The configuration for the barman-cloud tool suite | True |  |  |
-| `retentionPolicy` _string_ | RetentionPolicy is the retention policy to be used for backups<br />and WALs (i.e. '60d'). The retention policy is expressed in the form<br />of `XXu` where `XX` is a positive integer and `u` is in `[dwm]` -<br />days, weeks, months. |  |  | Pattern: `^[1-9][0-9]*[dwm]$` <br /> |
-| `instanceSidecarConfiguration` _[InstanceSidecarConfiguration](#instancesidecarconfiguration)_ | The configuration for the sidecar that runs in the instance pods |  |  |  |
-
-
-#### ObjectStoreStatus
-
-
-
-ObjectStoreStatus defines the observed state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `serverRecoveryWindow` _object (keys:string, values:[RecoveryWindow](#recoverywindow))_ | ServerRecoveryWindow maps each server to its recovery window | True |  |  |
-
-
-#### RecoveryWindow
-
-
-
-RecoveryWindow represents the time span between the first
-recoverability point and the last successful backup of a PostgreSQL
-server, defining the period during which data can be restored.
-
-
-
-_Appears in:_
-- [ObjectStoreStatus](#objectstorestatus)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `firstRecoverabilityPoint` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The first recoverability point in a PostgreSQL server refers to<br />the earliest point in time to which the database can be<br />restored. | True |  |  |
-| `lastSuccessfulBackupTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The last successful backup time | True |  |  |
-| `lastFailedBackupTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The last failed backup time | True |  |  |
-
-

web/versioned_docs/version-0.10.0/resource-name-migration.md

@@ -1,219 +0,0 @@
----
-sidebar_position: 90
----
-
-# Resource name migration guide
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-:::warning
-Before proceeding with the migration process, please:
-1. **Read this guide in its entirety** to understand what changes will be made
-2. **Test in a non-production environment** first if possible
-3. **Ensure you have proper backups** of your cluster configuration
-
-This migration will delete old RBAC resources only after the
-`plugin-barman-cloud` upgrade. While the operation is designed to be safe, you
-should review and understand the changes before proceeding. The maintainers of
-this project are not responsible for any issues that may arise during
-migration.
-
-**Note:** This guide assumes you are using the default `cnpg-system` namespace.
-:::
-
-## Overview
-
-Starting from version **0.8.0**, the `plugin-barman-cloud` deployment manifests
-use more specific, prefixed resource names to avoid conflicts with other
-components deployed in the same Kubernetes cluster.
-
-## What Changed
-
-The following resources have been renamed to use proper prefixes.
-
-### Cluster-scoped Resources
-
-| Old Name                   | New Name                                 |
-|----------------------------|------------------------------------------|
-| `metrics-auth-role`        | `barman-plugin-metrics-auth-role`        |
-| `metrics-auth-rolebinding` | `barman-plugin-metrics-auth-rolebinding` |
-| `metrics-reader`           | `barman-plugin-metrics-reader`           |
-| `objectstore-viewer-role`  | `barman-plugin-objectstore-viewer-role`  |
-| `objectstore-editor-role`  | `barman-plugin-objectstore-editor-role`  |
-
-### Namespace-scoped Resources
-
-| Old Name                      | New Name                                    | Namespace     |
-|-------------------------------|---------------------------------------------|---------------|
-| `leader-election-role`        | `barman-plugin-leader-election-role`        | `cnpg-system` |
-| `leader-election-rolebinding` | `barman-plugin-leader-election-rolebinding` | `cnpg-system` |
-
-## Why This Change?
-
-Using generic names for cluster-wide resources is discouraged as they may
-conflict with other components deployed in the same cluster. The new names make
-it clear that these resources belong to the Barman Cloud plugin and help avoid
-naming collisions.
-
-## Migration Instructions
-
-This three steps migration process is straightforward and can be completed with
-a few `kubectl` commands.
-
-### Step 1: Upgrade plugin-barman-cloud
-
-Please refer to the [Installation](installation.mdx) section to deploy the new
-`plugin-barman-cloud` release.
-
-### Step 2: Delete Old Cluster-scoped Resources
-
-:::danger Verify Resources Before Deletion
-**IMPORTANT**: The old resource names are generic and could potentially belong
-to other components in your cluster.
-
-**Before deleting each resource, verify it belongs to the Barman Cloud plugin
-by checking:**
-- For `objectstore-*` roles: Look for `barmancloud.cnpg.io` in the API groups
-- For `metrics-*` roles: Check if they reference the `plugin-barman-cloud`
-  ServiceAccount in `cnpg-system` namespace
-- For other roles: Look for labels like `app.kubernetes.io/name: plugin-barman-cloud`
-
-If a resource doesn't have these indicators, **DO NOT DELETE IT** as it may
-belong to another application.
-
-Carefully review the output of each verification command before proceeding with
-the `delete`.
-:::
-
-:::tip Dry Run First
-You can add `--dry-run=client` to any `kubectl delete` command to preview what
-would be deleted without actually removing anything.
-:::
-
-**Only proceed if you've verified these resources belong to the Barman Cloud
-plugin (see warning above).**
-
-For each resource below, first verify it belongs to Barman Cloud, then delete
-it:
-
-```bash
-# 1. Check metrics-auth-rolebinding FIRST (we'll check the role after)
-# Look for references to plugin-barman-cloud ServiceAccount
-kubectl describe clusterrolebinding metrics-auth-rolebinding
-# If it references plugin-barman-cloud ServiceAccount in cnpg-system namespace,
-# delete it:
-kubectl delete clusterrolebinding metrics-auth-rolebinding
-
-# 2. Check metrics-auth-role
-# Look for references to authentication.k8s.io and authorization.k8s.io
-kubectl describe clusterrole metrics-auth-role
-# Verify it's not being used by any other rolebindings:
-kubectl get clusterrolebinding -o json \
-  | jq -r '.items[] | select(.roleRef.name=="metrics-auth-role") \
-  | .metadata.name'
-# If the above returns nothing (role is not in use) and the role looks like the
-# Barman Cloud one, delete it (see warnings section):
-kubectl delete clusterrole metrics-auth-role
-
-# 3. Check objectstore-viewer-role
-# Look for barmancloud.cnpg.io API group or
-# for `app.kubernetes.io/name: plugin-barman-cloud` label
-kubectl describe clusterrole objectstore-viewer-role
-# If it shows barmancloud.cnpg.io in API groups, delete it:
-kubectl delete clusterrole objectstore-viewer-role
-
-# 4. Check objectstore-editor-role
-# Look for barmancloud.cnpg.io API group or
-# for `app.kubernetes.io/name: plugin-barman-cloud` label
-kubectl describe clusterrole objectstore-editor-role
-# If it shows barmancloud.cnpg.io in API groups, delete it:
-kubectl delete clusterrole objectstore-editor-role
-
-# 5. Check metrics-reader (MOST DANGEROUS - very generic name)
-# First, check if it's being used by any rolebindings OTHER than barman's:
-kubectl get clusterrolebinding -o json | jq -r '.items[] \
-  | select(.roleRef.name=="metrics-reader") \
-  | "\(.metadata.name) -> \(.subjects[0].name) in \(.subjects[0].namespace)"'
-# If this shows ANY rolebindings, review them carefully. Only proceed if
-# they're all Barman-related.  Then check the role itself:
-kubectl describe clusterrole metrics-reader
-# If it ONLY has nonResourceURLs: /metrics and NO other rolebindings use it,
-# delete it:
-kubectl delete clusterrole metrics-reader
-```
-
-:::warning
-The `metrics-reader` role is particularly dangerous to delete blindly. Many
-monitoring systems use this exact name. Only delete it if:
-
-1. You've verified it ONLY grants access to `/metrics`
-2. No other rolebindings reference it (checked with the jq command above)
-3. You're certain it was created by the Barman Cloud plugin
-
-If you're unsure, it's safer to leave it and let the new
-`barman-plugin-metrics-reader` role coexist with it.
-:::
-
-If any resource is not found during the `describe` command, that's okay - it
-means it was never created or already deleted. Simply skip the delete command
-for that resource.
-
-### Step 3: Delete Old Namespace-scoped Resources
-
-Delete the old namespace-scoped resources in the `cnpg-system` namespace:
-
-```bash
-# Delete the old leader-election resources
-kubectl delete role leader-election-role -n cnpg-system
-kubectl delete rolebinding leader-election-rolebinding -n cnpg-system
-```
-
-If any resource is not found, that's okay - it means it was never created or
-already deleted.
-
-## Impact
-
-- **Permissions:** If you have custom RBAC rules or tools that reference the
-  old resource names, they will need to be updated.
-- **External Users:** If end users have been granted the
-  `objectstore-viewer-role` or `objectstore-editor-role`, they will need to be
-  re-granted the new role names (`barman-plugin-objectstore-viewer-role` and
-  `barman-plugin-objectstore-editor-role`).
-
-## Verification
-
-After migration, verify that the new resources are created:
-
-```bash
-# Check cluster-scoped resources
-kubectl get clusterrole | grep barman
-kubectl get clusterrolebinding | grep barman
-
-# Check namespace-scoped resources
-kubectl get role,rolebinding -n cnpg-system | grep barman
-```
-
-You should see the new prefixed resource names.
-
-## Troubleshooting
-
-### Plugin Not Starting After Migration
-
-If the plugin fails to start after migration, check:
-
-1. **ServiceAccount permissions:** Ensure the `plugin-barman-cloud` ServiceAccount is bound to the new roles:
-   ```bash
-   kubectl get clusterrolebinding barman-plugin-metrics-auth-rolebinding -o yaml
-   kubectl get rolebinding barman-plugin-leader-election-rolebinding -n cnpg-system -o yaml
-   ```
-
-2. **Role references:** Verify that the rolebindings reference the correct role names:
-   ```bash
-   kubectl describe rolebinding barman-plugin-leader-election-rolebinding -n cnpg-system
-   kubectl describe clusterrolebinding barman-plugin-metrics-auth-rolebinding
-   ```
-
-## Support
-
-If you encounter issues during migration, please open an issue on the [GitHub
-repository](https://github.com/cloudnative-pg/plugin-barman-cloud/issues).

web/versioned_docs/version-0.10.0/retention.md

@@ -1,38 +0,0 @@
----
-sidebar_position: 60
----
-
-# Retention Policies
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin supports **automated cleanup of obsolete backups** via
-retention policies, configured in the `.spec.retentionPolicy` field of the
-`ObjectStore` resource.
-
-:::note
-This feature uses the `barman-cloud-backup-delete` command with the
-`--retention-policy "RECOVERY WINDOW OF {{ value }} {{ unit }}"` syntax.
-:::
-
-#### Example: 30-Day Retention Policy
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  [...]
-  retentionPolicy: "30d"
-````
-
-:::note
-A **recovery window retention policy** ensures the cluster can be restored to
-any point in time between the calculated *Point of Recoverability* (PoR) and
-the latest WAL archive. The PoR is defined as `current time - recovery window`.
-The **first valid backup** is the most recent backup completed before the PoR.
-Backups older than that are marked as *obsolete* and deleted after the next
-backup completes.
-:::
-

web/versioned_docs/version-0.10.0/troubleshooting.md

@@ -1,591 +0,0 @@
----
-sidebar_position: 90
----
-
-# Troubleshooting
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-This guide helps you diagnose and resolve common issues with the Barman Cloud
-plugin.
-
-:::important
-We are continuously improving the integration between CloudNativePG and the
-Barman Cloud plugin as it moves toward greater stability and maturity. For this
-reason, we recommend using the latest available version of both components.
-See the [*Requirements* section](intro.md#requirements) for details.
-:::
-
-:::note
-The following commands assume you installed the CloudNativePG operator in
-the default `cnpg-system` namespace. If you installed it in a different
-namespace, adjust the commands accordingly.
-:::
-
-## Viewing Logs
-
-To troubleshoot effectively, you’ll often need to review logs from multiple
-sources:
-
-```sh
-# View operator logs (includes plugin interaction logs)
-kubectl logs -n cnpg-system deployment/cnpg-controller-manager -f
-
-# View plugin manager logs
-kubectl logs -n cnpg-system deployment/barman-cloud -f
-
-# View sidecar container logs (Barman Cloud operations)
-kubectl logs -n <namespace> <cluster-pod-name> -c plugin-barman-cloud -f
-
-# View all containers in a pod
-kubectl logs -n <namespace> <cluster-pod-name> --all-containers=true
-
-# View previous container logs (if container restarted)
-kubectl logs -n <namespace> <cluster-pod-name> -c plugin-barman-cloud --previous
-```
-
-## Common Issues
-
-### Plugin Installation Issues
-
-#### Plugin pods not starting
-
-**Symptoms:**
-
-- Plugin pods stuck in `CrashLoopBackOff` or `Error`
-- Plugin deployment not ready
-
-**Possible causes and solutions:**
-
-1. **Certificate issues**
-
-   ```sh
-   # Check if cert-manager is installed and running
-   kubectl get pods -n cert-manager
-
-   # Check if the plugin certificate is created
-   kubectl get certificates -n cnpg-system
-   ```
-
-   If cert-manager is not installed, install it first:
-
-   ```sh
-   # Note: other installation methods for cert-manager are available
-   kubectl apply -f \
-     https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml
-   ```
-
-   If you are using your own certificates without cert-manager, you will need
-   to verify the entire certificate chain yourself.
-
-
-2. **Image pull errors**
-
-   ```sh
-   # Check pod events for image pull errors
-   kubectl describe pod -n cnpg-system -l app=barman-cloud
-   ```
-
-   Verify the image exists and you have proper credentials if using a private
-   registry.
-
-
-3. **Resource constraints**
-
-   ```sh
-   # Check node resources
-   kubectl top nodes
-   kubectl describe nodes
-   ```
-
-   Make sure your cluster has sufficient CPU and memory resources.
-
-### Backup Failures
-
-#### Quick Backup Troubleshooting Checklist
-
-When a backup fails, follow these steps in order:
-
-1. **Check backup status**:
-
-   ```sh
-   kubectl get backups.postgresql.cnpg.io -n <namespace>
-   ```
-2. **Get error details and target pod**:
-
-   ```sh
-   kubectl describe backups.postgresql.cnpg.io \
-     -n <namespace> <backup-name>
-
-   kubectl get backups.postgresql.cnpg.io \
-     -n <namespace> <backup-name> \
-     -o jsonpath='{.status.instanceID.podName}'
-   ```
-3. **Check the target pod’s sidecar logs**:
-
-   ```sh
-   TARGET_POD=$(kubectl get backups.postgresql.cnpg.io \
-     -n <namespace> <backup-name> \
-     -o jsonpath='{.status.instanceID.podName}')
-
-   kubectl logs \
-     -n <namespace> $TARGET_POD -c plugin-barman-cloud \
-     --tail=100 | grep -E "ERROR|FATAL|panic"
-   ```
-4. **Check cluster events**:
-
-   ```sh
-   kubectl get events -n <namespace> \
-     --field-selector involvedObject.name=<cluster-name> \
-     --sort-by='.lastTimestamp'
-   ```
-5. **Verify plugin is running**:
-
-   ```sh
-   kubectl get pods \
-     -n cnpg-system -l app=barman-cloud
-   ```
-6. **Check operator logs**:
-
-   ```sh
-   kubectl logs \
-     -n cnpg-system deployment/cnpg-controller-manager \
-     --tail=100 | grep -i "backup\|plugin"
-   ```
-7. **Check plugin manager logs**:
-
-   ```sh
-   kubectl logs \
-     -n cnpg-system deployment/barman-cloud --tail=100
-   ```
-
-#### Backup job fails immediately
-
-**Symptoms:**
-
-- Backup pods terminate with error
-- No backup files appear in object storage
-- Backup shows `failed` phase with various error messages
-
-**Common failure modes and solutions:**
-
-1. **"requested plugin is not available" errors**
-
-   ```
-   requested plugin is not available: barman
-   requested plugin is not available: barman-cloud
-   requested plugin is not available: barman-cloud.cloudnative-pg.io
-   ```
-   
-   **Cause:** The plugin name in the Cluster configuration doesn’t match the
-   deployed plugin, or the plugin isn’t registered.
-   
-   **Solution:** 
-   
-   a. **Check plugin registration:**
-
-   ```sh
-   # If you have the `cnpg` plugin installed (v1.27.0+)
-   kubectl cnpg status -n <namespace> <cluster-name>
-   ```
-   
-   Look for the "Plugins status" section:
-   ```
-   Plugins status
-   Name                            Version  Status  Reported Operator Capabilities
-   ----                            -------  ------  ------------------------------
-   barman-cloud.cloudnative-pg.io  0.6.0    N/A     Reconciler Hooks, Lifecycle Service
-   ```
-   
-   b. **Verify plugin name in `Cluster` spec**:
-
-   ```yaml
-   apiVersion: postgresql.cnpg.io/v1
-   kind: Cluster
-   spec:
-     plugins:
-       - name: barman-cloud.cloudnative-pg.io
-         parameters:
-           barmanObjectName: <your-objectstore-name>
-   ```
-   
-   c. **Check plugin deployment is running**:
-
-   ```sh
-   kubectl get deployment -n cnpg-system barman-cloud
-   ```
-
-2. **"rpc error: code = Unknown desc = panic caught: assignment to entry in nil map" errors**
-   
-   **Cause:** Misconfiguration in the `ObjectStore` (e.g., typo or missing field).
-   
-   **Solution:** 
-
-   - Review sidecar logs for details
-   - Verify `ObjectStore` configuration and secrets
-   - Common issues include:
-     - Missing or incorrect secret references
-     - Typos in configuration parameters
-     - Missing required environment variables in secrets
-
-#### Backup performance issues
-
-**Symptoms:**
-
-- Backups take extremely long
-- Backups timeout
-
-**Plugin-specific considerations:**
-
-1. **Check `ObjectStore` parallelism settings**
-   - Adjust `maxParallel` in `ObjectStore` configuration
-   - Monitor sidecar container resource usage during backups
-
-2. **Verify plugin resource allocation**
-   - Check if the sidecar container has sufficient CPU/memory
-   - Review plugin container logs for resource-related warnings
-
-:::tip
-For Barman-specific features like compression, encryption, and performance
-tuning, refer to the [Barman documentation](https://docs.pgbarman.org/latest/).
-:::
-
-### WAL Archiving Issues
-
-#### WAL archiving stops
-
-**Symptoms:**
-
-- WAL files accumulate on the primary
-- Cluster shows WAL archiving warnings
-- Sidecar logs show WAL errors
-
-**Debugging steps:**
-
-1. **Check plugin sidecar logs for WAL archiving errors**
-   ```sh
-   # Check recent WAL archive operations in sidecar
-   kubectl logs -n <namespace> <primary-pod> -c plugin-barman-cloud \
-     --tail=50 | grep -i wal
-   ```
-
-2. **Check ObjectStore configuration for WAL settings**
-   - Ensure ObjectStore has proper WAL retention settings
-   - Verify credentials have permissions for WAL operations
-
-### Restore Issues
-
-#### Restore fails during recovery
-
-**Symptoms:**
-
-- New cluster stuck in recovery
-- Plugin sidecar shows restore errors
-- PostgreSQL won’t start
-
-**Debugging steps:**
-
-1. **Check plugin sidecar logs during restore**
-
-   ```sh
-   # Check the sidecar logs on the recovering cluster pods
-   kubectl logs -n <namespace> <cluster-pod-name> \
-     -c plugin-barman-cloud --tail=100
-   
-   # Look for restore-related errors
-   kubectl logs -n <namespace> <cluster-pod-name> \
-     -c plugin-barman-cloud | grep -E "restore|recovery|ERROR"
-   ```
-
-2. **Verify plugin can access backups**
-
-   ```sh
-   # Check if `ObjectStore` is properly configured for restore
-   kubectl get objectstores.barmancloud.cnpg.io \
-     -n <namespace> <objectstore-name> -o yaml
-   
-   # Check PostgreSQL recovery logs
-   kubectl logs -n <namespace> <cluster-pod> \
-     -c postgres | grep -i recovery
-   ```
-
-:::tip
-For detailed Barman restore operations and troubleshooting, refer to the
-[Barman documentation](https://docs.pgbarman.org/latest/barman-cloud-restore.html).
-:::
-
-#### Point-in-time recovery (PITR) configuration issues
-
-**Symptoms:**
-
-- PITR doesn’t reach target time
-- WAL access errors
-- Recovery halts early
-
-**Debugging steps:**
-
-1. **Verify PITR configuration in the `Cluster` spec**
-
-   ```yaml
-   apiVersion: postgresql.cnpg.io/v1
-   kind: Cluster
-   metadata:
-     name: <cluster-restore-name>
-   spec:
-     storage:
-       size: 1Gi
-
-     bootstrap:
-       recovery:
-         source: origin
-         recoveryTarget:
-           targetTime: "2024-01-15T10:30:00Z"
-
-     externalClusters:
-       - name: origin
-         plugin:
-           enabled: true
-           name: barman-cloud.cloudnative-pg.io
-           parameters:
-             barmanObjectName: <object-store-name>
-             serverName: <source-cluster-name>
-   ```
-
-2. **Check sidecar logs for WAL-related errors**
-
-   ```sh
-   kubectl logs -n <namespace> <cluster-pod> \
-     -c plugin-barman-cloud | grep -i wal
-   ```
-
-:::note
-Timestamps without an explicit timezone suffix
-(e.g., `2024-01-15 10:30:00`) are interpreted as UTC.
-:::
-
-:::warning
-Always specify an explicit timezone in your timestamp to avoid ambiguity.
-For example, use `2024-01-15T10:30:00Z` or `2024-01-15T10:30:00+02:00`
-instead of `2024-01-15 10:30:00`.
-:::
-
-:::note
-For detailed PITR configuration and WAL management, see the
-[Barman PITR documentation](https://docs.pgbarman.org/latest/).
-:::
-
-### Plugin Configuration Issues
-
-#### Plugin cannot connect to object storage
-
-**Symptoms:**
-
-- Sidecar logs show connection errors
-- Backups fail with authentication or network errors
-- `ObjectStore` resource reports errors
-
-**Solution:**
-
-1. **Verify `ObjectStore` CRD configuration and secrets**
-
-   ```sh
-   # Check ObjectStore resource status
-   kubectl get objectstores.barmancloud.cnpg.io \
-     -n <namespace> <objectstore-name> -o yaml
-   
-   # Verify the secret exists and has correct keys for your provider
-   kubectl get secret -n <namespace> <secret-name> \
-     -o jsonpath='{.data}' | jq 'keys'
-   ```
-
-2. **Check sidecar logs for connectivity issues**
-   ```sh
-   kubectl logs -n <namespace> <cluster-pod> \
-     -c plugin-barman-cloud | grep -E "connect|timeout|SSL|cert"
-   ```
-
-3. **Adjust provider-specific settings (endpoint, path style, etc.)**
-   - See [Object Store Configuration](object_stores.md) for provider-specific settings
-   - Ensure `endpointURL` match your storage type
-   - Verify network policies allow egress to your storage provider
-
-## Diagnostic Commands
-
-### Using the `cnpg` plugin for `kubectl`
-
-The `cnpg` plugin for `kubectl` provides extended debugging capabilities.
-Keep it updated:
-
-```sh
-# Install or update the `cnpg` plugin
-kubectl krew install cnpg
-# Or using an alternative method: https://cloudnative-pg.io/documentation/current/kubectl-plugin/#install
-
-# Check plugin status (requires CNPG 1.27.0+)
-kubectl cnpg status <cluster-name> -n <namespace>
-
-# View cluster status in detail
-kubectl cnpg status <cluster-name> -n <namespace> --verbose
-```
-
-## Getting Help
-
-If problems persist:
-
-1. **Check the documentation**
-
-   - [Installation Guide](installation.mdx)
-   - [Object Store Configuration](object_stores.md) (for provider-specific settings)
-   - [Usage Examples](usage.md)
-
-
-2. **Gather diagnostic information**
-
-   ```sh
-   # Create a diagnostic bundle (⚠️ sanitize these before sharing!)
-   kubectl get objectstores.barmancloud.cnpg.io -A -o yaml > /tmp/objectstores.yaml
-   kubectl get clusters.postgresql.cnpg.io -A -o yaml > /tmp/clusters.yaml
-   kubectl logs -n cnpg-system deployment/barman-cloud --tail=1000 > /tmp/plugin.log
-   ```
-
-
-3. **Community support**
-
-   - CloudNativePG Slack: [#cloudnativepg-users](https://cloud-native.slack.com/messages/cloudnativepg-users)
-   - GitHub Issues: [plugin-barman-cloud](https://github.com/cloudnative-pg/plugin-barman-cloud/issues)
-
-
-4. **Include when reporting**
-
-   - CloudNativePG version
-   - Plugin version
-   - Kubernetes version
-   - Cloud provider and region
-   - Relevant configuration (⚠️ sanitize/redact sensitive information)
-   - Error messages and logs
-   - Steps to reproduce
-
-## Known Issues and Limitations
-
-### Current Known Issues
-
-1. **Migration compatibility**: After migrating from in-tree backup to the
-   plugin, the `kubectl cnpg backup` command syntax has changed
-   ([#353](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/353)):
-
-   ```sh
-   # Old command (in-tree, no longer works after migration)
-   kubectl cnpg backup -n <namespace> <cluster-name> \
-     --method=barmanObjectStore
-   
-   # New command (plugin-based)
-   kubectl cnpg backup -n <namespace> <cluster-name> \
-     --method=plugin --plugin-name=barman-cloud.cloudnative-pg.io
-   ```
-
-### Plugin Limitations
-
-1. **Installation method**: Currently only supports manifest and Kustomize
-   installation ([#351](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/351) -
-   Helm chart requested)
-
-2. **Sidecar resource sharing**: The plugin sidecar container shares pod
-   resources with PostgreSQL
-
-3. **Plugin restart behavior**: Restarting the sidecar container requires
-   restarting the entire PostgreSQL pod
-
-## Recap of General Debugging Steps
-
-### Check Backup Status and Identify the Target Instance
-
-```sh
-# List all backups and their status
-kubectl get backups.postgresql.cnpg.io -n <namespace>
-
-# Get detailed backup information including error messages and target instance
-kubectl describe backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name>
-
-# Extract the target pod name from a failed backup
-kubectl get backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name> \
-  -o jsonpath='{.status.instanceID.podName}'
-
-# Get more details including the target pod, method, phase, and error
-kubectl get backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name> \
-  -o jsonpath='Pod: {.status.instanceID.podName}{"\n"}Method: {.status.method}{"\n"}Phase: {.status.phase}{"\n"}Error: {.status.error}{"\n"}'
-
-# Check the cluster status for backup-related information
-kubectl cnpg status <cluster-name> -n <namespace> --verbose
-```
-
-### Check Sidecar Logs on the Backup Target Pod
-
-```sh
-# Identify which pod was the backup target (from the previous step)
-TARGET_POD=$(kubectl get backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name> \
-  -o jsonpath='{.status.instanceID.podName}')
-echo "Backup target pod: $TARGET_POD"
-
-# Check the sidecar logs on the specific target pod
-kubectl logs -n <namespace> $TARGET_POD \
-  -c plugin-barman-cloud --tail=100
-
-# Follow the logs in real time
-kubectl logs -n <namespace> $TARGET_POD \
-  -c plugin-barman-cloud -f
-
-# Check for specific errors in the target pod around the backup time
-kubectl logs -n <namespace> $TARGET_POD \
-  -c plugin-barman-cloud --since=10m | grep -E "ERROR|FATAL|panic|failed"
-
-# Alternative: List all cluster pods and their roles
-kubectl get pods -n <namespace> -l cnpg.io/cluster=<cluster-name> \
-  -o custom-columns=NAME:.metadata.name,ROLE:.metadata.labels.cnpg\\.io/instanceRole,INSTANCE:.metadata.labels.cnpg\\.io/instanceName
-
-# Check sidecar logs on ALL cluster pods (if the target is unclear)
-for pod in $(kubectl get pods -n <namespace> -l cnpg.io/cluster=<cluster-name> -o name); do
-  echo "=== Checking $pod ==="
-  kubectl logs -n <namespace> $pod -c plugin-barman-cloud \
-    --tail=20 | grep -i error || echo "No errors found"
-done
-```
-
-### Check Events for Backup-Related Issues
-
-```sh
-# Check events for the cluster
-kubectl get events -n <namespace> \
-  --field-selector involvedObject.name=<cluster-name>
-
-# Check events for failed backups
-kubectl get events -n <namespace> \
-  --field-selector involvedObject.kind=Backup
-
-# Get all recent events in the namespace
-kubectl get events -n <namespace> --sort-by='.lastTimestamp' | tail -20
-```
-
-### Verify `ObjectStore` Configuration
-
-```sh
-# Check the ObjectStore resource
-kubectl get objectstores.barmancloud.cnpg.io \
-  -n <namespace> <objectstore-name> -o yaml
-
-# Verify the secret exists and has the correct keys
-kubectl get secret -n <namespace> <secret-name> -o yaml
-# Alternatively
-kubectl get secret -n <namespace> <secret-name> -o jsonpath='{.data}' | jq 'keys'
-```
-
-### Common Error Messages and Solutions
-
-* **"AccessDenied" or "403 Forbidden"** — Check cloud credentials and bucket permissions.
-* **"NoSuchBucket"** — Verify the bucket exists and the endpoint URL is correct.
-* **"Connection timeout"** — Check network connectivity and firewall rules.
-* **"SSL certificate problem"** — For self-signed certificates, verify the CA bundle configuration.
-

web/versioned_docs/version-0.10.0/upgrades.mdx

@@ -1,16 +0,0 @@
----
-sidebar_position: 25
----
-
-# Upgrades
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-You can upgrade the plugin simply by installing the new version. Unless
-explicitly stated below or in the release notes, no special steps are required.
-
-## Upgrading to version 0.8.x from previous versions
-
-Version **0.8.0** introduces breaking changes to resource naming.
-To complete the upgrade successfully, follow the instructions in the
-["Resource name migration guide"](resource-name-migration.md).

web/versioned_docs/version-0.10.0/usage.md

@@ -1,283 +0,0 @@
----
-sidebar_position: 30
----
-
-# Using the Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-After [installing the plugin](installation.mdx) in the same namespace as the
-CloudNativePG operator, enabling your PostgreSQL cluster to use the Barman
-Cloud Plugin involves just a few steps:
-
-- Defining the object store containing your WAL archive and base backups, using
-  your preferred [provider](object_stores.md)
-- Instructing the Postgres cluster to use the Barman Cloud Plugin
-
-From that moment, you’ll be able to issue on-demand backups or define a backup
-schedule, as well as rely on the object store for recovery operations.
-
-The rest of this page details each step, using MinIO as object store provider.
-
-## Defining the `ObjectStore`
-
-An `ObjectStore` resource must be created for each object store used in your
-PostgreSQL architecture. Here's an example configuration using MinIO:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-The `.spec.configuration` schema follows the same format as the
-[in-tree barman-cloud support](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration).
-Refer to [the CloudNativePG documentation](https://cloudnative-pg.io/documentation/current/appendixes/backup_barmanobjectstore/)
-for additional details.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::
-
-## Configuring WAL Archiving
-
-Once the `ObjectStore` is defined, you can configure your PostgreSQL cluster
-to archive WALs by referencing the store in the `.spec.plugins` section:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  instances: 3
-  imagePullPolicy: Always
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store
-  storage:
-    size: 1Gi
-```
-
-This configuration enables both WAL archiving and data directory backups.
-
-## Performing a Base Backup
-
-Once WAL archiving is enabled, the cluster is ready for backups. Backups can be
-created either declaratively (with YAML manifests) or imperatively (with the
-`cnpg` plugin).
-
-### Declarative approach (YAML manifest)
-
-Create a backup resource by applying a YAML manifest:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Backup
-metadata:
-  name: backup-example
-spec:
-  cluster:
-    name: cluster-example
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
-### Imperative approach (using the `cnpg` plugin)
-
-The quickest way to trigger an on-demand backup is with the `cnpg` plugin:
-
-```bash
-kubectl cnpg backup -n <namespace> <cluster-name> \
-  --method=plugin \
-  --plugin-name=barman-cloud.cloudnative-pg.io
-```
-
-:::note Migration from in-tree backups
-If you are migrating from the in-tree backup system, note the change in syntax:
-
-```bash
-# Old command (in-tree backup)
-kubectl cnpg backup -n <namespace> <cluster-name> --method=barmanObjectStore
-
-# New command (plugin-based backup)
-kubectl cnpg backup -n <namespace> <cluster-name> \
-  --method=plugin \
-  --plugin-name=barman-cloud.cloudnative-pg.io
-```
-:::
-
-## Restoring a Cluster
-
-To restore a cluster from an object store, create a new `Cluster` resource that
-references the store containing the backup. Below is an example configuration:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-:::important
-The above configuration does **not** enable WAL archiving for the restored cluster.
-:::
-
-To enable WAL archiving for the restored cluster, include the `.spec.plugins`
-section alongside the `externalClusters.plugin` section, as shown below:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      # Backup Object Store (push, read-write)
-      barmanObjectName: minio-store-bis
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        # Recovery Object Store (pull, read-only)
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-The same object store may be used for both transaction log archiving and
-restoring a cluster, or you can configure separate stores for these purposes.
-
-## Configuring Replica Clusters
-
-You can set up a distributed topology by combining the previously defined
-configurations with the `.spec.replica` section. Below is an example of how to
-define a replica cluster:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-dc-a
-spec:
-  instances: 3
-  primaryUpdateStrategy: unsupervised
-
-  storage:
-    storageClass: csi-hostpath-sc
-    size: 1Gi
-
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store-a
-
-  replica:
-    self: cluster-dc-a
-    primary: cluster-dc-a
-    source: cluster-dc-b
-
-  externalClusters:
-  - name: cluster-dc-a
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-a
-
-  - name: cluster-dc-b
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-b
-```
-
-## Configuring the plugin instance sidecar
-
-The Barman Cloud Plugin runs as a sidecar container next to each PostgreSQL
-instance pod. It manages backup, WAL archiving, and restore processes.
-
-Configuration comes from multiple `ObjectStore` resources:
-
-1. The one referenced in the
-   `.spec.plugins` section of the `Cluster`. This is the
-   object store used for WAL archiving and base backups.
-2. The one referenced in the external cluster
-   used in the `.spec.replica.source` section of the `Cluster`. This is
-   used by the log-shipping designated primary to get the WAL files.
-3. The one referenced in the
-   `.spec.bootstrap.recovery.source` section of the `Cluster`. Used by
-   the initial recovery job to create the cluster from an existing backup.
-
-You can fine-tune sidecar behavior in the `.spec.instanceSidecarConfiguration`
-of your ObjectStore. These settings apply to all PostgreSQL instances that use
-this object store. Any updates take effect at the next `Cluster` reconciliation,
-and could generate a rollout of the `Cluster`.
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-  # [...]
-  instanceSidecarConfiguration:
-    retentionPolicyIntervalSeconds: 1800
-    resources:
-      requests:
-        memory: "XXX"
-        cpu: "YYY"
-      limits:
-        memory: "XXX"
-        cpu: "YYY"
-```
-
-:::note
-If more than one `ObjectStore` applies, the `instanceSidecarConfiguration` of
-the one set in `.spec.plugins` has priority.
-:::

web/versioned_docs/version-0.11.0/compression.md

@@ -1,43 +0,0 @@
----
-sidebar_position: 80
----
-
-# Compression
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-By default, backups and WAL files are archived **uncompressed**. However, the
-Barman Cloud Plugin supports multiple compression algorithms via
-`barman-cloud-backup` and `barman-cloud-wal-archive`, allowing you to optimize
-for space, speed, or a balance of both.
-
-### Supported Compression Algorithms
-
-- `bzip2`
-- `gzip`
-- `lz4` (WAL only)
-- `snappy`
-- `xz` (WAL only)
-- `zstd` (WAL only)
-
-Compression settings for base backups and WAL archives are configured
-independently. For implementation details, refer to the corresponding API
-definitions:
-
-- [`DataBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#DataBackupConfiguration)
-- [`WALBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#WalBackupConfiguration)
-
-:::important
-Compression impacts both performance and storage efficiency. Choose the right
-algorithm based on your recovery time objectives (RTO), storage capacity, and
-network throughput.
-:::
-
-## Compression Benchmark (on MinIO)
-
-| Compression | Backup Time (ms) | Restore Time (ms) | Uncompressed Size (MB) | Compressed Size (MB) | Ratio |
-| ----------- | ---------------- | ----------------- | ---------------------- | -------------------- | ----- |
-| None        | 10,927           | 7,553             | 395                    | 395                  | 1.0:1 |
-| bzip2       | 25,404           | 13,886            | 395                    | 67                   | 5.9:1 |
-| gzip        | 116,281          | 3,077             | 395                    | 91                   | 4.3:1 |
-| snappy      | 8,134            | 8,341             | 395                    | 166                  | 2.4:1 |

web/versioned_docs/version-0.11.0/concepts.md

@@ -1,177 +0,0 @@
----
-sidebar_position: 10
----
-
-# Main Concepts
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-:::important
-Before proceeding, make sure to review the following sections of the
-CloudNativePG documentation:
-
-- [**Backup**](https://cloudnative-pg.io/documentation/current/backup/)
-- [**WAL Archiving**](https://cloudnative-pg.io/documentation/current/wal_archiving/)
-- [**Recovery**](https://cloudnative-pg.io/documentation/current/recovery/)
-:::
-
-The **Barman Cloud Plugin** enables **hot (online) backups** of PostgreSQL
-clusters in CloudNativePG through [`barman-cloud`](https://pgbarman.org),
-supporting continuous physical backups and WAL archiving to an **object
-store**—without interrupting write operations.
-
-It also supports both **full recovery** and **Point-in-Time Recovery (PITR)**
-of a PostgreSQL cluster.
-
-## The Object Store
-
-At the core is the [`ObjectStore` custom resource (CRD)](plugin-barman-cloud.v1.md#objectstorespec),
-which acts as the interface between the PostgreSQL cluster and the target
-object storage system. It allows you to configure:
-
-- **Authentication and bucket location** via the `.spec.configuration` section
-- **WAL archiving** settings—such as compression type, parallelism, and
-  server-side encryption—under `.spec.configuration.wal`
-- **Base backup options**—with similar settings for compression, concurrency,
-  and encryption—under `.spec.configuration.data`
-- **Retention policies** to manage the life-cycle of archived WALs and backups
-  via `.spec.configuration.retentionPolicy`
-
-WAL files are archived in the `wals` directory, while base backups are stored
-as **tarballs** in the `base` directory, following the
-[Barman Cloud convention](https://docs.pgbarman.org/cloud/latest/usage/#object-store-layout).
-
-The plugin also offers advanced capabilities, including
-[backup tagging](misc.md#backup-object-tagging) and
-[extra options for backups and WAL archiving](misc.md#extra-options-for-backup-and-wal-archiving).
-
-:::tip
-For details, refer to the
-[API reference for the `ObjectStore` resource](plugin-barman-cloud.v1.md#objectstorespec).
-:::
-
-## Integration with a CloudNativePG Cluster
-
-CloudNativePG can delegate continuous backup and recovery responsibilities to
-the **Barman Cloud Plugin** by configuring the `.spec.plugins` section of a
-`Cluster` resource. This setup requires a corresponding `ObjectStore` resource
-to be defined.
-
-:::important
-While it is technically possible to reuse the same `ObjectStore` for multiple
-`Cluster` resources within the same namespace, it is strongly recommended to
-dedicate one object store per PostgreSQL cluster to ensure data isolation and
-operational clarity.
-:::
-
-The following example demonstrates how to configure a CloudNativePG cluster
-named `cluster-example` to use a previously defined `ObjectStore` (also named
-`cluster-example`) in the same namespace. Setting `isWALArchiver: true` enables
-WAL archiving through the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  # Other cluster settings...
-  plugins:
-    - name: barman-cloud.cloudnative-pg.io
-      isWALArchiver: true
-      parameters:
-        barmanObjectName: cluster-example
-```
-
-## Backup of a Postgres Cluster
-
-Once the object store is defined and the `Cluster` is configured to use the
-Barman Cloud Plugin, **WAL archiving is activated immediately** on the
-PostgreSQL primary.
-
-Physical base backups are seamlessly managed by CloudNativePG using the
-`Backup` and `ScheduledBackup` resources, respectively for
-[on-demand](https://cloudnative-pg.io/documentation/current/backup/#on-demand-backups)
-and
-[scheduled](https://cloudnative-pg.io/documentation/current/backup/#scheduled-backups)
-backups.
-
-To use the Barman Cloud Plugin, you must set the `method` to `plugin` and
-configure the `pluginConfiguration` section as shown:
-
-```yaml
-[...]
-spec:
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-  [...]
-```
-
-With this configuration, CloudNativePG supports:
-
-- Backups from both **primary** and **standby** instances
-- Backups from **designated primaries** in a distributed topology using
-  [replica clusters](https://cloudnative-pg.io/documentation/current/replica_cluster/)
-
-:::tip
-For details on how to back up from a standby, refer to the official documentation:
-[Backup from a standby](https://cloudnative-pg.io/documentation/current/backup/#backup-from-a-standby).
-:::
-
-:::important
-Both backup and WAL archiving operations are executed by sidecar containers
-running in the same pod as the PostgreSQL `Cluster` primary instance—except
-when backups are taken from a standby, in which case the sidecar runs alongside
-the standby pod.
-The sidecar containers use a [dedicated container image](images.md) that
-includes only the supported version of Barman Cloud.
-:::
-
-## Recovery of a Postgres Cluster
-
-In PostgreSQL, *recovery* refers to the process of starting a database instance
-from an existing backup.  The Barman Cloud Plugin integrates with CloudNativePG
-to support both **full recovery** and **Point-in-Time Recovery (PITR)** from an
-object store.
-
-Recovery in this context is *not in-place*: it bootstraps a brand-new
-PostgreSQL cluster from a backup and replays the necessary WAL files to reach
-the desired recovery target.
-
-To perform a recovery, define an *external cluster* that references the
-appropriate `ObjectStore`, and use it as the source in the `bootstrap` section
-of the target cluster:
-
-```yaml
-[...]
-spec:
-  [...]
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: cluster-example
-        serverName: cluster-example
-  [...]
-```
-
-The critical element here is the `externalClusters` section of the `Cluster`
-resource, where the `plugin` stanza instructs CloudNativePG to use the Barman
-Cloud Plugin to access the object store for recovery.
-
-This same mechanism can be used for a variety of scenarios enabled by the
-CloudNativePG API, including:
-
-* **Full cluster recovery** from the latest backup
-* **Point-in-Time Recovery (PITR)**
-* Bootstrapping **replica clusters** in a distributed topology
-
-:::tip
-For complete instructions and advanced use cases, refer to the official
-[Recovery documentation](https://cloudnative-pg.io/documentation/current/recovery/).
-:::

web/versioned_docs/version-0.11.0/images.md

@@ -1,37 +0,0 @@
----
-sidebar_position: 99
----
-
-# Container Images
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin is distributed using two container images:
-
-- One for deploying the plugin components
-- One for the sidecar that runs alongside each PostgreSQL instance in a
-  CloudNativePG `Cluster` using the plugin
-
-## Plugin Container Image
-
-The plugin image contains the logic required to operate the Barman Cloud Plugin
-within your Kubernetes environment with CloudNativePG. It is published on the
-GitHub Container Registry at `ghcr.io/cloudnative-pg/plugin-barman-cloud`.
-
-This image is built from the
-[`Dockerfile.plugin`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.plugin)
-in the plugin repository.
-
-## Sidecar Container Image
-
-The sidecar image is used within each PostgreSQL pod in the cluster. It
-includes the latest supported version of Barman Cloud and is responsible for
-performing WAL archiving and backups on behalf of CloudNativePG.
-
-It is available at `ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar` and is
-built from the
-[`Dockerfile.sidecar`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.sidecar).
-
-These sidecar images are designed to work seamlessly with the
-[`minimal` PostgreSQL container images](https://github.com/cloudnative-pg/postgres-containers?tab=readme-ov-file#minimal-images)
-maintained by the CloudNativePG Community.

web/versioned_docs/version-0.11.0/installation.mdx

@@ -1,109 +0,0 @@
----
-sidebar_position: 20
----
-
-# Installation
-
-:::important
-1. The plugin **must** be installed in the same namespace as the CloudNativePG
-   operator (typically `cnpg-system`).
-
-2. Keep in mind that the operator's **listening namespaces** may differ from its
-   installation namespace. Double-check this to avoid configuration issues.
-:::
-
-## Verifying the Requirements
-
-Before installing the plugin, make sure the [requirements](intro.md#requirements) are met.
-
-### CloudNativePG Version
-
-Ensure you're running a version of CloudNativePG that is compatible with the
-plugin. If installed in the default `cnpg-system` namespace, you can verify the
-version with:
-
-```sh
-kubectl get deployment -n cnpg-system cnpg-controller-manager \
-  -o jsonpath="{.spec.template.spec.containers[*].image}"
-```
-
-Example output:
-
-```output
-ghcr.io/cloudnative-pg/cloudnative-pg:1.26.0
-```
-
-The version **must be 1.26 or newer**.
-
-### cert-manager
-
-Use the [cmctl](https://cert-manager.io/docs/reference/cmctl/#installation)
-tool to confirm that `cert-manager` is installed and available:
-
-```sh
-cmctl check api
-```
-
-Example output:
-
-```output
-The cert-manager API is ready
-```
-
-Both checks are required before proceeding with the installation.
-
-## Installing the Barman Cloud Plugin
-
-import { InstallationSnippet } from '@site/src/components/Installation';
-
-Install the plugin using `kubectl` by applying the manifest for the latest
-release:
-
-<InstallationSnippet />
-
-Example output:
-
-```output
-customresourcedefinition.apiextensions.k8s.io/objectstores.barmancloud.cnpg.io created
-serviceaccount/plugin-barman-cloud created
-role.rbac.authorization.k8s.io/leader-election-role created
-clusterrole.rbac.authorization.k8s.io/metrics-auth-role created
-clusterrole.rbac.authorization.k8s.io/metrics-reader created
-clusterrole.rbac.authorization.k8s.io/objectstore-editor-role created
-clusterrole.rbac.authorization.k8s.io/objectstore-viewer-role created
-clusterrole.rbac.authorization.k8s.io/plugin-barman-cloud created
-rolebinding.rbac.authorization.k8s.io/leader-election-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/metrics-auth-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/plugin-barman-cloud-binding created
-secret/plugin-barman-cloud-8tfddg42gf created
-service/barman-cloud created
-deployment.apps/barman-cloud configured
-certificate.cert-manager.io/barman-cloud-client created
-certificate.cert-manager.io/barman-cloud-server created
-issuer.cert-manager.io/selfsigned-issuer created
-```
-
-Finally, check that the deployment is up and running:
-
-```sh
-kubectl rollout status deployment \
-  -n cnpg-system barman-cloud
-```
-
-Example output:
-
-```output
-deployment "barman-cloud" successfully rolled out
-```
-
-This confirms that the plugin is deployed and ready to use.
-
-## Testing the latest development snapshot
-
-You can also test the latest development snapshot of the plugin with the
-following command:
-
-```sh
-kubectl apply -f \
-  https://raw.githubusercontent.com/cloudnative-pg/plugin-barman-cloud/refs/heads/main/manifest.yaml
-```

web/versioned_docs/version-0.11.0/intro.md

@@ -1,86 +0,0 @@
----
-sidebar_position: 1
-sidebar_label: "Introduction"
----
-
-# Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The **Barman Cloud Plugin** for [CloudNativePG](https://cloudnative-pg.io/)
-enables online continuous physical backups of PostgreSQL clusters to object storage
-using the `barman-cloud` suite from the [Barman](https://docs.pgbarman.org/release/latest/)
-project.
-
-:::important
-If you plan to migrate your existing CloudNativePG cluster to the new
-plugin-based approach using the Barman Cloud Plugin, see
-["Migrating from Built-in CloudNativePG Backup"](migration.md)
-for detailed instructions.
-:::
-
-## Requirements
-
-Before using the Barman Cloud Plugin, ensure that the following components are
-installed and properly configured:
-
-- [CloudNativePG](https://cloudnative-pg.io) version 1.26 or later
-
-  - We strongly recommend version 1.27.0 or later, which includes improved
-    error handling and status reporting for the plugin.
-  - If you are running an earlier release, refer to the
-    [upgrade guide](https://cloudnative-pg.io/documentation/current/installation_upgrade).
-
-- [cert-manager](https://cert-manager.io/)
-
-  - The recommended way to enable secure TLS communication between the plugin
-    and the operator.
-  - Alternatively, you can provide your own certificate bundles. See the
-    [CloudNativePG documentation on TLS configuration](https://cloudnative-pg.io/documentation/current/cnpg_i/#configuring-tls-certificates).
-
-- [`kubectl-cnpg`](https://cloudnative-pg.io/documentation/current/kubectl-plugin/)
-  plugin (optional but recommended)
-
-  - Simplifies debugging and monitoring with additional status and inspection
-    commands.
-  - Multiple installation options are available in the
-    [installation guide](https://cloudnative-pg.io/documentation/current/kubectl-plugin/#install).
-
-## Key Features
-
-This plugin provides the following capabilities:
-
-- Physical online backup of the data directory
-- Physical restore of the data directory
-- Write-Ahead Log (WAL) archiving
-- WAL restore
-- Full cluster recovery
-- Point-in-Time Recovery (PITR)
-- Seamless integration with replica clusters for bootstrap and WAL restore from archive
-
-:::important
-The Barman Cloud Plugin is designed to **replace the in-tree object storage support**
-previously provided via the `.spec.backup.barmanObjectStore` section in the
-`Cluster` resource.
-Backups created using the in-tree approach are fully supported and compatible
-with this plugin.
-:::
-
-## Supported Object Storage Providers
-
-The plugin works with all storage backends supported by `barman-cloud`, including:
-
-- **Amazon S3**
-- **Google Cloud Storage**
-- **Microsoft Azure Blob Storage**
-
-In addition, the following S3-compatible and simulator solutions have been
-tested and verified:
-
-- [MinIO](https://min.io/) – An S3-compatible storage solution
-- [Azurite](https://github.com/Azure/Azurite) – A simulator for Azure Blob Storage
-- [fake-gcs-server](https://github.com/fsouza/fake-gcs-server) – A simulator for Google Cloud Storage
-
-:::tip
-For more details, refer to [Object Store Providers](object_stores.md).
-:::

web/versioned_docs/version-0.11.0/migration.md

@@ -1,274 +0,0 @@
----
-sidebar_position: 40
----
-
-# Migrating from Built-in CloudNativePG Backup
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The in-tree support for Barman Cloud in CloudNativePG is **deprecated starting
-from version 1.26** and will be removed in a future release.
-
-If you're currently relying on the built-in Barman Cloud integration, you can
-migrate seamlessly to the new **plugin-based architecture** using the Barman
-Cloud Plugin, without data loss. Follow these steps:
-
-- [Install the Barman Cloud Plugin](installation.mdx)
-- Create an `ObjectStore` resource by translating the contents of the
-  `.spec.backup.barmanObjectStore` section from your existing `Cluster`
-  definition
-- Modify the `Cluster` resource in a single atomic change to switch from
-  in-tree backup to the plugin
-- Update any `ScheduledBackup` resources to use the plugin
-- Update the `externalClusters` configuration, where applicable
-
-:::tip
-For a working example, refer to [this commit](https://github.com/cloudnative-pg/cnpg-playground/commit/596f30e252896edf8f734991c3538df87630f6f7)
-from the [CloudNativePG Playground project](https://github.com/cloudnative-pg/cnpg-playground),
-which demonstrates a full migration.
-:::
-
----
-
-## Step 1: Define the `ObjectStore`
-
-Begin by creating an `ObjectStore` resource in the same namespace as your
-PostgreSQL `Cluster`.
-
-There is a **direct mapping** between the `.spec.backup.barmanObjectStore`
-section in CloudNativePG and the `.spec.configuration` field in the
-`ObjectStore` CR. The conversion is mostly mechanical, with one key difference:
-
-:::warning
-In the plugin architecture, retention policies are defined as part of the `ObjectStore`.
-In contrast, the in-tree implementation defined them at the `Cluster` level.
-:::
-
-If your `Cluster` used `.spec.backup.retentionPolicy`, move that configuration
-to `.spec.retentionPolicy` in the `ObjectStore`.
-
----
-
-### Example
-
-Here’s an excerpt from a traditional in-tree CloudNativePG backup configuration
-taken from the CloudNativePG Playground project:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-eu
-spec:
-  # [...]
-  backup:
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-This configuration translates to the following `ObjectStore` resource for the
-plugin:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-As you can see, the contents of `barmanObjectStore` have been copied directly
-under the `configuration` field of the `ObjectStore` resource, using the same
-secret references.
-
-## Step 2: Update the `Cluster` for plugin WAL archiving
-
-Once the `ObjectStore` resource is in place, update the `Cluster` resource as
-follows in a single atomic change:
-
-- Remove the `.spec.backup.barmanObjectStore` section
-- Remove `.spec.backup.retentionPolicy` if it was defined (as it is now in the
-  `ObjectStore`)
-- Remove the entire `spec.backup` section if it is now empty
-- Add `barman-cloud.cloudnative-pg.io` to the `plugins` list, as described in
-  [Configuring WAL archiving](usage.md#configuring-wal-archiving)
-
-This will trigger a rolling update of the `Cluster`, switching continuous
-backup from the in-tree implementation to the plugin-based approach.
-
-### Example
-
-The updated `pg-eu` cluster will have this configuration instead of the
-previous `backup` section:
-
-```yaml
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-eu
-```
-
----
-
-## Step 3: Update the `ScheduledBackup`
-
-After switching the `Cluster` to use the plugin, update your `ScheduledBackup`
-resources to match.
-
-Set the backup `method` to `plugin` and reference the plugin name via
-`pluginConfiguration`, as shown in ["Performing a base backup"](usage.md#performing-a-base-backup).
-
-### Example
-
-Original in-tree `ScheduledBackup`:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-```
-
-Updated version using the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
----
-
-## Step 4: Update the `externalClusters` configuration
-
-If your `Cluster` relies on one or more external clusters that use the in-tree
-Barman Cloud integration, you need to update those configurations to use the
-plugin-based architecture.
-
-When a replica cluster fetches WAL files or base backups from an external
-source that used the built-in backup method, follow these steps:
-
-1. Create a corresponding `ObjectStore` resource for the external cluster, as
-   shown in [Step 1](#step-1-define-the-objectstore)
-2. Update the `externalClusters` section of your replica cluster to use the
-   plugin instead of the in-tree `barmanObjectStore` field
-
-### Example
-
-Consider the original configuration using in-tree Barman Cloud:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      serverName: pg-eu
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-Create the `ObjectStore` resource for the external cluster:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-    accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-    secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-Update the external cluster configuration to use the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-eu
-        serverName: pg-eu
-```
-
-## Step 5: Verify your metrics
-
-When migrating from the in-core solution to the plugin-based approach, you need
-to monitor a different set of metrics, as described in the
-["Observability"](observability.md) section.
-
-The table below summarizes the name changes between the old in-core metrics and
-the new plugin-based ones:
-
-| Old metric name                                  | New metric name                                                  |
-| ------------------------------------------------ | ---------------------------------------------------------------- |
-| `cnpg_collector_last_failed_backup_timestamp`    | `barman_cloud_cloudnative_pg_io_last_failed_backup_timestamp`    |
-| `cnpg_collector_last_available_backup_timestamp` | `barman_cloud_cloudnative_pg_io_last_available_backup_timestamp` |
-| `cnpg_collector_first_recoverability_point`      | `barman_cloud_cloudnative_pg_io_first_recoverability_point`      |

web/versioned_docs/version-0.11.0/misc.md

@@ -1,97 +0,0 @@
----
-sidebar_position: 90
----
-
-# Miscellaneous
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-## Backup Object Tagging
-
-You can attach key-value metadata tags to backup artifacts—such as base
-backups, WAL files, and history files—via the `.spec.configuration` section of
-the `ObjectStore` resource.
-
-- `tags`: applied to base backups and WAL files
-- `historyTags`: applied to history files only
-
-### Example
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    [...]
-    tags:
-      backupRetentionPolicy: "expire"
-    historyTags:
-      backupRetentionPolicy: "keep"
-  [...]
-```
-
-## Extra Options for Backup and WAL Archiving
-
-You can pass additional command-line arguments to `barman-cloud-backup` and
-`barman-cloud-wal-archive` using the `additionalCommandArgs` field in the
-`ObjectStore` configuration.
-
-- `.spec.configuration.data.additionalCommandArgs`: for `barman-cloud-backup`
-- `.spec.configuration.wal.archiveAdditionalCommandArgs`: for `barman-cloud-wal-archive`
-
-Each field accepts a list of string arguments. If an argument is already
-configured elsewhere in the plugin, the duplicate will be ignored.
-
-### Example: Extra Backup Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    data:
-      additionalCommandArgs:
-        - "--min-chunk-size=5MB"
-        - "--read-timeout=60"
-```
-
-### Example: Extra WAL Archive Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    wal:
-      archiveAdditionalCommandArgs:
-        - "--max-concurrency=1"
-        - "--read-timeout=60"
-```
-
-For a complete list of supported options, refer to the
-[official Barman Cloud documentation](https://docs.pgbarman.org/release/latest/).
-
-## Enable the pprof debug server for the sidecar
-
-You can enable the instance sidecar's pprof debug HTTP server by adding the `--pprof-server=<address>` flag to the container's
-arguments via `.spec.instanceSidecarConfiguration.additionalContainerArgs`.
-
-Pass a bind address in the form `<host>:<port>` (for example, `0.0.0.0:6061`).
-An empty value disables the server (disabled by default).
-
-### Example
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  instanceSidecarConfiguration:
-    additionalContainerArgs:
-      - "--pprof-server=0.0.0.0:6061"
-```

web/versioned_docs/version-0.11.0/object_stores.md

@@ -1,498 +0,0 @@
----
-sidebar_position: 50
----
-
-# Object Store Providers
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin enables the storage of PostgreSQL cluster backup files
-in any object storage service supported by the
-[Barman Cloud infrastructure](https://docs.pgbarman.org/release/latest/).
-
-Currently, Barman Cloud supports the following providers:
-
-- [Amazon S3](#aws-s3)
-- [Microsoft Azure Blob Storage](#azure-blob-storage)
-- [Google Cloud Storage](#google-cloud-storage)
-
-You may also use any S3- or Azure-compatible implementation of the above
-services.
-
-To configure object storage with Barman Cloud, you must define an
-[`ObjectStore` object](plugin-barman-cloud.v1.md#objectstore), which
-establishes the connection between your PostgreSQL cluster and the object
-storage backend.
-
-Configuration details — particularly around authentication — will vary depending on
-the specific object storage provider you are using.
-
-The following sections detail the setup for each.
-
-:::note Authentication Methods
-The Barman Cloud Plugin does not independently test all authentication methods
-supported by `barman-cloud`. The plugin's responsibility is limited to passing
-the provided credentials to `barman-cloud`, which then handles authentication
-according to its own implementation. Users should refer to the
-[Barman Cloud documentation](https://docs.pgbarman.org/release/latest/) to
-verify that their chosen authentication method is supported and properly
-configured.
-:::
-
----
-
-## AWS S3
-
-[AWS Simple Storage Service (S3)](https://aws.amazon.com/s3/) is one of the
-most widely adopted object storage solutions.
-
-The Barman Cloud plugin for CloudNativePG integrates with S3 through two
-primary authentication mechanisms:
-
-- [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) —
-  recommended for clusters running on EKS
-- Access keys — using `ACCESS_KEY_ID` and `ACCESS_SECRET_KEY` credentials
-
-### Access Keys
-
-To authenticate using access keys, you’ll need:
-
-- `ACCESS_KEY_ID`: the public key used to authenticate to S3
-- `ACCESS_SECRET_KEY`: the corresponding secret key
-- `ACCESS_SESSION_TOKEN`: (optional) a temporary session token, if required
-
-These credentials must be stored securely in a Kubernetes secret:
-
-```sh
-kubectl create secret generic aws-creds \
-  --from-literal=ACCESS_KEY_ID=<access key here> \
-  --from-literal=ACCESS_SECRET_KEY=<secret key here>
-# --from-literal=ACCESS_SESSION_TOKEN=<session token here> # if required
-```
-
-The credentials will be encrypted at rest if your Kubernetes environment
-supports it.
-
-You can then reference the secret in your `ObjectStore` definition:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: aws-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    s3Credentials:
-      accessKeyId:
-        name: aws-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: aws-creds
-        key: ACCESS_SECRET_KEY
-  [...]
-```
-
-### IAM Role for Service Account (IRSA)
-
-To use IRSA with EKS, configure the service account of the PostgreSQL cluster
-with the appropriate annotation:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  [...]
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        eks.amazonaws.com/role-arn: arn:[...]
-        [...]
-```
-
-### S3 Lifecycle Policy
-
-Barman Cloud uploads backup files to S3 but does not modify them afterward.
-To enhance data durability and protect against accidental or malicious loss,
-it's recommended to implement the following best practices:
-
-- Enable object versioning
-- Enable object locking to prevent objects from being deleted or overwritten
-  for a defined period or indefinitely (this provides an additional layer of
-  protection against accidental deletion and ransomware attacks)
-- Set lifecycle rules to expire current versions a few days after your Barman
-  retention window
-- Expire non-current versions after a longer period
-
-These strategies help you safeguard backups without requiring broad delete
-permissions, ensuring both security and compliance with minimal operational
-overhead.
-
-
-### S3-Compatible Storage Providers
-
-You can use S3-compatible services like **MinIO**, **Linode (Akamai) Object Storage**,
-or **DigitalOcean Spaces** by specifying a custom `endpointURL`.
-
-Example with Linode (Akamai) Object Storage (`us-east1`):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: linode-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/"
-    endpointURL: "https://us-east1.linodeobjects.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-Recent changes to the [boto3 implementation](https://github.com/boto/boto3/issues/4392)
-of [Amazon S3 Data Integrity Protections](https://docs.aws.amazon.com/sdkref/latest/guide/feature-dataintegrity.html)
-may lead to the `x-amz-content-sha256` error when using the Barman Cloud
-Plugin.
-
-If you encounter this issue (see [GitHub issue #393](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/393)),
-you can apply the following workaround by setting specific environment
-variables in the `ObjectStore` resource:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: linode-store
-spec:
-  instanceSidecarConfiguration:
-    env:
-      - name: AWS_REQUEST_CHECKSUM_CALCULATION
-        value: when_required
-      - name: AWS_RESPONSE_CHECKSUM_VALIDATION
-        value: when_required
-  [...]
-```
-
-These settings ensure that checksum calculations and validations are only
-applied when explicitly required, avoiding compatibility issues with certain
-S3-compatible storage providers.
-
-Example with DigitalOcean Spaces (SFO3, path-style):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: digitalocean-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    endpointURL: "https://sfo3.digitaloceanspaces.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-### Using Object Storage with a Private CA
-
-For object storage services (e.g., MinIO) that use HTTPS with certificates
-signed by a private CA, set the `endpointCA` field in the `ObjectStore`
-definition. Unless you already have it, create a Kubernetes `Secret` with the
-CA bundle:
-
-```sh
-kubectl create secret generic my-ca-secret --from-file=ca.crt
-```
-
-Then reference it:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    endpointURL: <myEndpointURL>
-    endpointCA:
-      name: my-ca-secret
-      key: ca.crt
-  [...]
-```
-
-<!-- TODO: does this also apply to the plugin? -->
-:::note
-If you want `ConfigMaps` and `Secrets` to be **automatically** reloaded by
-instances, you can add a label with the key `cnpg.io/reload` to the
-`Secrets`/`ConfigMaps`. Otherwise, you will have to reload the instances using the
-`kubectl cnpg reload` subcommand.
-:::
-
----
-
-## Azure Blob Storage
-
-[Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/)
-is Microsoft’s cloud-based object storage solution.
-
-Barman Cloud supports the following authentication methods:
-
-- [Connection String](https://learn.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string)
-- Storage Account Name + [Storage Account Access Key](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage)
-- Storage Account Name + [Storage Account SAS Token](https://learn.microsoft.com/en-us/azure/storage/blobs/sas-service-create)
-- [Azure AD Managed Identity](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview)
-- [Default Azure Credentials](https://learn.microsoft.com/en-us/dotnet/api/azure.identity.defaultazurecredential?view=azure-dotnet)
-
-### Azure AD Managed Identity
-
-This method avoids storing credentials in Kubernetes by enabling the
-usage of [Azure Managed Identities](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview) authentication mechanism.
-This can be enabled by setting the `inheritFromAzureAD` option to `true`.
-Managed Identity can be configured for the AKS Cluster by following
-the [Azure documentation](https://learn.microsoft.com/en-us/azure/aks/use-managed-identity?pivots=system-assigned).
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      inheritFromAzureAD: true
-  [...]
-```
-
-### Default Azure Credentials
-
-The `useDefaultAzureCredentials` option enables the default Azure credentials
-flow, which uses [`DefaultAzureCredential`](https://learn.microsoft.com/en-us/python/api/azure-identity/azure.identity.defaultazurecredential)
-to automatically discover and use available credentials in the following order:
-
-1. **Environment Variables** — `AZURE_CLIENT_ID`, `AZURE_CLIENT_SECRET`, and `AZURE_TENANT_ID` for Service Principal authentication
-2. **Managed Identity** — Uses the managed identity assigned to the pod
-3. **Azure CLI** — Uses credentials from the Azure CLI if available
-4. **Azure PowerShell** — Uses credentials from Azure PowerShell if available
-
-This approach is particularly useful for getting started with development and testing; it allows
-the SDK to attempt multiple authentication mechanisms seamlessly across different environments.
-However, this is not recommended for production. Please refer to the
-[official Azure guidance](https://learn.microsoft.com/en-us/dotnet/azure/sdk/authentication/credential-chains?tabs=dac#usage-guidance-for-defaultazurecredential)
-for a comprehensive understanding of `DefaultAzureCredential`.
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      useDefaultAzureCredentials: true
-  [...]
-```
-
-### Access Key, SAS Token, or Connection String
-
-Store credentials in a Kubernetes secret:
-
-```sh
-kubectl create secret generic azure-creds \
-  --from-literal=AZURE_STORAGE_ACCOUNT=<storage account name> \
-  --from-literal=AZURE_STORAGE_KEY=<storage account key> \
-  --from-literal=AZURE_STORAGE_SAS_TOKEN=<SAS token> \
-  --from-literal=AZURE_STORAGE_CONNECTION_STRING=<connection string>
-```
-
-Then reference the required keys in your `ObjectStore`:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      connectionString:
-        name: azure-creds
-        key: AZURE_CONNECTION_STRING
-      storageAccount:
-        name: azure-creds
-        key: AZURE_STORAGE_ACCOUNT
-      storageKey:
-        name: azure-creds
-        key: AZURE_STORAGE_KEY
-      storageSasToken:
-        name: azure-creds
-        key: AZURE_STORAGE_SAS_TOKEN
-  [...]
-```
-
-For Azure Blob, the destination path format is:
-
-```
-<http|https>://<account-name>.<service-name>.core.windows.net/<container>/<blob>
-```
-
-### Azure-Compatible Providers
-
-If you're using a different implementation (e.g., Azurite or emulator):
-
-```
-<http|https>://<local-machine-address>:<port>/<account-name>/<container>/<blob>
-```
-
----
-
-## Google Cloud Storage
-
-[Google Cloud Storage](https://cloud.google.com/storage/) is supported with two
-authentication modes:
-
-- **GKE Workload Identity** (recommended inside Google Kubernetes Engine)
-- **Service Account JSON key** via the `GOOGLE_APPLICATION_CREDENTIALS` environment variable
-
-### GKE Workload Identity
-
-Use the [Workload Identity authentication](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
-when running in GKE:
-
-1. Set `googleCredentials.gkeEnvironment` to `true` in the `ObjectStore`
-   resource
-2. Annotate the `serviceAccountTemplate` in the `Cluster` resource with the GCP
-   service account
-
-For example, in the `ObjectStore` resource:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      gkeEnvironment: true
-```
-
-And in the `Cluster` resource:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        iam.gke.io/gcp-service-account: [...].iam.gserviceaccount.com
-```
-
-### Service Account JSON Key
-
-Follow Google’s [authentication setup](https://cloud.google.com/docs/authentication/getting-started),
-then:
-
-```sh
-kubectl create secret generic backup-creds --from-file=gcsCredentials=gcs_credentials_file.json
-```
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      applicationCredentials:
-        name: backup-creds
-        key: gcsCredentials
-  [...]
-```
-
-:::important
-This authentication method generates a JSON file within the container
-with all the credentials required to access your Google Cloud Storage
-bucket. As a result, if someone gains access to the `Pod`, they will also have
-write permissions to the bucket.
-:::
-
----
-
-
-## MinIO Object Store
-
-In order to use the Tenant resource you first need to deploy the
-[MinIO operator](https://docs.min.io/community/minio-object-store/operations/deployments/installation.html).
-For the latest documentation of MinIO, please refer to the
-[MinIO official documentation](https://docs.min.io/community/minio-object-store/).
-
-MinIO Object Store's API is compatible with S3, and the default configuration of the Tenant
-will create these services:
-- `<tenant>-console` on port 9090 (with autocert) or 9443 (without autocert)
-- `<tenant>-hl` on port 9000
-Where `<tenant>` is the `metadata.name` you assigned to your Tenant resource.
-
-:::note
-The `<tenant>-console` service will only be available if you have enabled the
-[MinIO Console](https://docs.min.io/community/minio-object-store/administration/minio-console.html).
-
-For example, the following Tenant:
-```yml
-apiVersion: minio.min.io/v2
-kind: Tenant
-metadata:
-  name: cnpg-backups
-spec:
-  [...]
-```
-would have services called `cnpg-backups-console` and `cnpg-backups-hl` respectively.
-
-The `console` service is for managing the tenant, while the `hl` service exposes the S3
-compatible API. If your tenant is configured with `requestAutoCert` you will communicate
-to these services over HTTPS, if not you will use HTTP.
-
-For authentication you can use your username and password, or create an access key.
-Whichever method you choose, it has to be stored as a secret.
-
-```sh
-kubectl create secret generic minio-creds \
-  --from-literal=MINIO_ACCESS_KEY=<minio access key or username> \
-  --from-literal=MINIO_SECRET_KEY=<minio secret key or password>
-```
-
-Finally, create the Barman ObjectStore:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    destinationPath: s3://BUCKET_NAME/
-    endpointURL: http://<tenant>-hl:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio-creds
-        key: MINIO_ACCESS_KEY
-      secretAccessKey:
-        name: minio-creds
-        key: MINIO_SECRET_KEY
-  [...]
-```
-
-:::important
-Verify on `s3://BUCKET_NAME/` the presence of archived WAL files before
-proceeding with a backup.
-:::
-
----

web/versioned_docs/version-0.11.0/observability.md

@@ -1,24 +0,0 @@
----
-sidebar_position: 55
----
-
-# Observability
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin exposes the following metrics through the native
-Prometheus exporter of the instance manager:
-
-- `barman_cloud_cloudnative_pg_io_last_failed_backup_timestamp`:
-  the UNIX timestamp of the most recent failed backup.
-
-- `barman_cloud_cloudnative_pg_io_last_available_backup_timestamp`:
-  the UNIX timestamp of the most recent successfully available backup.
-
-- `barman_cloud_cloudnative_pg_io_first_recoverability_point`:
-  the UNIX timestamp representing the earliest point in time from which the
-  cluster can be recovered.
-
-These metrics supersede the previously available in-core metrics that used the
-`cnpg_collector` prefix. The new metrics are exposed under the
-`barman_cloud_cloudnative_pg_io` prefix instead.

web/versioned_docs/version-0.11.0/parameters.md

@@ -1,19 +0,0 @@
----
-sidebar_position: 100
----
-
-# Parameters
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The following parameters are available for the Barman Cloud Plugin:
-
-- `barmanObjectName`: references the `ObjectStore` resource to be used by the
-  plugin.
-- `serverName`: Specifies the server name in the object store.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::

web/versioned_docs/version-0.11.0/plugin-barman-cloud.v1.md

@@ -1,108 +0,0 @@
-# API Reference
-
-## Packages
-- [barmancloud.cnpg.io/v1](#barmancloudcnpgiov1)
-
-
-## barmancloud.cnpg.io/v1
-
-Package v1 contains API Schema definitions for the barmancloud v1 API group
-
-### Resource Types
-- [ObjectStore](#objectstore)
-
-
-
-#### InstanceSidecarConfiguration
-
-
-
-InstanceSidecarConfiguration defines the configuration for the sidecar that runs in the instance pods.
-
-
-
-_Appears in:_
-- [ObjectStoreSpec](#objectstorespec)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `env` _[EnvVar](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#envvar-v1-core) array_ | The environment to be explicitly passed to the sidecar |  |  |  |
-| `retentionPolicyIntervalSeconds` _integer_ | The retentionCheckInterval defines the frequency at which the<br />system checks and enforces retention policies. |  | 1800 |  |
-| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | Resources define cpu/memory requests and limits for the sidecar that runs in the instance pods. |  |  |  |
-| `additionalContainerArgs` _string array_ | AdditionalContainerArgs is an optional list of command-line arguments<br />to be passed to the sidecar container when it starts.<br />The provided arguments are appended to the container’s default arguments. |  |  |  |
-| `logLevel` _string_ | The log level for PostgreSQL instances. Valid values are: `error`, `warning`, `info` (default), `debug`, `trace` |  | info | Enum: [error warning info debug trace] <br /> |
-
-
-#### ObjectStore
-
-
-
-ObjectStore is the Schema for the objectstores API.
-
-
-
-
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `apiVersion` _string_ | `barmancloud.cnpg.io/v1` | True | | |
-| `kind` _string_ | `ObjectStore` | True | | |
-| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | True |  |  |
-| `spec` _[ObjectStoreSpec](#objectstorespec)_ | Specification of the desired behavior of the ObjectStore.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status | True |  |  |
-| `status` _[ObjectStoreStatus](#objectstorestatus)_ | Most recently observed status of the ObjectStore. This data may not be up to<br />date. Populated by the system. Read-only.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status |  |  |  |
-
-
-#### ObjectStoreSpec
-
-
-
-ObjectStoreSpec defines the desired state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `configuration` _[BarmanObjectStoreConfiguration](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration)_ | The configuration for the barman-cloud tool suite | True |  |  |
-| `retentionPolicy` _string_ | RetentionPolicy is the retention policy to be used for backups<br />and WALs (i.e. '60d'). The retention policy is expressed in the form<br />of `XXu` where `XX` is a positive integer and `u` is in `[dwm]` -<br />days, weeks, months. |  |  | Pattern: `^[1-9][0-9]*[dwm]$` <br /> |
-| `instanceSidecarConfiguration` _[InstanceSidecarConfiguration](#instancesidecarconfiguration)_ | The configuration for the sidecar that runs in the instance pods |  |  |  |
-
-
-#### ObjectStoreStatus
-
-
-
-ObjectStoreStatus defines the observed state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `serverRecoveryWindow` _object (keys:string, values:[RecoveryWindow](#recoverywindow))_ | ServerRecoveryWindow maps each server to its recovery window | True |  |  |
-
-
-#### RecoveryWindow
-
-
-
-RecoveryWindow represents the time span between the first
-recoverability point and the last successful backup of a PostgreSQL
-server, defining the period during which data can be restored.
-
-
-
-_Appears in:_
-- [ObjectStoreStatus](#objectstorestatus)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `firstRecoverabilityPoint` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The first recoverability point in a PostgreSQL server refers to<br />the earliest point in time to which the database can be<br />restored. | True |  |  |
-| `lastSuccessfulBackupTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The last successful backup time | True |  |  |
-| `lastFailedBackupTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The last failed backup time | True |  |  |
-
-

web/versioned_docs/version-0.11.0/resource-name-migration.md

@@ -1,219 +0,0 @@
----
-sidebar_position: 90
----
-
-# Resource name migration guide
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-:::warning
-Before proceeding with the migration process, please:
-1. **Read this guide in its entirety** to understand what changes will be made
-2. **Test in a non-production environment** first if possible
-3. **Ensure you have proper backups** of your cluster configuration
-
-This migration will delete old RBAC resources only after the
-`plugin-barman-cloud` upgrade. While the operation is designed to be safe, you
-should review and understand the changes before proceeding. The maintainers of
-this project are not responsible for any issues that may arise during
-migration.
-
-**Note:** This guide assumes you are using the default `cnpg-system` namespace.
-:::
-
-## Overview
-
-Starting from version **0.8.0**, the `plugin-barman-cloud` deployment manifests
-use more specific, prefixed resource names to avoid conflicts with other
-components deployed in the same Kubernetes cluster.
-
-## What Changed
-
-The following resources have been renamed to use proper prefixes.
-
-### Cluster-scoped Resources
-
-| Old Name                   | New Name                                 |
-|----------------------------|------------------------------------------|
-| `metrics-auth-role`        | `barman-plugin-metrics-auth-role`        |
-| `metrics-auth-rolebinding` | `barman-plugin-metrics-auth-rolebinding` |
-| `metrics-reader`           | `barman-plugin-metrics-reader`           |
-| `objectstore-viewer-role`  | `barman-plugin-objectstore-viewer-role`  |
-| `objectstore-editor-role`  | `barman-plugin-objectstore-editor-role`  |
-
-### Namespace-scoped Resources
-
-| Old Name                      | New Name                                    | Namespace     |
-|-------------------------------|---------------------------------------------|---------------|
-| `leader-election-role`        | `barman-plugin-leader-election-role`        | `cnpg-system` |
-| `leader-election-rolebinding` | `barman-plugin-leader-election-rolebinding` | `cnpg-system` |
-
-## Why This Change?
-
-Using generic names for cluster-wide resources is discouraged as they may
-conflict with other components deployed in the same cluster. The new names make
-it clear that these resources belong to the Barman Cloud plugin and help avoid
-naming collisions.
-
-## Migration Instructions
-
-This three steps migration process is straightforward and can be completed with
-a few `kubectl` commands.
-
-### Step 1: Upgrade plugin-barman-cloud
-
-Please refer to the [Installation](installation.mdx) section to deploy the new
-`plugin-barman-cloud` release.
-
-### Step 2: Delete Old Cluster-scoped Resources
-
-:::danger Verify Resources Before Deletion
-**IMPORTANT**: The old resource names are generic and could potentially belong
-to other components in your cluster.
-
-**Before deleting each resource, verify it belongs to the Barman Cloud plugin
-by checking:**
-- For `objectstore-*` roles: Look for `barmancloud.cnpg.io` in the API groups
-- For `metrics-*` roles: Check if they reference the `plugin-barman-cloud`
-  ServiceAccount in `cnpg-system` namespace
-- For other roles: Look for labels like `app.kubernetes.io/name: plugin-barman-cloud`
-
-If a resource doesn't have these indicators, **DO NOT DELETE IT** as it may
-belong to another application.
-
-Carefully review the output of each verification command before proceeding with
-the `delete`.
-:::
-
-:::tip Dry Run First
-You can add `--dry-run=client` to any `kubectl delete` command to preview what
-would be deleted without actually removing anything.
-:::
-
-**Only proceed if you've verified these resources belong to the Barman Cloud
-plugin (see warning above).**
-
-For each resource below, first verify it belongs to Barman Cloud, then delete
-it:
-
-```bash
-# 1. Check metrics-auth-rolebinding FIRST (we'll check the role after)
-# Look for references to plugin-barman-cloud ServiceAccount
-kubectl describe clusterrolebinding metrics-auth-rolebinding
-# If it references plugin-barman-cloud ServiceAccount in cnpg-system namespace,
-# delete it:
-kubectl delete clusterrolebinding metrics-auth-rolebinding
-
-# 2. Check metrics-auth-role
-# Look for references to authentication.k8s.io and authorization.k8s.io
-kubectl describe clusterrole metrics-auth-role
-# Verify it's not being used by any other rolebindings:
-kubectl get clusterrolebinding -o json \
-  | jq -r '.items[] | select(.roleRef.name=="metrics-auth-role") \
-  | .metadata.name'
-# If the above returns nothing (role is not in use) and the role looks like the
-# Barman Cloud one, delete it (see warnings section):
-kubectl delete clusterrole metrics-auth-role
-
-# 3. Check objectstore-viewer-role
-# Look for barmancloud.cnpg.io API group or
-# for `app.kubernetes.io/name: plugin-barman-cloud` label
-kubectl describe clusterrole objectstore-viewer-role
-# If it shows barmancloud.cnpg.io in API groups, delete it:
-kubectl delete clusterrole objectstore-viewer-role
-
-# 4. Check objectstore-editor-role
-# Look for barmancloud.cnpg.io API group or
-# for `app.kubernetes.io/name: plugin-barman-cloud` label
-kubectl describe clusterrole objectstore-editor-role
-# If it shows barmancloud.cnpg.io in API groups, delete it:
-kubectl delete clusterrole objectstore-editor-role
-
-# 5. Check metrics-reader (MOST DANGEROUS - very generic name)
-# First, check if it's being used by any rolebindings OTHER than barman's:
-kubectl get clusterrolebinding -o json | jq -r '.items[] \
-  | select(.roleRef.name=="metrics-reader") \
-  | "\(.metadata.name) -> \(.subjects[0].name) in \(.subjects[0].namespace)"'
-# If this shows ANY rolebindings, review them carefully. Only proceed if
-# they're all Barman-related.  Then check the role itself:
-kubectl describe clusterrole metrics-reader
-# If it ONLY has nonResourceURLs: /metrics and NO other rolebindings use it,
-# delete it:
-kubectl delete clusterrole metrics-reader
-```
-
-:::warning
-The `metrics-reader` role is particularly dangerous to delete blindly. Many
-monitoring systems use this exact name. Only delete it if:
-
-1. You've verified it ONLY grants access to `/metrics`
-2. No other rolebindings reference it (checked with the jq command above)
-3. You're certain it was created by the Barman Cloud plugin
-
-If you're unsure, it's safer to leave it and let the new
-`barman-plugin-metrics-reader` role coexist with it.
-:::
-
-If any resource is not found during the `describe` command, that's okay - it
-means it was never created or already deleted. Simply skip the delete command
-for that resource.
-
-### Step 3: Delete Old Namespace-scoped Resources
-
-Delete the old namespace-scoped resources in the `cnpg-system` namespace:
-
-```bash
-# Delete the old leader-election resources
-kubectl delete role leader-election-role -n cnpg-system
-kubectl delete rolebinding leader-election-rolebinding -n cnpg-system
-```
-
-If any resource is not found, that's okay - it means it was never created or
-already deleted.
-
-## Impact
-
-- **Permissions:** If you have custom RBAC rules or tools that reference the
-  old resource names, they will need to be updated.
-- **External Users:** If end users have been granted the
-  `objectstore-viewer-role` or `objectstore-editor-role`, they will need to be
-  re-granted the new role names (`barman-plugin-objectstore-viewer-role` and
-  `barman-plugin-objectstore-editor-role`).
-
-## Verification
-
-After migration, verify that the new resources are created:
-
-```bash
-# Check cluster-scoped resources
-kubectl get clusterrole | grep barman
-kubectl get clusterrolebinding | grep barman
-
-# Check namespace-scoped resources
-kubectl get role,rolebinding -n cnpg-system | grep barman
-```
-
-You should see the new prefixed resource names.
-
-## Troubleshooting
-
-### Plugin Not Starting After Migration
-
-If the plugin fails to start after migration, check:
-
-1. **ServiceAccount permissions:** Ensure the `plugin-barman-cloud` ServiceAccount is bound to the new roles:
-   ```bash
-   kubectl get clusterrolebinding barman-plugin-metrics-auth-rolebinding -o yaml
-   kubectl get rolebinding barman-plugin-leader-election-rolebinding -n cnpg-system -o yaml
-   ```
-
-2. **Role references:** Verify that the rolebindings reference the correct role names:
-   ```bash
-   kubectl describe rolebinding barman-plugin-leader-election-rolebinding -n cnpg-system
-   kubectl describe clusterrolebinding barman-plugin-metrics-auth-rolebinding
-   ```
-
-## Support
-
-If you encounter issues during migration, please open an issue on the [GitHub
-repository](https://github.com/cloudnative-pg/plugin-barman-cloud/issues).

web/versioned_docs/version-0.11.0/retention.md

@@ -1,38 +0,0 @@
----
-sidebar_position: 60
----
-
-# Retention Policies
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin supports **automated cleanup of obsolete backups** via
-retention policies, configured in the `.spec.retentionPolicy` field of the
-`ObjectStore` resource.
-
-:::note
-This feature uses the `barman-cloud-backup-delete` command with the
-`--retention-policy "RECOVERY WINDOW OF {{ value }} {{ unit }}"` syntax.
-:::
-
-#### Example: 30-Day Retention Policy
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  [...]
-  retentionPolicy: "30d"
-````
-
-:::note
-A **recovery window retention policy** ensures the cluster can be restored to
-any point in time between the calculated *Point of Recoverability* (PoR) and
-the latest WAL archive. The PoR is defined as `current time - recovery window`.
-The **first valid backup** is the most recent backup completed before the PoR.
-Backups older than that are marked as *obsolete* and deleted after the next
-backup completes.
-:::
-

web/versioned_docs/version-0.11.0/troubleshooting.md

@@ -1,591 +0,0 @@
----
-sidebar_position: 90
----
-
-# Troubleshooting
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-This guide helps you diagnose and resolve common issues with the Barman Cloud
-plugin.
-
-:::important
-We are continuously improving the integration between CloudNativePG and the
-Barman Cloud plugin as it moves toward greater stability and maturity. For this
-reason, we recommend using the latest available version of both components.
-See the [*Requirements* section](intro.md#requirements) for details.
-:::
-
-:::note
-The following commands assume you installed the CloudNativePG operator in
-the default `cnpg-system` namespace. If you installed it in a different
-namespace, adjust the commands accordingly.
-:::
-
-## Viewing Logs
-
-To troubleshoot effectively, you’ll often need to review logs from multiple
-sources:
-
-```sh
-# View operator logs (includes plugin interaction logs)
-kubectl logs -n cnpg-system deployment/cnpg-controller-manager -f
-
-# View plugin manager logs
-kubectl logs -n cnpg-system deployment/barman-cloud -f
-
-# View sidecar container logs (Barman Cloud operations)
-kubectl logs -n <namespace> <cluster-pod-name> -c plugin-barman-cloud -f
-
-# View all containers in a pod
-kubectl logs -n <namespace> <cluster-pod-name> --all-containers=true
-
-# View previous container logs (if container restarted)
-kubectl logs -n <namespace> <cluster-pod-name> -c plugin-barman-cloud --previous
-```
-
-## Common Issues
-
-### Plugin Installation Issues
-
-#### Plugin pods not starting
-
-**Symptoms:**
-
-- Plugin pods stuck in `CrashLoopBackOff` or `Error`
-- Plugin deployment not ready
-
-**Possible causes and solutions:**
-
-1. **Certificate issues**
-
-   ```sh
-   # Check if cert-manager is installed and running
-   kubectl get pods -n cert-manager
-
-   # Check if the plugin certificate is created
-   kubectl get certificates -n cnpg-system
-   ```
-
-   If cert-manager is not installed, install it first:
-
-   ```sh
-   # Note: other installation methods for cert-manager are available
-   kubectl apply -f \
-     https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml
-   ```
-
-   If you are using your own certificates without cert-manager, you will need
-   to verify the entire certificate chain yourself.
-
-
-2. **Image pull errors**
-
-   ```sh
-   # Check pod events for image pull errors
-   kubectl describe pod -n cnpg-system -l app=barman-cloud
-   ```
-
-   Verify the image exists and you have proper credentials if using a private
-   registry.
-
-
-3. **Resource constraints**
-
-   ```sh
-   # Check node resources
-   kubectl top nodes
-   kubectl describe nodes
-   ```
-
-   Make sure your cluster has sufficient CPU and memory resources.
-
-### Backup Failures
-
-#### Quick Backup Troubleshooting Checklist
-
-When a backup fails, follow these steps in order:
-
-1. **Check backup status**:
-
-   ```sh
-   kubectl get backups.postgresql.cnpg.io -n <namespace>
-   ```
-2. **Get error details and target pod**:
-
-   ```sh
-   kubectl describe backups.postgresql.cnpg.io \
-     -n <namespace> <backup-name>
-
-   kubectl get backups.postgresql.cnpg.io \
-     -n <namespace> <backup-name> \
-     -o jsonpath='{.status.instanceID.podName}'
-   ```
-3. **Check the target pod’s sidecar logs**:
-
-   ```sh
-   TARGET_POD=$(kubectl get backups.postgresql.cnpg.io \
-     -n <namespace> <backup-name> \
-     -o jsonpath='{.status.instanceID.podName}')
-
-   kubectl logs \
-     -n <namespace> $TARGET_POD -c plugin-barman-cloud \
-     --tail=100 | grep -E "ERROR|FATAL|panic"
-   ```
-4. **Check cluster events**:
-
-   ```sh
-   kubectl get events -n <namespace> \
-     --field-selector involvedObject.name=<cluster-name> \
-     --sort-by='.lastTimestamp'
-   ```
-5. **Verify plugin is running**:
-
-   ```sh
-   kubectl get pods \
-     -n cnpg-system -l app=barman-cloud
-   ```
-6. **Check operator logs**:
-
-   ```sh
-   kubectl logs \
-     -n cnpg-system deployment/cnpg-controller-manager \
-     --tail=100 | grep -i "backup\|plugin"
-   ```
-7. **Check plugin manager logs**:
-
-   ```sh
-   kubectl logs \
-     -n cnpg-system deployment/barman-cloud --tail=100
-   ```
-
-#### Backup job fails immediately
-
-**Symptoms:**
-
-- Backup pods terminate with error
-- No backup files appear in object storage
-- Backup shows `failed` phase with various error messages
-
-**Common failure modes and solutions:**
-
-1. **"requested plugin is not available" errors**
-
-   ```
-   requested plugin is not available: barman
-   requested plugin is not available: barman-cloud
-   requested plugin is not available: barman-cloud.cloudnative-pg.io
-   ```
-   
-   **Cause:** The plugin name in the Cluster configuration doesn’t match the
-   deployed plugin, or the plugin isn’t registered.
-   
-   **Solution:** 
-   
-   a. **Check plugin registration:**
-
-   ```sh
-   # If you have the `cnpg` plugin installed (v1.27.0+)
-   kubectl cnpg status -n <namespace> <cluster-name>
-   ```
-   
-   Look for the "Plugins status" section:
-   ```
-   Plugins status
-   Name                            Version  Status  Reported Operator Capabilities
-   ----                            -------  ------  ------------------------------
-   barman-cloud.cloudnative-pg.io  0.6.0    N/A     Reconciler Hooks, Lifecycle Service
-   ```
-   
-   b. **Verify plugin name in `Cluster` spec**:
-
-   ```yaml
-   apiVersion: postgresql.cnpg.io/v1
-   kind: Cluster
-   spec:
-     plugins:
-       - name: barman-cloud.cloudnative-pg.io
-         parameters:
-           barmanObjectName: <your-objectstore-name>
-   ```
-   
-   c. **Check plugin deployment is running**:
-
-   ```sh
-   kubectl get deployment -n cnpg-system barman-cloud
-   ```
-
-2. **"rpc error: code = Unknown desc = panic caught: assignment to entry in nil map" errors**
-   
-   **Cause:** Misconfiguration in the `ObjectStore` (e.g., typo or missing field).
-   
-   **Solution:** 
-
-   - Review sidecar logs for details
-   - Verify `ObjectStore` configuration and secrets
-   - Common issues include:
-     - Missing or incorrect secret references
-     - Typos in configuration parameters
-     - Missing required environment variables in secrets
-
-#### Backup performance issues
-
-**Symptoms:**
-
-- Backups take extremely long
-- Backups timeout
-
-**Plugin-specific considerations:**
-
-1. **Check `ObjectStore` parallelism settings**
-   - Adjust `maxParallel` in `ObjectStore` configuration
-   - Monitor sidecar container resource usage during backups
-
-2. **Verify plugin resource allocation**
-   - Check if the sidecar container has sufficient CPU/memory
-   - Review plugin container logs for resource-related warnings
-
-:::tip
-For Barman-specific features like compression, encryption, and performance
-tuning, refer to the [Barman documentation](https://docs.pgbarman.org/latest/).
-:::
-
-### WAL Archiving Issues
-
-#### WAL archiving stops
-
-**Symptoms:**
-
-- WAL files accumulate on the primary
-- Cluster shows WAL archiving warnings
-- Sidecar logs show WAL errors
-
-**Debugging steps:**
-
-1. **Check plugin sidecar logs for WAL archiving errors**
-   ```sh
-   # Check recent WAL archive operations in sidecar
-   kubectl logs -n <namespace> <primary-pod> -c plugin-barman-cloud \
-     --tail=50 | grep -i wal
-   ```
-
-2. **Check ObjectStore configuration for WAL settings**
-   - Ensure ObjectStore has proper WAL retention settings
-   - Verify credentials have permissions for WAL operations
-
-### Restore Issues
-
-#### Restore fails during recovery
-
-**Symptoms:**
-
-- New cluster stuck in recovery
-- Plugin sidecar shows restore errors
-- PostgreSQL won’t start
-
-**Debugging steps:**
-
-1. **Check plugin sidecar logs during restore**
-
-   ```sh
-   # Check the sidecar logs on the recovering cluster pods
-   kubectl logs -n <namespace> <cluster-pod-name> \
-     -c plugin-barman-cloud --tail=100
-   
-   # Look for restore-related errors
-   kubectl logs -n <namespace> <cluster-pod-name> \
-     -c plugin-barman-cloud | grep -E "restore|recovery|ERROR"
-   ```
-
-2. **Verify plugin can access backups**
-
-   ```sh
-   # Check if `ObjectStore` is properly configured for restore
-   kubectl get objectstores.barmancloud.cnpg.io \
-     -n <namespace> <objectstore-name> -o yaml
-   
-   # Check PostgreSQL recovery logs
-   kubectl logs -n <namespace> <cluster-pod> \
-     -c postgres | grep -i recovery
-   ```
-
-:::tip
-For detailed Barman restore operations and troubleshooting, refer to the
-[Barman documentation](https://docs.pgbarman.org/latest/barman-cloud-restore.html).
-:::
-
-#### Point-in-time recovery (PITR) configuration issues
-
-**Symptoms:**
-
-- PITR doesn’t reach target time
-- WAL access errors
-- Recovery halts early
-
-**Debugging steps:**
-
-1. **Verify PITR configuration in the `Cluster` spec**
-
-   ```yaml
-   apiVersion: postgresql.cnpg.io/v1
-   kind: Cluster
-   metadata:
-     name: <cluster-restore-name>
-   spec:
-     storage:
-       size: 1Gi
-
-     bootstrap:
-       recovery:
-         source: origin
-         recoveryTarget:
-           targetTime: "2024-01-15T10:30:00Z"
-
-     externalClusters:
-       - name: origin
-         plugin:
-           enabled: true
-           name: barman-cloud.cloudnative-pg.io
-           parameters:
-             barmanObjectName: <object-store-name>
-             serverName: <source-cluster-name>
-   ```
-
-2. **Check sidecar logs for WAL-related errors**
-
-   ```sh
-   kubectl logs -n <namespace> <cluster-pod> \
-     -c plugin-barman-cloud | grep -i wal
-   ```
-
-:::note
-Timestamps without an explicit timezone suffix
-(e.g., `2024-01-15 10:30:00`) are interpreted as UTC.
-:::
-
-:::warning
-Always specify an explicit timezone in your timestamp to avoid ambiguity.
-For example, use `2024-01-15T10:30:00Z` or `2024-01-15T10:30:00+02:00`
-instead of `2024-01-15 10:30:00`.
-:::
-
-:::note
-For detailed PITR configuration and WAL management, see the
-[Barman PITR documentation](https://docs.pgbarman.org/latest/).
-:::
-
-### Plugin Configuration Issues
-
-#### Plugin cannot connect to object storage
-
-**Symptoms:**
-
-- Sidecar logs show connection errors
-- Backups fail with authentication or network errors
-- `ObjectStore` resource reports errors
-
-**Solution:**
-
-1. **Verify `ObjectStore` CRD configuration and secrets**
-
-   ```sh
-   # Check ObjectStore resource status
-   kubectl get objectstores.barmancloud.cnpg.io \
-     -n <namespace> <objectstore-name> -o yaml
-   
-   # Verify the secret exists and has correct keys for your provider
-   kubectl get secret -n <namespace> <secret-name> \
-     -o jsonpath='{.data}' | jq 'keys'
-   ```
-
-2. **Check sidecar logs for connectivity issues**
-   ```sh
-   kubectl logs -n <namespace> <cluster-pod> \
-     -c plugin-barman-cloud | grep -E "connect|timeout|SSL|cert"
-   ```
-
-3. **Adjust provider-specific settings (endpoint, path style, etc.)**
-   - See [Object Store Configuration](object_stores.md) for provider-specific settings
-   - Ensure `endpointURL` is set correctly for your storage provider
-   - Verify network policies allow egress to your storage provider
-
-## Diagnostic Commands
-
-### Using the `cnpg` plugin for `kubectl`
-
-The `cnpg` plugin for `kubectl` provides extended debugging capabilities.
-Keep it updated:
-
-```sh
-# Install or update the `cnpg` plugin
-kubectl krew install cnpg
-# Or using an alternative method: https://cloudnative-pg.io/documentation/current/kubectl-plugin/#install
-
-# Check plugin status (requires CNPG 1.27.0+)
-kubectl cnpg status <cluster-name> -n <namespace>
-
-# View cluster status in detail
-kubectl cnpg status <cluster-name> -n <namespace> --verbose
-```
-
-## Getting Help
-
-If problems persist:
-
-1. **Check the documentation**
-
-   - [Installation Guide](installation.mdx)
-   - [Object Store Configuration](object_stores.md) (for provider-specific settings)
-   - [Usage Examples](usage.md)
-
-
-2. **Gather diagnostic information**
-
-   ```sh
-   # Create a diagnostic bundle (⚠️ sanitize these before sharing!)
-   kubectl get objectstores.barmancloud.cnpg.io -A -o yaml > /tmp/objectstores.yaml
-   kubectl get clusters.postgresql.cnpg.io -A -o yaml > /tmp/clusters.yaml
-   kubectl logs -n cnpg-system deployment/barman-cloud --tail=1000 > /tmp/plugin.log
-   ```
-
-
-3. **Community support**
-
-   - CloudNativePG Slack: [#cloudnativepg-users](https://cloud-native.slack.com/messages/cloudnativepg-users)
-   - GitHub Issues: [plugin-barman-cloud](https://github.com/cloudnative-pg/plugin-barman-cloud/issues)
-
-
-4. **Include when reporting**
-
-   - CloudNativePG version
-   - Plugin version
-   - Kubernetes version
-   - Cloud provider and region
-   - Relevant configuration (⚠️ sanitize/redact sensitive information)
-   - Error messages and logs
-   - Steps to reproduce
-
-## Known Issues and Limitations
-
-### Current Known Issues
-
-1. **Migration compatibility**: After migrating from in-tree backup to the
-   plugin, the `kubectl cnpg backup` command syntax has changed
-   ([#353](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/353)):
-
-   ```sh
-   # Old command (in-tree, no longer works after migration)
-   kubectl cnpg backup -n <namespace> <cluster-name> \
-     --method=barmanObjectStore
-   
-   # New command (plugin-based)
-   kubectl cnpg backup -n <namespace> <cluster-name> \
-     --method=plugin --plugin-name=barman-cloud.cloudnative-pg.io
-   ```
-
-### Plugin Limitations
-
-1. **Installation method**: Currently only supports manifest and Kustomize
-   installation ([#351](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/351) -
-   Helm chart requested)
-
-2. **Sidecar resource sharing**: The plugin sidecar container shares pod
-   resources with PostgreSQL
-
-3. **Plugin restart behavior**: Restarting the sidecar container requires
-   restarting the entire PostgreSQL pod
-
-## Recap of General Debugging Steps
-
-### Check Backup Status and Identify the Target Instance
-
-```sh
-# List all backups and their status
-kubectl get backups.postgresql.cnpg.io -n <namespace>
-
-# Get detailed backup information including error messages and target instance
-kubectl describe backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name>
-
-# Extract the target pod name from a failed backup
-kubectl get backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name> \
-  -o jsonpath='{.status.instanceID.podName}'
-
-# Get more details including the target pod, method, phase, and error
-kubectl get backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name> \
-  -o jsonpath='Pod: {.status.instanceID.podName}{"\n"}Method: {.status.method}{"\n"}Phase: {.status.phase}{"\n"}Error: {.status.error}{"\n"}'
-
-# Check the cluster status for backup-related information
-kubectl cnpg status <cluster-name> -n <namespace> --verbose
-```
-
-### Check Sidecar Logs on the Backup Target Pod
-
-```sh
-# Identify which pod was the backup target (from the previous step)
-TARGET_POD=$(kubectl get backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name> \
-  -o jsonpath='{.status.instanceID.podName}')
-echo "Backup target pod: $TARGET_POD"
-
-# Check the sidecar logs on the specific target pod
-kubectl logs -n <namespace> $TARGET_POD \
-  -c plugin-barman-cloud --tail=100
-
-# Follow the logs in real time
-kubectl logs -n <namespace> $TARGET_POD \
-  -c plugin-barman-cloud -f
-
-# Check for specific errors in the target pod around the backup time
-kubectl logs -n <namespace> $TARGET_POD \
-  -c plugin-barman-cloud --since=10m | grep -E "ERROR|FATAL|panic|failed"
-
-# Alternative: List all cluster pods and their roles
-kubectl get pods -n <namespace> -l cnpg.io/cluster=<cluster-name> \
-  -o custom-columns=NAME:.metadata.name,ROLE:.metadata.labels.cnpg\\.io/instanceRole,INSTANCE:.metadata.labels.cnpg\\.io/instanceName
-
-# Check sidecar logs on ALL cluster pods (if the target is unclear)
-for pod in $(kubectl get pods -n <namespace> -l cnpg.io/cluster=<cluster-name> -o name); do
-  echo "=== Checking $pod ==="
-  kubectl logs -n <namespace> $pod -c plugin-barman-cloud \
-    --tail=20 | grep -i error || echo "No errors found"
-done
-```
-
-### Check Events for Backup-Related Issues
-
-```sh
-# Check events for the cluster
-kubectl get events -n <namespace> \
-  --field-selector involvedObject.name=<cluster-name>
-
-# Check events for failed backups
-kubectl get events -n <namespace> \
-  --field-selector involvedObject.kind=Backup
-
-# Get all recent events in the namespace
-kubectl get events -n <namespace> --sort-by='.lastTimestamp' | tail -20
-```
-
-### Verify `ObjectStore` Configuration
-
-```sh
-# Check the ObjectStore resource
-kubectl get objectstores.barmancloud.cnpg.io \
-  -n <namespace> <objectstore-name> -o yaml
-
-# Verify the secret exists and has the correct keys
-kubectl get secret -n <namespace> <secret-name> -o yaml
-# Alternatively
-kubectl get secret -n <namespace> <secret-name> -o jsonpath='{.data}' | jq 'keys'
-```
-
-### Common Error Messages and Solutions
-
-* **"AccessDenied" or "403 Forbidden"** — Check cloud credentials and bucket permissions.
-* **"NoSuchBucket"** — Verify the bucket exists and the endpoint URL is correct.
-* **"Connection timeout"** — Check network connectivity and firewall rules.
-* **"SSL certificate problem"** — For self-signed certificates, verify the CA bundle configuration.
-

web/versioned_docs/version-0.11.0/upgrades.mdx

@@ -1,16 +0,0 @@
----
-sidebar_position: 25
----
-
-# Upgrades
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-You can upgrade the plugin simply by installing the new version. Unless
-explicitly stated below or in the release notes, no special steps are required.
-
-## Upgrading to version 0.8.x from previous versions
-
-Version **0.8.0** introduces breaking changes to resource naming.
-To complete the upgrade successfully, follow the instructions in the
-["Resource name migration guide"](resource-name-migration.md).

web/versioned_docs/version-0.11.0/usage.md

@@ -1,283 +0,0 @@
----
-sidebar_position: 30
----
-
-# Using the Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-After [installing the plugin](installation.mdx) in the same namespace as the
-CloudNativePG operator, enabling your PostgreSQL cluster to use the Barman
-Cloud Plugin involves just a few steps:
-
-- Defining the object store containing your WAL archive and base backups, using
-  your preferred [provider](object_stores.md)
-- Instructing the Postgres cluster to use the Barman Cloud Plugin
-
-From that moment, you’ll be able to issue on-demand backups or define a backup
-schedule, as well as rely on the object store for recovery operations.
-
-The rest of this page details each step, using MinIO as object store provider.
-
-## Defining the `ObjectStore`
-
-An `ObjectStore` resource must be created for each object store used in your
-PostgreSQL architecture. Here's an example configuration using MinIO:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-The `.spec.configuration` schema follows the same format as the
-[in-tree barman-cloud support](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration).
-Refer to [the CloudNativePG documentation](https://cloudnative-pg.io/documentation/current/appendixes/backup_barmanobjectstore/)
-for additional details.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::
-
-## Configuring WAL Archiving
-
-Once the `ObjectStore` is defined, you can configure your PostgreSQL cluster
-to archive WALs by referencing the store in the `.spec.plugins` section:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  instances: 3
-  imagePullPolicy: Always
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store
-  storage:
-    size: 1Gi
-```
-
-This configuration enables both WAL archiving and data directory backups.
-
-## Performing a Base Backup
-
-Once WAL archiving is enabled, the cluster is ready for backups. Backups can be
-created either declaratively (with YAML manifests) or imperatively (with the
-`cnpg` plugin).
-
-### Declarative approach (YAML manifest)
-
-Create a backup resource by applying a YAML manifest:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Backup
-metadata:
-  name: backup-example
-spec:
-  cluster:
-    name: cluster-example
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
-### Imperative approach (using the `cnpg` plugin)
-
-The quickest way to trigger an on-demand backup is with the `cnpg` plugin:
-
-```bash
-kubectl cnpg backup -n <namespace> <cluster-name> \
-  --method=plugin \
-  --plugin-name=barman-cloud.cloudnative-pg.io
-```
-
-:::note Migration from in-tree backups
-If you are migrating from the in-tree backup system, note the change in syntax:
-
-```bash
-# Old command (in-tree backup)
-kubectl cnpg backup -n <namespace> <cluster-name> --method=barmanObjectStore
-
-# New command (plugin-based backup)
-kubectl cnpg backup -n <namespace> <cluster-name> \
-  --method=plugin \
-  --plugin-name=barman-cloud.cloudnative-pg.io
-```
-:::
-
-## Restoring a Cluster
-
-To restore a cluster from an object store, create a new `Cluster` resource that
-references the store containing the backup. Below is an example configuration:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-:::important
-The above configuration does **not** enable WAL archiving for the restored cluster.
-:::
-
-To enable WAL archiving for the restored cluster, include the `.spec.plugins`
-section alongside the `externalClusters.plugin` section, as shown below:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      # Backup Object Store (push, read-write)
-      barmanObjectName: minio-store-bis
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        # Recovery Object Store (pull, read-only)
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-The same object store may be used for both transaction log archiving and
-restoring a cluster, or you can configure separate stores for these purposes.
-
-## Configuring Replica Clusters
-
-You can set up a distributed topology by combining the previously defined
-configurations with the `.spec.replica` section. Below is an example of how to
-define a replica cluster:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-dc-a
-spec:
-  instances: 3
-  primaryUpdateStrategy: unsupervised
-
-  storage:
-    storageClass: csi-hostpath-sc
-    size: 1Gi
-
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store-a
-
-  replica:
-    self: cluster-dc-a
-    primary: cluster-dc-a
-    source: cluster-dc-b
-
-  externalClusters:
-  - name: cluster-dc-a
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-a
-
-  - name: cluster-dc-b
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-b
-```
-
-## Configuring the plugin instance sidecar
-
-The Barman Cloud Plugin runs as a sidecar container next to each PostgreSQL
-instance pod. It manages backup, WAL archiving, and restore processes.
-
-Configuration comes from multiple `ObjectStore` resources:
-
-1. The one referenced in the
-   `.spec.plugins` section of the `Cluster`. This is the
-   object store used for WAL archiving and base backups.
-2. The one referenced in the external cluster
-   used in the `.spec.replica.source` section of the `Cluster`. This is
-   used by the log-shipping designated primary to get the WAL files.
-3. The one referenced in the
-   `.spec.bootstrap.recovery.source` section of the `Cluster`. Used by
-   the initial recovery job to create the cluster from an existing backup.
-
-You can fine-tune sidecar behavior in the `.spec.instanceSidecarConfiguration`
-of your ObjectStore. These settings apply to all PostgreSQL instances that use
-this object store. Any updates take effect at the next `Cluster` reconciliation,
-and could generate a rollout of the `Cluster`.
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-  # [...]
-  instanceSidecarConfiguration:
-    retentionPolicyIntervalSeconds: 1800
-    resources:
-      requests:
-        memory: "XXX"
-        cpu: "YYY"
-      limits:
-        memory: "XXX"
-        cpu: "YYY"
-```
-
-:::note
-If more than one `ObjectStore` applies, the `instanceSidecarConfiguration` of
-the one set in `.spec.plugins` has priority.
-:::

web/versioned_docs/version-0.12.0/compression.md

@@ -1,43 +0,0 @@
----
-sidebar_position: 80
----
-
-# Compression
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-By default, backups and WAL files are archived **uncompressed**. However, the
-Barman Cloud Plugin supports multiple compression algorithms via
-`barman-cloud-backup` and `barman-cloud-wal-archive`, allowing you to optimize
-for space, speed, or a balance of both.
-
-### Supported Compression Algorithms
-
-- `bzip2`
-- `gzip`
-- `lz4` (WAL only)
-- `snappy`
-- `xz` (WAL only)
-- `zstd` (WAL only)
-
-Compression settings for base backups and WAL archives are configured
-independently. For implementation details, refer to the corresponding API
-definitions:
-
-- [`DataBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#DataBackupConfiguration)
-- [`WALBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#WalBackupConfiguration)
-
-:::important
-Compression impacts both performance and storage efficiency. Choose the right
-algorithm based on your recovery time objectives (RTO), storage capacity, and
-network throughput.
-:::
-
-## Compression Benchmark (on MinIO)
-
-| Compression | Backup Time (ms) | Restore Time (ms) | Uncompressed Size (MB) | Compressed Size (MB) | Ratio |
-| ----------- | ---------------- | ----------------- | ---------------------- | -------------------- | ----- |
-| None        | 10,927           | 7,553             | 395                    | 395                  | 1.0:1 |
-| bzip2       | 25,404           | 13,886            | 395                    | 67                   | 5.9:1 |
-| gzip        | 116,281          | 3,077             | 395                    | 91                   | 4.3:1 |
-| snappy      | 8,134            | 8,341             | 395                    | 166                  | 2.4:1 |

web/versioned_docs/version-0.12.0/concepts.md

@@ -1,177 +0,0 @@
----
-sidebar_position: 10
----
-
-# Main Concepts
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-:::important
-Before proceeding, make sure to review the following sections of the
-CloudNativePG documentation:
-
-- [**Backup**](https://cloudnative-pg.io/documentation/current/backup/)
-- [**WAL Archiving**](https://cloudnative-pg.io/documentation/current/wal_archiving/)
-- [**Recovery**](https://cloudnative-pg.io/documentation/current/recovery/)
-:::
-
-The **Barman Cloud Plugin** enables **hot (online) backups** of PostgreSQL
-clusters in CloudNativePG through [`barman-cloud`](https://pgbarman.org),
-supporting continuous physical backups and WAL archiving to an **object
-store**—without interrupting write operations.
-
-It also supports both **full recovery** and **Point-in-Time Recovery (PITR)**
-of a PostgreSQL cluster.
-
-## The Object Store
-
-At the core is the [`ObjectStore` custom resource (CRD)](plugin-barman-cloud.v1.md#objectstorespec),
-which acts as the interface between the PostgreSQL cluster and the target
-object storage system. It allows you to configure:
-
-- **Authentication and bucket location** via the `.spec.configuration` section
-- **WAL archiving** settings—such as compression type, parallelism, and
-  server-side encryption—under `.spec.configuration.wal`
-- **Base backup options**—with similar settings for compression, concurrency,
-  and encryption—under `.spec.configuration.data`
-- **Retention policies** to manage the life-cycle of archived WALs and backups
-  via `.spec.configuration.retentionPolicy`
-
-WAL files are archived in the `wals` directory, while base backups are stored
-as **tarballs** in the `base` directory, following the
-[Barman Cloud convention](https://docs.pgbarman.org/cloud/latest/usage/#object-store-layout).
-
-The plugin also offers advanced capabilities, including
-[backup tagging](misc.md#backup-object-tagging) and
-[extra options for backups and WAL archiving](misc.md#extra-options-for-backup-and-wal-archiving).
-
-:::tip
-For details, refer to the
-[API reference for the `ObjectStore` resource](plugin-barman-cloud.v1.md#objectstorespec).
-:::
-
-## Integration with a CloudNativePG Cluster
-
-CloudNativePG can delegate continuous backup and recovery responsibilities to
-the **Barman Cloud Plugin** by configuring the `.spec.plugins` section of a
-`Cluster` resource. This setup requires a corresponding `ObjectStore` resource
-to be defined.
-
-:::important
-While it is technically possible to reuse the same `ObjectStore` for multiple
-`Cluster` resources within the same namespace, it is strongly recommended to
-dedicate one object store per PostgreSQL cluster to ensure data isolation and
-operational clarity.
-:::
-
-The following example demonstrates how to configure a CloudNativePG cluster
-named `cluster-example` to use a previously defined `ObjectStore` (also named
-`cluster-example`) in the same namespace. Setting `isWALArchiver: true` enables
-WAL archiving through the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  # Other cluster settings...
-  plugins:
-    - name: barman-cloud.cloudnative-pg.io
-      isWALArchiver: true
-      parameters:
-        barmanObjectName: cluster-example
-```
-
-## Backup of a Postgres Cluster
-
-Once the object store is defined and the `Cluster` is configured to use the
-Barman Cloud Plugin, **WAL archiving is activated immediately** on the
-PostgreSQL primary.
-
-Physical base backups are seamlessly managed by CloudNativePG using the
-`Backup` and `ScheduledBackup` resources, respectively for
-[on-demand](https://cloudnative-pg.io/documentation/current/backup/#on-demand-backups)
-and
-[scheduled](https://cloudnative-pg.io/documentation/current/backup/#scheduled-backups)
-backups.
-
-To use the Barman Cloud Plugin, you must set the `method` to `plugin` and
-configure the `pluginConfiguration` section as shown:
-
-```yaml
-[...]
-spec:
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-  [...]
-```
-
-With this configuration, CloudNativePG supports:
-
-- Backups from both **primary** and **standby** instances
-- Backups from **designated primaries** in a distributed topology using
-  [replica clusters](https://cloudnative-pg.io/documentation/current/replica_cluster/)
-
-:::tip
-For details on how to back up from a standby, refer to the official documentation:
-[Backup from a standby](https://cloudnative-pg.io/documentation/current/backup/#backup-from-a-standby).
-:::
-
-:::important
-Both backup and WAL archiving operations are executed by sidecar containers
-running in the same pod as the PostgreSQL `Cluster` primary instance—except
-when backups are taken from a standby, in which case the sidecar runs alongside
-the standby pod.
-The sidecar containers use a [dedicated container image](images.md) that
-includes only the supported version of Barman Cloud.
-:::
-
-## Recovery of a Postgres Cluster
-
-In PostgreSQL, *recovery* refers to the process of starting a database instance
-from an existing backup.  The Barman Cloud Plugin integrates with CloudNativePG
-to support both **full recovery** and **Point-in-Time Recovery (PITR)** from an
-object store.
-
-Recovery in this context is *not in-place*: it bootstraps a brand-new
-PostgreSQL cluster from a backup and replays the necessary WAL files to reach
-the desired recovery target.
-
-To perform a recovery, define an *external cluster* that references the
-appropriate `ObjectStore`, and use it as the source in the `bootstrap` section
-of the target cluster:
-
-```yaml
-[...]
-spec:
-  [...]
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: cluster-example
-        serverName: cluster-example
-  [...]
-```
-
-The critical element here is the `externalClusters` section of the `Cluster`
-resource, where the `plugin` stanza instructs CloudNativePG to use the Barman
-Cloud Plugin to access the object store for recovery.
-
-This same mechanism can be used for a variety of scenarios enabled by the
-CloudNativePG API, including:
-
-* **Full cluster recovery** from the latest backup
-* **Point-in-Time Recovery (PITR)**
-* Bootstrapping **replica clusters** in a distributed topology
-
-:::tip
-For complete instructions and advanced use cases, refer to the official
-[Recovery documentation](https://cloudnative-pg.io/documentation/current/recovery/).
-:::

web/versioned_docs/version-0.12.0/images.md

@@ -1,37 +0,0 @@
----
-sidebar_position: 99
----
-
-# Container Images
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin is distributed using two container images:
-
-- One for deploying the plugin components
-- One for the sidecar that runs alongside each PostgreSQL instance in a
-  CloudNativePG `Cluster` using the plugin
-
-## Plugin Container Image
-
-The plugin image contains the logic required to operate the Barman Cloud Plugin
-within your Kubernetes environment with CloudNativePG. It is published on the
-GitHub Container Registry at `ghcr.io/cloudnative-pg/plugin-barman-cloud`.
-
-This image is built from the
-[`Dockerfile.plugin`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.plugin)
-in the plugin repository.
-
-## Sidecar Container Image
-
-The sidecar image is used within each PostgreSQL pod in the cluster. It
-includes the latest supported version of Barman Cloud and is responsible for
-performing WAL archiving and backups on behalf of CloudNativePG.
-
-It is available at `ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar` and is
-built from the
-[`Dockerfile.sidecar`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.sidecar).
-
-These sidecar images are designed to work seamlessly with the
-[`minimal` PostgreSQL container images](https://github.com/cloudnative-pg/postgres-containers?tab=readme-ov-file#minimal-images)
-maintained by the CloudNativePG Community.

web/versioned_docs/version-0.12.0/installation.mdx

@@ -1,109 +0,0 @@
----
-sidebar_position: 20
----
-
-# Installation
-
-:::important
-1. The plugin **must** be installed in the same namespace as the CloudNativePG
-   operator (typically `cnpg-system`).
-
-2. Keep in mind that the operator's **listening namespaces** may differ from its
-   installation namespace. Double-check this to avoid configuration issues.
-:::
-
-## Verifying the Requirements
-
-Before installing the plugin, make sure the [requirements](intro.md#requirements) are met.
-
-### CloudNativePG Version
-
-Ensure you're running a version of CloudNativePG that is compatible with the
-plugin. If installed in the default `cnpg-system` namespace, you can verify the
-version with:
-
-```sh
-kubectl get deployment -n cnpg-system cnpg-controller-manager \
-  -o jsonpath="{.spec.template.spec.containers[*].image}"
-```
-
-Example output:
-
-```output
-ghcr.io/cloudnative-pg/cloudnative-pg:1.26.0
-```
-
-The version **must be 1.26 or newer**.
-
-### cert-manager
-
-Use the [cmctl](https://cert-manager.io/docs/reference/cmctl/#installation)
-tool to confirm that `cert-manager` is installed and available:
-
-```sh
-cmctl check api
-```
-
-Example output:
-
-```output
-The cert-manager API is ready
-```
-
-Both checks are required before proceeding with the installation.
-
-## Installing the Barman Cloud Plugin
-
-import { InstallationSnippet } from '@site/src/components/Installation';
-
-Install the plugin using `kubectl` by applying the manifest for the latest
-release:
-
-<InstallationSnippet />
-
-Example output:
-
-```output
-customresourcedefinition.apiextensions.k8s.io/objectstores.barmancloud.cnpg.io created
-serviceaccount/plugin-barman-cloud created
-role.rbac.authorization.k8s.io/leader-election-role created
-clusterrole.rbac.authorization.k8s.io/metrics-auth-role created
-clusterrole.rbac.authorization.k8s.io/metrics-reader created
-clusterrole.rbac.authorization.k8s.io/objectstore-editor-role created
-clusterrole.rbac.authorization.k8s.io/objectstore-viewer-role created
-clusterrole.rbac.authorization.k8s.io/plugin-barman-cloud created
-rolebinding.rbac.authorization.k8s.io/leader-election-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/metrics-auth-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/plugin-barman-cloud-binding created
-secret/plugin-barman-cloud-8tfddg42gf created
-service/barman-cloud created
-deployment.apps/barman-cloud configured
-certificate.cert-manager.io/barman-cloud-client created
-certificate.cert-manager.io/barman-cloud-server created
-issuer.cert-manager.io/selfsigned-issuer created
-```
-
-Finally, check that the deployment is up and running:
-
-```sh
-kubectl rollout status deployment \
-  -n cnpg-system barman-cloud
-```
-
-Example output:
-
-```output
-deployment "barman-cloud" successfully rolled out
-```
-
-This confirms that the plugin is deployed and ready to use.
-
-## Testing the latest development snapshot
-
-You can also test the latest development snapshot of the plugin with the
-following command:
-
-```sh
-kubectl apply -f \
-  https://raw.githubusercontent.com/cloudnative-pg/plugin-barman-cloud/refs/heads/main/manifest.yaml
-```

web/versioned_docs/version-0.12.0/intro.md

@@ -1,86 +0,0 @@
----
-sidebar_position: 1
-sidebar_label: "Introduction"
----
-
-# Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The **Barman Cloud Plugin** for [CloudNativePG](https://cloudnative-pg.io/)
-enables online continuous physical backups of PostgreSQL clusters to object storage
-using the `barman-cloud` suite from the [Barman](https://docs.pgbarman.org/release/latest/)
-project.
-
-:::important
-If you plan to migrate your existing CloudNativePG cluster to the new
-plugin-based approach using the Barman Cloud Plugin, see
-["Migrating from Built-in CloudNativePG Backup"](migration.md)
-for detailed instructions.
-:::
-
-## Requirements
-
-Before using the Barman Cloud Plugin, ensure that the following components are
-installed and properly configured:
-
-- [CloudNativePG](https://cloudnative-pg.io) version 1.26 or later
-
-  - We strongly recommend version 1.27.0 or later, which includes improved
-    error handling and status reporting for the plugin.
-  - If you are running an earlier release, refer to the
-    [upgrade guide](https://cloudnative-pg.io/documentation/current/installation_upgrade).
-
-- [cert-manager](https://cert-manager.io/)
-
-  - The recommended way to enable secure TLS communication between the plugin
-    and the operator.
-  - Alternatively, you can provide your own certificate bundles. See the
-    [CloudNativePG documentation on TLS configuration](https://cloudnative-pg.io/documentation/current/cnpg_i/#configuring-tls-certificates).
-
-- [`kubectl-cnpg`](https://cloudnative-pg.io/documentation/current/kubectl-plugin/)
-  plugin (optional but recommended)
-
-  - Simplifies debugging and monitoring with additional status and inspection
-    commands.
-  - Multiple installation options are available in the
-    [installation guide](https://cloudnative-pg.io/documentation/current/kubectl-plugin/#install).
-
-## Key Features
-
-This plugin provides the following capabilities:
-
-- Physical online backup of the data directory
-- Physical restore of the data directory
-- Write-Ahead Log (WAL) archiving
-- WAL restore
-- Full cluster recovery
-- Point-in-Time Recovery (PITR)
-- Seamless integration with replica clusters for bootstrap and WAL restore from archive
-
-:::important
-The Barman Cloud Plugin is designed to **replace the in-tree object storage support**
-previously provided via the `.spec.backup.barmanObjectStore` section in the
-`Cluster` resource.
-Backups created using the in-tree approach are fully supported and compatible
-with this plugin.
-:::
-
-## Supported Object Storage Providers
-
-The plugin works with all storage backends supported by `barman-cloud`, including:
-
-- **Amazon S3**
-- **Google Cloud Storage**
-- **Microsoft Azure Blob Storage**
-
-In addition, the following S3-compatible and simulator solutions have been
-tested and verified:
-
-- [MinIO](https://min.io/) – An S3-compatible storage solution
-- [Azurite](https://github.com/Azure/Azurite) – A simulator for Azure Blob Storage
-- [fake-gcs-server](https://github.com/fsouza/fake-gcs-server) – A simulator for Google Cloud Storage
-
-:::tip
-For more details, refer to [Object Store Providers](object_stores.md).
-:::

web/versioned_docs/version-0.12.0/migration.md

@@ -1,274 +0,0 @@
----
-sidebar_position: 40
----
-
-# Migrating from Built-in CloudNativePG Backup
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The in-tree support for Barman Cloud in CloudNativePG is **deprecated starting
-from version 1.26** and will be removed in a future release.
-
-If you're currently relying on the built-in Barman Cloud integration, you can
-migrate seamlessly to the new **plugin-based architecture** using the Barman
-Cloud Plugin, without data loss. Follow these steps:
-
-- [Install the Barman Cloud Plugin](installation.mdx)
-- Create an `ObjectStore` resource by translating the contents of the
-  `.spec.backup.barmanObjectStore` section from your existing `Cluster`
-  definition
-- Modify the `Cluster` resource in a single atomic change to switch from
-  in-tree backup to the plugin
-- Update any `ScheduledBackup` resources to use the plugin
-- Update the `externalClusters` configuration, where applicable
-
-:::tip
-For a working example, refer to [this commit](https://github.com/cloudnative-pg/cnpg-playground/commit/596f30e252896edf8f734991c3538df87630f6f7)
-from the [CloudNativePG Playground project](https://github.com/cloudnative-pg/cnpg-playground),
-which demonstrates a full migration.
-:::
-
----
-
-## Step 1: Define the `ObjectStore`
-
-Begin by creating an `ObjectStore` resource in the same namespace as your
-PostgreSQL `Cluster`.
-
-There is a **direct mapping** between the `.spec.backup.barmanObjectStore`
-section in CloudNativePG and the `.spec.configuration` field in the
-`ObjectStore` CR. The conversion is mostly mechanical, with one key difference:
-
-:::warning
-In the plugin architecture, retention policies are defined as part of the `ObjectStore`.
-In contrast, the in-tree implementation defined them at the `Cluster` level.
-:::
-
-If your `Cluster` used `.spec.backup.retentionPolicy`, move that configuration
-to `.spec.retentionPolicy` in the `ObjectStore`.
-
----
-
-### Example
-
-Here’s an excerpt from a traditional in-tree CloudNativePG backup configuration
-taken from the CloudNativePG Playground project:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-eu
-spec:
-  # [...]
-  backup:
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-This configuration translates to the following `ObjectStore` resource for the
-plugin:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-As you can see, the contents of `barmanObjectStore` have been copied directly
-under the `configuration` field of the `ObjectStore` resource, using the same
-secret references.
-
-## Step 2: Update the `Cluster` for plugin WAL archiving
-
-Once the `ObjectStore` resource is in place, update the `Cluster` resource as
-follows in a single atomic change:
-
-- Remove the `.spec.backup.barmanObjectStore` section
-- Remove `.spec.backup.retentionPolicy` if it was defined (as it is now in the
-  `ObjectStore`)
-- Remove the entire `spec.backup` section if it is now empty
-- Add `barman-cloud.cloudnative-pg.io` to the `plugins` list, as described in
-  [Configuring WAL archiving](usage.md#configuring-wal-archiving)
-
-This will trigger a rolling update of the `Cluster`, switching continuous
-backup from the in-tree implementation to the plugin-based approach.
-
-### Example
-
-The updated `pg-eu` cluster will have this configuration instead of the
-previous `backup` section:
-
-```yaml
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-eu
-```
-
----
-
-## Step 3: Update the `ScheduledBackup`
-
-After switching the `Cluster` to use the plugin, update your `ScheduledBackup`
-resources to match.
-
-Set the backup `method` to `plugin` and reference the plugin name via
-`pluginConfiguration`, as shown in ["Performing a base backup"](usage.md#performing-a-base-backup).
-
-### Example
-
-Original in-tree `ScheduledBackup`:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-```
-
-Updated version using the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
----
-
-## Step 4: Update the `externalClusters` configuration
-
-If your `Cluster` relies on one or more external clusters that use the in-tree
-Barman Cloud integration, you need to update those configurations to use the
-plugin-based architecture.
-
-When a replica cluster fetches WAL files or base backups from an external
-source that used the built-in backup method, follow these steps:
-
-1. Create a corresponding `ObjectStore` resource for the external cluster, as
-   shown in [Step 1](#step-1-define-the-objectstore)
-2. Update the `externalClusters` section of your replica cluster to use the
-   plugin instead of the in-tree `barmanObjectStore` field
-
-### Example
-
-Consider the original configuration using in-tree Barman Cloud:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      serverName: pg-eu
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-Create the `ObjectStore` resource for the external cluster:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-    accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-    secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-Update the external cluster configuration to use the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-eu
-        serverName: pg-eu
-```
-
-## Step 5: Verify your metrics
-
-When migrating from the in-core solution to the plugin-based approach, you need
-to monitor a different set of metrics, as described in the
-["Observability"](observability.md) section.
-
-The table below summarizes the name changes between the old in-core metrics and
-the new plugin-based ones:
-
-| Old metric name                                  | New metric name                                                  |
-| ------------------------------------------------ | ---------------------------------------------------------------- |
-| `cnpg_collector_last_failed_backup_timestamp`    | `barman_cloud_cloudnative_pg_io_last_failed_backup_timestamp`    |
-| `cnpg_collector_last_available_backup_timestamp` | `barman_cloud_cloudnative_pg_io_last_available_backup_timestamp` |
-| `cnpg_collector_first_recoverability_point`      | `barman_cloud_cloudnative_pg_io_first_recoverability_point`      |

web/versioned_docs/version-0.12.0/misc.md

@@ -1,97 +0,0 @@
----
-sidebar_position: 90
----
-
-# Miscellaneous
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-## Backup Object Tagging
-
-You can attach key-value metadata tags to backup artifacts—such as base
-backups, WAL files, and history files—via the `.spec.configuration` section of
-the `ObjectStore` resource.
-
-- `tags`: applied to base backups and WAL files
-- `historyTags`: applied to history files only
-
-### Example
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    [...]
-    tags:
-      backupRetentionPolicy: "expire"
-    historyTags:
-      backupRetentionPolicy: "keep"
-  [...]
-```
-
-## Extra Options for Backup and WAL Archiving
-
-You can pass additional command-line arguments to `barman-cloud-backup` and
-`barman-cloud-wal-archive` using the `additionalCommandArgs` field in the
-`ObjectStore` configuration.
-
-- `.spec.configuration.data.additionalCommandArgs`: for `barman-cloud-backup`
-- `.spec.configuration.wal.archiveAdditionalCommandArgs`: for `barman-cloud-wal-archive`
-
-Each field accepts a list of string arguments. If an argument is already
-configured elsewhere in the plugin, the duplicate will be ignored.
-
-### Example: Extra Backup Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    data:
-      additionalCommandArgs:
-        - "--min-chunk-size=5MB"
-        - "--read-timeout=60"
-```
-
-### Example: Extra WAL Archive Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    wal:
-      archiveAdditionalCommandArgs:
-        - "--max-concurrency=1"
-        - "--read-timeout=60"
-```
-
-For a complete list of supported options, refer to the
-[official Barman Cloud documentation](https://docs.pgbarman.org/release/latest/).
-
-## Enable the pprof debug server for the sidecar
-
-You can enable the instance sidecar's pprof debug HTTP server by adding the `--pprof-server=<address>` flag to the container's
-arguments via `.spec.instanceSidecarConfiguration.additionalContainerArgs`.
-
-Pass a bind address in the form `<host>:<port>` (for example, `0.0.0.0:6061`).
-An empty value disables the server (disabled by default).
-
-### Example
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  instanceSidecarConfiguration:
-    additionalContainerArgs:
-      - "--pprof-server=0.0.0.0:6061"
-```

web/versioned_docs/version-0.12.0/object_stores.md

@@ -1,497 +0,0 @@
----
-sidebar_position: 50
----
-
-# Object Store Providers
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin enables the storage of PostgreSQL cluster backup files
-in any object storage service supported by the
-[Barman Cloud infrastructure](https://docs.pgbarman.org/release/latest/).
-
-Currently, Barman Cloud supports the following providers:
-
-- [Amazon S3](#aws-s3)
-- [Microsoft Azure Blob Storage](#azure-blob-storage)
-- [Google Cloud Storage](#google-cloud-storage)
-
-You may also use any S3- or Azure-compatible implementation of the above
-services.
-
-To configure object storage with Barman Cloud, you must define an
-[`ObjectStore` object](plugin-barman-cloud.v1.md#objectstore), which
-establishes the connection between your PostgreSQL cluster and the object
-storage backend.
-
-Configuration details — particularly around authentication — will vary depending on
-the specific object storage provider you are using.
-
-The following sections detail the setup for each.
-
-:::note Authentication Methods
-The Barman Cloud Plugin does not independently test all authentication methods
-supported by `barman-cloud`. The plugin's responsibility is limited to passing
-the provided credentials to `barman-cloud`, which then handles authentication
-according to its own implementation. Users should refer to the
-[Barman Cloud documentation](https://docs.pgbarman.org/release/latest/) to
-verify that their chosen authentication method is supported and properly
-configured.
-:::
-
----
-
-## AWS S3
-
-[AWS Simple Storage Service (S3)](https://aws.amazon.com/s3/) is one of the
-most widely adopted object storage solutions.
-
-The Barman Cloud plugin for CloudNativePG integrates with S3 through two
-primary authentication mechanisms:
-
-- [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) —
-  recommended for clusters running on EKS
-- Access keys — using `ACCESS_KEY_ID` and `ACCESS_SECRET_KEY` credentials
-
-### Access Keys
-
-To authenticate using access keys, you’ll need:
-
-- `ACCESS_KEY_ID`: the public key used to authenticate to S3
-- `ACCESS_SECRET_KEY`: the corresponding secret key
-- `ACCESS_SESSION_TOKEN`: (optional) a temporary session token, if required
-
-These credentials must be stored securely in a Kubernetes secret:
-
-```sh
-kubectl create secret generic aws-creds \
-  --from-literal=ACCESS_KEY_ID=<access key here> \
-  --from-literal=ACCESS_SECRET_KEY=<secret key here>
-# --from-literal=ACCESS_SESSION_TOKEN=<session token here> # if required
-```
-
-The credentials will be encrypted at rest if your Kubernetes environment
-supports it.
-
-You can then reference the secret in your `ObjectStore` definition:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: aws-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    s3Credentials:
-      accessKeyId:
-        name: aws-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: aws-creds
-        key: ACCESS_SECRET_KEY
-  [...]
-```
-
-### IAM Role for Service Account (IRSA)
-
-To use IRSA with EKS, configure the service account of the PostgreSQL cluster
-with the appropriate annotation:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  [...]
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        eks.amazonaws.com/role-arn: arn:[...]
-        [...]
-```
-
-### S3 Lifecycle Policy
-
-Barman Cloud uploads backup files to S3 but does not modify them afterward.
-To enhance data durability and protect against accidental or malicious loss,
-it's recommended to implement the following best practices:
-
-- Enable object versioning
-- Enable object locking to prevent objects from being deleted or overwritten
-  for a defined period or indefinitely (this provides an additional layer of
-  protection against accidental deletion and ransomware attacks)
-- Set lifecycle rules to expire current versions a few days after your Barman
-  retention window
-- Expire non-current versions after a longer period
-
-These strategies help you safeguard backups without requiring broad delete
-permissions, ensuring both security and compliance with minimal operational
-overhead.
-
-### S3-Compatible Storage Providers
-
-You can use S3-compatible services like **MinIO**, **Linode (Akamai) Object Storage**,
-or **DigitalOcean Spaces** by specifying a custom `endpointURL`.
-
-Example with Linode (Akamai) Object Storage (`us-east1`):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: linode-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/"
-    endpointURL: "https://us-east1.linodeobjects.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-Recent changes to the [boto3 implementation](https://github.com/boto/boto3/issues/4392)
-of [Amazon S3 Data Integrity Protections](https://docs.aws.amazon.com/sdkref/latest/guide/feature-dataintegrity.html)
-may lead to the `x-amz-content-sha256` error when using the Barman Cloud
-Plugin.
-
-If you encounter this issue (see [GitHub issue #393](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/393)),
-you can apply the following workaround by setting specific environment
-variables in the `ObjectStore` resource:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: linode-store
-spec:
-  instanceSidecarConfiguration:
-    env:
-      - name: AWS_REQUEST_CHECKSUM_CALCULATION
-        value: when_required
-      - name: AWS_RESPONSE_CHECKSUM_VALIDATION
-        value: when_required
-  [...]
-```
-
-These settings ensure that checksum calculations and validations are only
-applied when explicitly required, avoiding compatibility issues with certain
-S3-compatible storage providers.
-
-Example with DigitalOcean Spaces (SFO3, path-style):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: digitalocean-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    endpointURL: "https://sfo3.digitaloceanspaces.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-### Using Object Storage with a Private CA
-
-For object storage services (e.g., MinIO) that use HTTPS with certificates
-signed by a private CA, set the `endpointCA` field in the `ObjectStore`
-definition. Unless you already have it, create a Kubernetes `Secret` with the
-CA bundle:
-
-```sh
-kubectl create secret generic my-ca-secret --from-file=ca.crt
-```
-
-Then reference it:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    endpointURL: <myEndpointURL>
-    endpointCA:
-      name: my-ca-secret
-      key: ca.crt
-  [...]
-```
-
-<!-- TODO: does this also apply to the plugin? -->
-:::note
-If you want `ConfigMaps` and `Secrets` to be **automatically** reloaded by
-instances, you can add a label with the key `cnpg.io/reload` to the
-`Secrets`/`ConfigMaps`. Otherwise, you will have to reload the instances using the
-`kubectl cnpg reload` subcommand.
-:::
-
----
-
-## Azure Blob Storage
-
-[Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/)
-is Microsoft’s cloud-based object storage solution.
-
-Barman Cloud supports the following authentication methods:
-
-- [Connection String](https://learn.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string)
-- Storage Account Name + [Storage Account Access Key](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage)
-- Storage Account Name + [Storage Account SAS Token](https://learn.microsoft.com/en-us/azure/storage/blobs/sas-service-create)
-- [Azure AD Managed Identity](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview)
-- [Default Azure Credentials](https://learn.microsoft.com/en-us/dotnet/api/azure.identity.defaultazurecredential?view=azure-dotnet)
-
-### Azure AD Managed Identity
-
-This method avoids storing credentials in Kubernetes by enabling the
-usage of [Azure Managed Identities](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview) authentication mechanism.
-This can be enabled by setting the `inheritFromAzureAD` option to `true`.
-Managed Identity can be configured for the AKS Cluster by following
-the [Azure documentation](https://learn.microsoft.com/en-us/azure/aks/use-managed-identity?pivots=system-assigned).
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      inheritFromAzureAD: true
-  [...]
-```
-
-### Default Azure Credentials
-
-The `useDefaultAzureCredentials` option enables the default Azure credentials
-flow, which uses [`DefaultAzureCredential`](https://learn.microsoft.com/en-us/python/api/azure-identity/azure.identity.defaultazurecredential)
-to automatically discover and use available credentials in the following order:
-
-1. **Environment Variables** — `AZURE_CLIENT_ID`, `AZURE_CLIENT_SECRET`, and `AZURE_TENANT_ID` for Service Principal authentication
-2. **Managed Identity** — Uses the managed identity assigned to the pod
-3. **Azure CLI** — Uses credentials from the Azure CLI if available
-4. **Azure PowerShell** — Uses credentials from Azure PowerShell if available
-
-This approach is particularly useful for getting started with development and testing; it allows
-the SDK to attempt multiple authentication mechanisms seamlessly across different environments.
-However, this is not recommended for production. Please refer to the
-[official Azure guidance](https://learn.microsoft.com/en-us/dotnet/azure/sdk/authentication/credential-chains?tabs=dac#usage-guidance-for-defaultazurecredential)
-for a comprehensive understanding of `DefaultAzureCredential`.
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      useDefaultAzureCredentials: true
-  [...]
-```
-
-### Access Key, SAS Token, or Connection String
-
-Store credentials in a Kubernetes secret:
-
-```sh
-kubectl create secret generic azure-creds \
-  --from-literal=AZURE_STORAGE_ACCOUNT=<storage account name> \
-  --from-literal=AZURE_STORAGE_KEY=<storage account key> \
-  --from-literal=AZURE_STORAGE_SAS_TOKEN=<SAS token> \
-  --from-literal=AZURE_STORAGE_CONNECTION_STRING=<connection string>
-```
-
-Then reference the required keys in your `ObjectStore`:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      connectionString:
-        name: azure-creds
-        key: AZURE_CONNECTION_STRING
-      storageAccount:
-        name: azure-creds
-        key: AZURE_STORAGE_ACCOUNT
-      storageKey:
-        name: azure-creds
-        key: AZURE_STORAGE_KEY
-      storageSasToken:
-        name: azure-creds
-        key: AZURE_STORAGE_SAS_TOKEN
-  [...]
-```
-
-For Azure Blob, the destination path format is:
-
-```
-<http|https>://<account-name>.<service-name>.core.windows.net/<container>/<blob>
-```
-
-### Azure-Compatible Providers
-
-If you're using a different implementation (e.g., Azurite or emulator):
-
-```
-<http|https>://<local-machine-address>:<port>/<account-name>/<container>/<blob>
-```
-
----
-
-## Google Cloud Storage
-
-[Google Cloud Storage](https://cloud.google.com/storage/) is supported with two
-authentication modes:
-
-- **GKE Workload Identity** (recommended inside Google Kubernetes Engine)
-- **Service Account JSON key** via the `GOOGLE_APPLICATION_CREDENTIALS` environment variable
-
-### GKE Workload Identity
-
-Use the [Workload Identity authentication](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
-when running in GKE:
-
-1. Set `googleCredentials.gkeEnvironment` to `true` in the `ObjectStore`
-   resource
-2. Annotate the `serviceAccountTemplate` in the `Cluster` resource with the GCP
-   service account
-
-For example, in the `ObjectStore` resource:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      gkeEnvironment: true
-```
-
-And in the `Cluster` resource:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        iam.gke.io/gcp-service-account: [...].iam.gserviceaccount.com
-```
-
-### Service Account JSON Key
-
-Follow Google’s [authentication setup](https://cloud.google.com/docs/authentication/getting-started),
-then:
-
-```sh
-kubectl create secret generic backup-creds --from-file=gcsCredentials=gcs_credentials_file.json
-```
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      applicationCredentials:
-        name: backup-creds
-        key: gcsCredentials
-  [...]
-```
-
-:::important
-This authentication method generates a JSON file within the container
-with all the credentials required to access your Google Cloud Storage
-bucket. As a result, if someone gains access to the `Pod`, they will also have
-write permissions to the bucket.
-:::
-
----
-
-
-## MinIO Object Store
-
-In order to use the Tenant resource you first need to deploy the
-[MinIO operator](https://docs.min.io/community/minio-object-store/operations/deployments/installation.html).
-For the latest documentation of MinIO, please refer to the
-[MinIO official documentation](https://docs.min.io/community/minio-object-store/).
-
-MinIO Object Store's API is compatible with S3, and the default configuration of the Tenant
-will create these services:
-- `<tenant>-console` on port 9090 (with autocert) or 9443 (without autocert)
-- `<tenant>-hl` on port 9000
-Where `<tenant>` is the `metadata.name` you assigned to your Tenant resource.
-
-:::note
-The `<tenant>-console` service will only be available if you have enabled the
-[MinIO Console](https://docs.min.io/community/minio-object-store/administration/minio-console.html).
-
-For example, the following Tenant:
-```yml
-apiVersion: minio.min.io/v2
-kind: Tenant
-metadata:
-  name: cnpg-backups
-spec:
-  [...]
-```
-would have services called `cnpg-backups-console` and `cnpg-backups-hl` respectively.
-
-The `console` service is for managing the tenant, while the `hl` service exposes the S3
-compatible API. If your tenant is configured with `requestAutoCert` you will communicate
-to these services over HTTPS, if not you will use HTTP.
-
-For authentication you can use your username and password, or create an access key.
-Whichever method you choose, it has to be stored as a secret.
-
-```sh
-kubectl create secret generic minio-creds \
-  --from-literal=MINIO_ACCESS_KEY=<minio access key or username> \
-  --from-literal=MINIO_SECRET_KEY=<minio secret key or password>
-```
-
-Finally, create the Barman ObjectStore:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    destinationPath: s3://BUCKET_NAME/
-    endpointURL: http://<tenant>-hl:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio-creds
-        key: MINIO_ACCESS_KEY
-      secretAccessKey:
-        name: minio-creds
-        key: MINIO_SECRET_KEY
-  [...]
-```
-
-:::important
-Verify on `s3://BUCKET_NAME/` the presence of archived WAL files before
-proceeding with a backup.
-:::
-
----

web/versioned_docs/version-0.12.0/observability.md

@@ -1,24 +0,0 @@
----
-sidebar_position: 55
----
-
-# Observability
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin exposes the following metrics through the native
-Prometheus exporter of the instance manager:
-
-- `barman_cloud_cloudnative_pg_io_last_failed_backup_timestamp`:
-  the UNIX timestamp of the most recent failed backup.
-
-- `barman_cloud_cloudnative_pg_io_last_available_backup_timestamp`:
-  the UNIX timestamp of the most recent successfully available backup.
-
-- `barman_cloud_cloudnative_pg_io_first_recoverability_point`:
-  the UNIX timestamp representing the earliest point in time from which the
-  cluster can be recovered.
-
-These metrics supersede the previously available in-core metrics that used the
-`cnpg_collector` prefix. The new metrics are exposed under the
-`barman_cloud_cloudnative_pg_io` prefix instead.

web/versioned_docs/version-0.12.0/parameters.md

@@ -1,19 +0,0 @@
----
-sidebar_position: 100
----
-
-# Parameters
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The following parameters are available for the Barman Cloud Plugin:
-
-- `barmanObjectName`: references the `ObjectStore` resource to be used by the
-  plugin.
-- `serverName`: Specifies the server name in the object store.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::

web/versioned_docs/version-0.12.0/plugin-barman-cloud.v1.md

@@ -1,108 +0,0 @@
-# API Reference
-
-## Packages
-- [barmancloud.cnpg.io/v1](#barmancloudcnpgiov1)
-
-
-## barmancloud.cnpg.io/v1
-
-Package v1 contains API Schema definitions for the barmancloud v1 API group
-
-### Resource Types
-- [ObjectStore](#objectstore)
-
-
-
-#### InstanceSidecarConfiguration
-
-
-
-InstanceSidecarConfiguration defines the configuration for the sidecar that runs in the instance pods.
-
-
-
-_Appears in:_
-- [ObjectStoreSpec](#objectstorespec)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `env` _[EnvVar](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#envvar-v1-core) array_ | The environment to be explicitly passed to the sidecar |  |  |  |
-| `retentionPolicyIntervalSeconds` _integer_ | The retentionCheckInterval defines the frequency at which the<br />system checks and enforces retention policies. |  | 1800 |  |
-| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | Resources define cpu/memory requests and limits for the sidecar that runs in the instance pods. |  |  |  |
-| `additionalContainerArgs` _string array_ | AdditionalContainerArgs is an optional list of command-line arguments<br />to be passed to the sidecar container when it starts.<br />The provided arguments are appended to the container’s default arguments. |  |  |  |
-| `logLevel` _string_ | The log level for PostgreSQL instances. Valid values are: `error`, `warning`, `info` (default), `debug`, `trace` |  | info | Enum: [error warning info debug trace] <br /> |
-
-
-#### ObjectStore
-
-
-
-ObjectStore is the Schema for the objectstores API.
-
-
-
-
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `apiVersion` _string_ | `barmancloud.cnpg.io/v1` | True | | |
-| `kind` _string_ | `ObjectStore` | True | | |
-| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | True |  |  |
-| `spec` _[ObjectStoreSpec](#objectstorespec)_ | Specification of the desired behavior of the ObjectStore.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status | True |  |  |
-| `status` _[ObjectStoreStatus](#objectstorestatus)_ | Most recently observed status of the ObjectStore. This data may not be up to<br />date. Populated by the system. Read-only.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status |  |  |  |
-
-
-#### ObjectStoreSpec
-
-
-
-ObjectStoreSpec defines the desired state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `configuration` _[BarmanObjectStoreConfiguration](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration)_ | The configuration for the barman-cloud tool suite | True |  |  |
-| `retentionPolicy` _string_ | RetentionPolicy is the retention policy to be used for backups<br />and WALs (i.e. '60d'). The retention policy is expressed in the form<br />of `XXu` where `XX` is a positive integer and `u` is in `[dwm]` -<br />days, weeks, months. |  |  | Pattern: `^[1-9][0-9]*[dwm]$` <br /> |
-| `instanceSidecarConfiguration` _[InstanceSidecarConfiguration](#instancesidecarconfiguration)_ | The configuration for the sidecar that runs in the instance pods |  |  |  |
-
-
-#### ObjectStoreStatus
-
-
-
-ObjectStoreStatus defines the observed state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `serverRecoveryWindow` _object (keys:string, values:[RecoveryWindow](#recoverywindow))_ | ServerRecoveryWindow maps each server to its recovery window | True |  |  |
-
-
-#### RecoveryWindow
-
-
-
-RecoveryWindow represents the time span between the first
-recoverability point and the last successful backup of a PostgreSQL
-server, defining the period during which data can be restored.
-
-
-
-_Appears in:_
-- [ObjectStoreStatus](#objectstorestatus)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `firstRecoverabilityPoint` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The first recoverability point in a PostgreSQL server refers to<br />the earliest point in time to which the database can be<br />restored. | True |  |  |
-| `lastSuccessfulBackupTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The last successful backup time | True |  |  |
-| `lastFailedBackupTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The last failed backup time | True |  |  |
-
-

web/versioned_docs/version-0.12.0/resource-name-migration.md

@@ -1,219 +0,0 @@
----
-sidebar_position: 90
----
-
-# Resource name migration guide
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-:::warning
-Before proceeding with the migration process, please:
-1. **Read this guide in its entirety** to understand what changes will be made
-2. **Test in a non-production environment** first if possible
-3. **Ensure you have proper backups** of your cluster configuration
-
-This migration will delete old RBAC resources only after the
-`plugin-barman-cloud` upgrade. While the operation is designed to be safe, you
-should review and understand the changes before proceeding. The maintainers of
-this project are not responsible for any issues that may arise during
-migration.
-
-**Note:** This guide assumes you are using the default `cnpg-system` namespace.
-:::
-
-## Overview
-
-Starting from version **0.8.0**, the `plugin-barman-cloud` deployment manifests
-use more specific, prefixed resource names to avoid conflicts with other
-components deployed in the same Kubernetes cluster.
-
-## What Changed
-
-The following resources have been renamed to use proper prefixes.
-
-### Cluster-scoped Resources
-
-| Old Name                   | New Name                                 |
-|----------------------------|------------------------------------------|
-| `metrics-auth-role`        | `barman-plugin-metrics-auth-role`        |
-| `metrics-auth-rolebinding` | `barman-plugin-metrics-auth-rolebinding` |
-| `metrics-reader`           | `barman-plugin-metrics-reader`           |
-| `objectstore-viewer-role`  | `barman-plugin-objectstore-viewer-role`  |
-| `objectstore-editor-role`  | `barman-plugin-objectstore-editor-role`  |
-
-### Namespace-scoped Resources
-
-| Old Name                      | New Name                                    | Namespace     |
-|-------------------------------|---------------------------------------------|---------------|
-| `leader-election-role`        | `barman-plugin-leader-election-role`        | `cnpg-system` |
-| `leader-election-rolebinding` | `barman-plugin-leader-election-rolebinding` | `cnpg-system` |
-
-## Why This Change?
-
-Using generic names for cluster-wide resources is discouraged as they may
-conflict with other components deployed in the same cluster. The new names make
-it clear that these resources belong to the Barman Cloud plugin and help avoid
-naming collisions.
-
-## Migration Instructions
-
-This three steps migration process is straightforward and can be completed with
-a few `kubectl` commands.
-
-### Step 1: Upgrade plugin-barman-cloud
-
-Please refer to the [Installation](installation.mdx) section to deploy the new
-`plugin-barman-cloud` release.
-
-### Step 2: Delete Old Cluster-scoped Resources
-
-:::danger Verify Resources Before Deletion
-**IMPORTANT**: The old resource names are generic and could potentially belong
-to other components in your cluster.
-
-**Before deleting each resource, verify it belongs to the Barman Cloud plugin
-by checking:**
-- For `objectstore-*` roles: Look for `barmancloud.cnpg.io` in the API groups
-- For `metrics-*` roles: Check if they reference the `plugin-barman-cloud`
-  ServiceAccount in `cnpg-system` namespace
-- For other roles: Look for labels like `app.kubernetes.io/name: plugin-barman-cloud`
-
-If a resource doesn't have these indicators, **DO NOT DELETE IT** as it may
-belong to another application.
-
-Carefully review the output of each verification command before proceeding with
-the `delete`.
-:::
-
-:::tip Dry Run First
-You can add `--dry-run=client` to any `kubectl delete` command to preview what
-would be deleted without actually removing anything.
-:::
-
-**Only proceed if you've verified these resources belong to the Barman Cloud
-plugin (see warning above).**
-
-For each resource below, first verify it belongs to Barman Cloud, then delete
-it:
-
-```bash
-# 1. Check metrics-auth-rolebinding FIRST (we'll check the role after)
-# Look for references to plugin-barman-cloud ServiceAccount
-kubectl describe clusterrolebinding metrics-auth-rolebinding
-# If it references plugin-barman-cloud ServiceAccount in cnpg-system namespace,
-# delete it:
-kubectl delete clusterrolebinding metrics-auth-rolebinding
-
-# 2. Check metrics-auth-role
-# Look for references to authentication.k8s.io and authorization.k8s.io
-kubectl describe clusterrole metrics-auth-role
-# Verify it's not being used by any other rolebindings:
-kubectl get clusterrolebinding -o json \
-  | jq -r '.items[] | select(.roleRef.name=="metrics-auth-role") \
-  | .metadata.name'
-# If the above returns nothing (role is not in use) and the role looks like the
-# Barman Cloud one, delete it (see warnings section):
-kubectl delete clusterrole metrics-auth-role
-
-# 3. Check objectstore-viewer-role
-# Look for barmancloud.cnpg.io API group or
-# for `app.kubernetes.io/name: plugin-barman-cloud` label
-kubectl describe clusterrole objectstore-viewer-role
-# If it shows barmancloud.cnpg.io in API groups, delete it:
-kubectl delete clusterrole objectstore-viewer-role
-
-# 4. Check objectstore-editor-role
-# Look for barmancloud.cnpg.io API group or
-# for `app.kubernetes.io/name: plugin-barman-cloud` label
-kubectl describe clusterrole objectstore-editor-role
-# If it shows barmancloud.cnpg.io in API groups, delete it:
-kubectl delete clusterrole objectstore-editor-role
-
-# 5. Check metrics-reader (MOST DANGEROUS - very generic name)
-# First, check if it's being used by any rolebindings OTHER than barman's:
-kubectl get clusterrolebinding -o json | jq -r '.items[] \
-  | select(.roleRef.name=="metrics-reader") \
-  | "\(.metadata.name) -> \(.subjects[0].name) in \(.subjects[0].namespace)"'
-# If this shows ANY rolebindings, review them carefully. Only proceed if
-# they're all Barman-related.  Then check the role itself:
-kubectl describe clusterrole metrics-reader
-# If it ONLY has nonResourceURLs: /metrics and NO other rolebindings use it,
-# delete it:
-kubectl delete clusterrole metrics-reader
-```
-
-:::warning
-The `metrics-reader` role is particularly dangerous to delete blindly. Many
-monitoring systems use this exact name. Only delete it if:
-
-1. You've verified it ONLY grants access to `/metrics`
-2. No other rolebindings reference it (checked with the jq command above)
-3. You're certain it was created by the Barman Cloud plugin
-
-If you're unsure, it's safer to leave it and let the new
-`barman-plugin-metrics-reader` role coexist with it.
-:::
-
-If any resource is not found during the `describe` command, that's okay - it
-means it was never created or already deleted. Simply skip the delete command
-for that resource.
-
-### Step 3: Delete Old Namespace-scoped Resources
-
-Delete the old namespace-scoped resources in the `cnpg-system` namespace:
-
-```bash
-# Delete the old leader-election resources
-kubectl delete role leader-election-role -n cnpg-system
-kubectl delete rolebinding leader-election-rolebinding -n cnpg-system
-```
-
-If any resource is not found, that's okay - it means it was never created or
-already deleted.
-
-## Impact
-
-- **Permissions:** If you have custom RBAC rules or tools that reference the
-  old resource names, they will need to be updated.
-- **External Users:** If end users have been granted the
-  `objectstore-viewer-role` or `objectstore-editor-role`, they will need to be
-  re-granted the new role names (`barman-plugin-objectstore-viewer-role` and
-  `barman-plugin-objectstore-editor-role`).
-
-## Verification
-
-After migration, verify that the new resources are created:
-
-```bash
-# Check cluster-scoped resources
-kubectl get clusterrole | grep barman
-kubectl get clusterrolebinding | grep barman
-
-# Check namespace-scoped resources
-kubectl get role,rolebinding -n cnpg-system | grep barman
-```
-
-You should see the new prefixed resource names.
-
-## Troubleshooting
-
-### Plugin Not Starting After Migration
-
-If the plugin fails to start after migration, check:
-
-1. **ServiceAccount permissions:** Ensure the `plugin-barman-cloud` ServiceAccount is bound to the new roles:
-   ```bash
-   kubectl get clusterrolebinding barman-plugin-metrics-auth-rolebinding -o yaml
-   kubectl get rolebinding barman-plugin-leader-election-rolebinding -n cnpg-system -o yaml
-   ```
-
-2. **Role references:** Verify that the rolebindings reference the correct role names:
-   ```bash
-   kubectl describe rolebinding barman-plugin-leader-election-rolebinding -n cnpg-system
-   kubectl describe clusterrolebinding barman-plugin-metrics-auth-rolebinding
-   ```
-
-## Support
-
-If you encounter issues during migration, please open an issue on the [GitHub
-repository](https://github.com/cloudnative-pg/plugin-barman-cloud/issues).

web/versioned_docs/version-0.12.0/retention.md

@@ -1,38 +0,0 @@
----
-sidebar_position: 60
----
-
-# Retention Policies
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin supports **automated cleanup of obsolete backups** via
-retention policies, configured in the `.spec.retentionPolicy` field of the
-`ObjectStore` resource.
-
-:::note
-This feature uses the `barman-cloud-backup-delete` command with the
-`--retention-policy "RECOVERY WINDOW OF {{ value }} {{ unit }}"` syntax.
-:::
-
-#### Example: 30-Day Retention Policy
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  [...]
-  retentionPolicy: "30d"
-````
-
-:::note
-A **recovery window retention policy** ensures the cluster can be restored to
-any point in time between the calculated *Point of Recoverability* (PoR) and
-the latest WAL archive. The PoR is defined as `current time - recovery window`.
-The **first valid backup** is the most recent backup completed before the PoR.
-Backups older than that are marked as *obsolete* and deleted after the next
-backup completes.
-:::
-

web/versioned_docs/version-0.12.0/troubleshooting.md

@@ -1,591 +0,0 @@
----
-sidebar_position: 90
----
-
-# Troubleshooting
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-This guide helps you diagnose and resolve common issues with the Barman Cloud
-plugin.
-
-:::important
-We are continuously improving the integration between CloudNativePG and the
-Barman Cloud plugin as it moves toward greater stability and maturity. For this
-reason, we recommend using the latest available version of both components.
-See the [*Requirements* section](intro.md#requirements) for details.
-:::
-
-:::note
-The following commands assume you installed the CloudNativePG operator in
-the default `cnpg-system` namespace. If you installed it in a different
-namespace, adjust the commands accordingly.
-:::
-
-## Viewing Logs
-
-To troubleshoot effectively, you’ll often need to review logs from multiple
-sources:
-
-```sh
-# View operator logs (includes plugin interaction logs)
-kubectl logs -n cnpg-system deployment/cnpg-controller-manager -f
-
-# View plugin manager logs
-kubectl logs -n cnpg-system deployment/barman-cloud -f
-
-# View sidecar container logs (Barman Cloud operations)
-kubectl logs -n <namespace> <cluster-pod-name> -c plugin-barman-cloud -f
-
-# View all containers in a pod
-kubectl logs -n <namespace> <cluster-pod-name> --all-containers=true
-
-# View previous container logs (if container restarted)
-kubectl logs -n <namespace> <cluster-pod-name> -c plugin-barman-cloud --previous
-```
-
-## Common Issues
-
-### Plugin Installation Issues
-
-#### Plugin pods not starting
-
-**Symptoms:**
-
-- Plugin pods stuck in `CrashLoopBackOff` or `Error`
-- Plugin deployment not ready
-
-**Possible causes and solutions:**
-
-1. **Certificate issues**
-
-   ```sh
-   # Check if cert-manager is installed and running
-   kubectl get pods -n cert-manager
-
-   # Check if the plugin certificate is created
-   kubectl get certificates -n cnpg-system
-   ```
-
-   If cert-manager is not installed, install it first:
-
-   ```sh
-   # Note: other installation methods for cert-manager are available
-   kubectl apply -f \
-     https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml
-   ```
-
-   If you are using your own certificates without cert-manager, you will need
-   to verify the entire certificate chain yourself.
-
-
-2. **Image pull errors**
-
-   ```sh
-   # Check pod events for image pull errors
-   kubectl describe pod -n cnpg-system -l app=barman-cloud
-   ```
-
-   Verify the image exists and you have proper credentials if using a private
-   registry.
-
-
-3. **Resource constraints**
-
-   ```sh
-   # Check node resources
-   kubectl top nodes
-   kubectl describe nodes
-   ```
-
-   Make sure your cluster has sufficient CPU and memory resources.
-
-### Backup Failures
-
-#### Quick Backup Troubleshooting Checklist
-
-When a backup fails, follow these steps in order:
-
-1. **Check backup status**:
-
-   ```sh
-   kubectl get backups.postgresql.cnpg.io -n <namespace>
-   ```
-2. **Get error details and target pod**:
-
-   ```sh
-   kubectl describe backups.postgresql.cnpg.io \
-     -n <namespace> <backup-name>
-
-   kubectl get backups.postgresql.cnpg.io \
-     -n <namespace> <backup-name> \
-     -o jsonpath='{.status.instanceID.podName}'
-   ```
-3. **Check the target pod’s sidecar logs**:
-
-   ```sh
-   TARGET_POD=$(kubectl get backups.postgresql.cnpg.io \
-     -n <namespace> <backup-name> \
-     -o jsonpath='{.status.instanceID.podName}')
-
-   kubectl logs \
-     -n <namespace> $TARGET_POD -c plugin-barman-cloud \
-     --tail=100 | grep -E "ERROR|FATAL|panic"
-   ```
-4. **Check cluster events**:
-
-   ```sh
-   kubectl get events -n <namespace> \
-     --field-selector involvedObject.name=<cluster-name> \
-     --sort-by='.lastTimestamp'
-   ```
-5. **Verify plugin is running**:
-
-   ```sh
-   kubectl get pods \
-     -n cnpg-system -l app=barman-cloud
-   ```
-6. **Check operator logs**:
-
-   ```sh
-   kubectl logs \
-     -n cnpg-system deployment/cnpg-controller-manager \
-     --tail=100 | grep -i "backup\|plugin"
-   ```
-7. **Check plugin manager logs**:
-
-   ```sh
-   kubectl logs \
-     -n cnpg-system deployment/barman-cloud --tail=100
-   ```
-
-#### Backup job fails immediately
-
-**Symptoms:**
-
-- Backup pods terminate with error
-- No backup files appear in object storage
-- Backup shows `failed` phase with various error messages
-
-**Common failure modes and solutions:**
-
-1. **"requested plugin is not available" errors**
-
-   ```
-   requested plugin is not available: barman
-   requested plugin is not available: barman-cloud
-   requested plugin is not available: barman-cloud.cloudnative-pg.io
-   ```
-   
-   **Cause:** The plugin name in the Cluster configuration doesn’t match the
-   deployed plugin, or the plugin isn’t registered.
-   
-   **Solution:** 
-   
-   a. **Check plugin registration:**
-
-   ```sh
-   # If you have the `cnpg` plugin installed (v1.27.0+)
-   kubectl cnpg status -n <namespace> <cluster-name>
-   ```
-   
-   Look for the "Plugins status" section:
-   ```
-   Plugins status
-   Name                            Version  Status  Reported Operator Capabilities
-   ----                            -------  ------  ------------------------------
-   barman-cloud.cloudnative-pg.io  0.6.0    N/A     Reconciler Hooks, Lifecycle Service
-   ```
-   
-   b. **Verify plugin name in `Cluster` spec**:
-
-   ```yaml
-   apiVersion: postgresql.cnpg.io/v1
-   kind: Cluster
-   spec:
-     plugins:
-       - name: barman-cloud.cloudnative-pg.io
-         parameters:
-           barmanObjectName: <your-objectstore-name>
-   ```
-   
-   c. **Check plugin deployment is running**:
-
-   ```sh
-   kubectl get deployment -n cnpg-system barman-cloud
-   ```
-
-2. **"rpc error: code = Unknown desc = panic caught: assignment to entry in nil map" errors**
-   
-   **Cause:** Misconfiguration in the `ObjectStore` (e.g., typo or missing field).
-   
-   **Solution:** 
-
-   - Review sidecar logs for details
-   - Verify `ObjectStore` configuration and secrets
-   - Common issues include:
-     - Missing or incorrect secret references
-     - Typos in configuration parameters
-     - Missing required environment variables in secrets
-
-#### Backup performance issues
-
-**Symptoms:**
-
-- Backups take extremely long
-- Backups timeout
-
-**Plugin-specific considerations:**
-
-1. **Check `ObjectStore` parallelism settings**
-   - Adjust `maxParallel` in `ObjectStore` configuration
-   - Monitor sidecar container resource usage during backups
-
-2. **Verify plugin resource allocation**
-   - Check if the sidecar container has sufficient CPU/memory
-   - Review plugin container logs for resource-related warnings
-
-:::tip
-For Barman-specific features like compression, encryption, and performance
-tuning, refer to the [Barman documentation](https://docs.pgbarman.org/latest/).
-:::
-
-### WAL Archiving Issues
-
-#### WAL archiving stops
-
-**Symptoms:**
-
-- WAL files accumulate on the primary
-- Cluster shows WAL archiving warnings
-- Sidecar logs show WAL errors
-
-**Debugging steps:**
-
-1. **Check plugin sidecar logs for WAL archiving errors**
-   ```sh
-   # Check recent WAL archive operations in sidecar
-   kubectl logs -n <namespace> <primary-pod> -c plugin-barman-cloud \
-     --tail=50 | grep -i wal
-   ```
-
-2. **Check ObjectStore configuration for WAL settings**
-   - Ensure ObjectStore has proper WAL retention settings
-   - Verify credentials have permissions for WAL operations
-
-### Restore Issues
-
-#### Restore fails during recovery
-
-**Symptoms:**
-
-- New cluster stuck in recovery
-- Plugin sidecar shows restore errors
-- PostgreSQL won’t start
-
-**Debugging steps:**
-
-1. **Check plugin sidecar logs during restore**
-
-   ```sh
-   # Check the sidecar logs on the recovering cluster pods
-   kubectl logs -n <namespace> <cluster-pod-name> \
-     -c plugin-barman-cloud --tail=100
-   
-   # Look for restore-related errors
-   kubectl logs -n <namespace> <cluster-pod-name> \
-     -c plugin-barman-cloud | grep -E "restore|recovery|ERROR"
-   ```
-
-2. **Verify plugin can access backups**
-
-   ```sh
-   # Check if `ObjectStore` is properly configured for restore
-   kubectl get objectstores.barmancloud.cnpg.io \
-     -n <namespace> <objectstore-name> -o yaml
-   
-   # Check PostgreSQL recovery logs
-   kubectl logs -n <namespace> <cluster-pod> \
-     -c postgres | grep -i recovery
-   ```
-
-:::tip
-For detailed Barman restore operations and troubleshooting, refer to the
-[Barman documentation](https://docs.pgbarman.org/latest/barman-cloud-restore.html).
-:::
-
-#### Point-in-time recovery (PITR) configuration issues
-
-**Symptoms:**
-
-- PITR doesn’t reach target time
-- WAL access errors
-- Recovery halts early
-
-**Debugging steps:**
-
-1. **Verify PITR configuration in the `Cluster` spec**
-
-   ```yaml
-   apiVersion: postgresql.cnpg.io/v1
-   kind: Cluster
-   metadata:
-     name: <cluster-restore-name>
-   spec:
-     storage:
-       size: 1Gi
-
-     bootstrap:
-       recovery:
-         source: origin
-         recoveryTarget:
-           targetTime: "2024-01-15T10:30:00Z"
-
-     externalClusters:
-       - name: origin
-         plugin:
-           enabled: true
-           name: barman-cloud.cloudnative-pg.io
-           parameters:
-             barmanObjectName: <object-store-name>
-             serverName: <source-cluster-name>
-   ```
-
-2. **Check sidecar logs for WAL-related errors**
-
-   ```sh
-   kubectl logs -n <namespace> <cluster-pod> \
-     -c plugin-barman-cloud | grep -i wal
-   ```
-
-:::note
-Timestamps without an explicit timezone suffix
-(e.g., `2024-01-15 10:30:00`) are interpreted as UTC.
-:::
-
-:::warning
-Always specify an explicit timezone in your timestamp to avoid ambiguity.
-For example, use `2024-01-15T10:30:00Z` or `2024-01-15T10:30:00+02:00`
-instead of `2024-01-15 10:30:00`.
-:::
-
-:::note
-For detailed PITR configuration and WAL management, see the
-[Barman PITR documentation](https://docs.pgbarman.org/latest/).
-:::
-
-### Plugin Configuration Issues
-
-#### Plugin cannot connect to object storage
-
-**Symptoms:**
-
-- Sidecar logs show connection errors
-- Backups fail with authentication or network errors
-- `ObjectStore` resource reports errors
-
-**Solution:**
-
-1. **Verify `ObjectStore` CRD configuration and secrets**
-
-   ```sh
-   # Check ObjectStore resource status
-   kubectl get objectstores.barmancloud.cnpg.io \
-     -n <namespace> <objectstore-name> -o yaml
-   
-   # Verify the secret exists and has correct keys for your provider
-   kubectl get secret -n <namespace> <secret-name> \
-     -o jsonpath='{.data}' | jq 'keys'
-   ```
-
-2. **Check sidecar logs for connectivity issues**
-   ```sh
-   kubectl logs -n <namespace> <cluster-pod> \
-     -c plugin-barman-cloud | grep -E "connect|timeout|SSL|cert"
-   ```
-
-3. **Adjust provider-specific settings (endpoint, path style, etc.)**
-   - See [Object Store Configuration](object_stores.md) for provider-specific settings
-   - Ensure `endpointURL` is set correctly for your storage provider
-   - Verify network policies allow egress to your storage provider
-
-## Diagnostic Commands
-
-### Using the `cnpg` plugin for `kubectl`
-
-The `cnpg` plugin for `kubectl` provides extended debugging capabilities.
-Keep it updated:
-
-```sh
-# Install or update the `cnpg` plugin
-kubectl krew install cnpg
-# Or using an alternative method: https://cloudnative-pg.io/documentation/current/kubectl-plugin/#install
-
-# Check plugin status (requires CNPG 1.27.0+)
-kubectl cnpg status <cluster-name> -n <namespace>
-
-# View cluster status in detail
-kubectl cnpg status <cluster-name> -n <namespace> --verbose
-```
-
-## Getting Help
-
-If problems persist:
-
-1. **Check the documentation**
-
-   - [Installation Guide](installation.mdx)
-   - [Object Store Configuration](object_stores.md) (for provider-specific settings)
-   - [Usage Examples](usage.md)
-
-
-2. **Gather diagnostic information**
-
-   ```sh
-   # Create a diagnostic bundle (⚠️ sanitize these before sharing!)
-   kubectl get objectstores.barmancloud.cnpg.io -A -o yaml > /tmp/objectstores.yaml
-   kubectl get clusters.postgresql.cnpg.io -A -o yaml > /tmp/clusters.yaml
-   kubectl logs -n cnpg-system deployment/barman-cloud --tail=1000 > /tmp/plugin.log
-   ```
-
-
-3. **Community support**
-
-   - CloudNativePG Slack: [#cloudnativepg-users](https://cloud-native.slack.com/messages/cloudnativepg-users)
-   - GitHub Issues: [plugin-barman-cloud](https://github.com/cloudnative-pg/plugin-barman-cloud/issues)
-
-
-4. **Include when reporting**
-
-   - CloudNativePG version
-   - Plugin version
-   - Kubernetes version
-   - Cloud provider and region
-   - Relevant configuration (⚠️ sanitize/redact sensitive information)
-   - Error messages and logs
-   - Steps to reproduce
-
-## Known Issues and Limitations
-
-### Current Known Issues
-
-1. **Migration compatibility**: After migrating from in-tree backup to the
-   plugin, the `kubectl cnpg backup` command syntax has changed
-   ([#353](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/353)):
-
-   ```sh
-   # Old command (in-tree, no longer works after migration)
-   kubectl cnpg backup -n <namespace> <cluster-name> \
-     --method=barmanObjectStore
-   
-   # New command (plugin-based)
-   kubectl cnpg backup -n <namespace> <cluster-name> \
-     --method=plugin --plugin-name=barman-cloud.cloudnative-pg.io
-   ```
-
-### Plugin Limitations
-
-1. **Installation method**: Currently only supports manifest and Kustomize
-   installation ([#351](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/351) -
-   Helm chart requested)
-
-2. **Sidecar resource sharing**: The plugin sidecar container shares pod
-   resources with PostgreSQL
-
-3. **Plugin restart behavior**: Restarting the sidecar container requires
-   restarting the entire PostgreSQL pod
-
-## Recap of General Debugging Steps
-
-### Check Backup Status and Identify the Target Instance
-
-```sh
-# List all backups and their status
-kubectl get backups.postgresql.cnpg.io -n <namespace>
-
-# Get detailed backup information including error messages and target instance
-kubectl describe backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name>
-
-# Extract the target pod name from a failed backup
-kubectl get backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name> \
-  -o jsonpath='{.status.instanceID.podName}'
-
-# Get more details including the target pod, method, phase, and error
-kubectl get backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name> \
-  -o jsonpath='Pod: {.status.instanceID.podName}{"\n"}Method: {.status.method}{"\n"}Phase: {.status.phase}{"\n"}Error: {.status.error}{"\n"}'
-
-# Check the cluster status for backup-related information
-kubectl cnpg status <cluster-name> -n <namespace> --verbose
-```
-
-### Check Sidecar Logs on the Backup Target Pod
-
-```sh
-# Identify which pod was the backup target (from the previous step)
-TARGET_POD=$(kubectl get backups.postgresql.cnpg.io \
-  -n <namespace> <backup-name> \
-  -o jsonpath='{.status.instanceID.podName}')
-echo "Backup target pod: $TARGET_POD"
-
-# Check the sidecar logs on the specific target pod
-kubectl logs -n <namespace> $TARGET_POD \
-  -c plugin-barman-cloud --tail=100
-
-# Follow the logs in real time
-kubectl logs -n <namespace> $TARGET_POD \
-  -c plugin-barman-cloud -f
-
-# Check for specific errors in the target pod around the backup time
-kubectl logs -n <namespace> $TARGET_POD \
-  -c plugin-barman-cloud --since=10m | grep -E "ERROR|FATAL|panic|failed"
-
-# Alternative: List all cluster pods and their roles
-kubectl get pods -n <namespace> -l cnpg.io/cluster=<cluster-name> \
-  -o custom-columns=NAME:.metadata.name,ROLE:.metadata.labels.cnpg\\.io/instanceRole,INSTANCE:.metadata.labels.cnpg\\.io/instanceName
-
-# Check sidecar logs on ALL cluster pods (if the target is unclear)
-for pod in $(kubectl get pods -n <namespace> -l cnpg.io/cluster=<cluster-name> -o name); do
-  echo "=== Checking $pod ==="
-  kubectl logs -n <namespace> $pod -c plugin-barman-cloud \
-    --tail=20 | grep -i error || echo "No errors found"
-done
-```
-
-### Check Events for Backup-Related Issues
-
-```sh
-# Check events for the cluster
-kubectl get events -n <namespace> \
-  --field-selector involvedObject.name=<cluster-name>
-
-# Check events for failed backups
-kubectl get events -n <namespace> \
-  --field-selector involvedObject.kind=Backup
-
-# Get all recent events in the namespace
-kubectl get events -n <namespace> --sort-by='.lastTimestamp' | tail -20
-```
-
-### Verify `ObjectStore` Configuration
-
-```sh
-# Check the ObjectStore resource
-kubectl get objectstores.barmancloud.cnpg.io \
-  -n <namespace> <objectstore-name> -o yaml
-
-# Verify the secret exists and has the correct keys
-kubectl get secret -n <namespace> <secret-name> -o yaml
-# Alternatively
-kubectl get secret -n <namespace> <secret-name> -o jsonpath='{.data}' | jq 'keys'
-```
-
-### Common Error Messages and Solutions
-
-* **"AccessDenied" or "403 Forbidden"** — Check cloud credentials and bucket permissions.
-* **"NoSuchBucket"** — Verify the bucket exists and the endpoint URL is correct.
-* **"Connection timeout"** — Check network connectivity and firewall rules.
-* **"SSL certificate problem"** — For self-signed certificates, verify the CA bundle configuration.
-

web/versioned_docs/version-0.12.0/upgrades.mdx

@@ -1,16 +0,0 @@
----
-sidebar_position: 25
----
-
-# Upgrades
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-You can upgrade the plugin simply by installing the new version. Unless
-explicitly stated below or in the release notes, no special steps are required.
-
-## Upgrading to version 0.8.x from previous versions
-
-Version **0.8.0** introduces breaking changes to resource naming.
-To complete the upgrade successfully, follow the instructions in the
-["Resource name migration guide"](resource-name-migration.md).

web/versioned_docs/version-0.12.0/usage.md

@@ -1,283 +0,0 @@
----
-sidebar_position: 30
----
-
-# Using the Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-After [installing the plugin](installation.mdx) in the same namespace as the
-CloudNativePG operator, enabling your PostgreSQL cluster to use the Barman
-Cloud Plugin involves just a few steps:
-
-- Defining the object store containing your WAL archive and base backups, using
-  your preferred [provider](object_stores.md)
-- Instructing the Postgres cluster to use the Barman Cloud Plugin
-
-From that moment, you’ll be able to issue on-demand backups or define a backup
-schedule, as well as rely on the object store for recovery operations.
-
-The rest of this page details each step, using MinIO as object store provider.
-
-## Defining the `ObjectStore`
-
-An `ObjectStore` resource must be created for each object store used in your
-PostgreSQL architecture. Here's an example configuration using MinIO:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-The `.spec.configuration` schema follows the same format as the
-[in-tree barman-cloud support](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration).
-Refer to [the CloudNativePG documentation](https://cloudnative-pg.io/documentation/current/appendixes/backup_barmanobjectstore/)
-for additional details.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::
-
-## Configuring WAL Archiving
-
-Once the `ObjectStore` is defined, you can configure your PostgreSQL cluster
-to archive WALs by referencing the store in the `.spec.plugins` section:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  instances: 3
-  imagePullPolicy: Always
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store
-  storage:
-    size: 1Gi
-```
-
-This configuration enables both WAL archiving and data directory backups.
-
-## Performing a Base Backup
-
-Once WAL archiving is enabled, the cluster is ready for backups. Backups can be
-created either declaratively (with YAML manifests) or imperatively (with the
-`cnpg` plugin).
-
-### Declarative approach (YAML manifest)
-
-Create a backup resource by applying a YAML manifest:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Backup
-metadata:
-  name: backup-example
-spec:
-  cluster:
-    name: cluster-example
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
-### Imperative approach (using the `cnpg` plugin)
-
-The quickest way to trigger an on-demand backup is with the `cnpg` plugin:
-
-```bash
-kubectl cnpg backup -n <namespace> <cluster-name> \
-  --method=plugin \
-  --plugin-name=barman-cloud.cloudnative-pg.io
-```
-
-:::note Migration from in-tree backups
-If you are migrating from the in-tree backup system, note the change in syntax:
-
-```bash
-# Old command (in-tree backup)
-kubectl cnpg backup -n <namespace> <cluster-name> --method=barmanObjectStore
-
-# New command (plugin-based backup)
-kubectl cnpg backup -n <namespace> <cluster-name> \
-  --method=plugin \
-  --plugin-name=barman-cloud.cloudnative-pg.io
-```
-:::
-
-## Restoring a Cluster
-
-To restore a cluster from an object store, create a new `Cluster` resource that
-references the store containing the backup. Below is an example configuration:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-:::important
-The above configuration does **not** enable WAL archiving for the restored cluster.
-:::
-
-To enable WAL archiving for the restored cluster, include the `.spec.plugins`
-section alongside the `externalClusters.plugin` section, as shown below:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      # Backup Object Store (push, read-write)
-      barmanObjectName: minio-store-bis
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        # Recovery Object Store (pull, read-only)
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-The same object store may be used for both transaction log archiving and
-restoring a cluster, or you can configure separate stores for these purposes.
-
-## Configuring Replica Clusters
-
-You can set up a distributed topology by combining the previously defined
-configurations with the `.spec.replica` section. Below is an example of how to
-define a replica cluster:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-dc-a
-spec:
-  instances: 3
-  primaryUpdateStrategy: unsupervised
-
-  storage:
-    storageClass: csi-hostpath-sc
-    size: 1Gi
-
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store-a
-
-  replica:
-    self: cluster-dc-a
-    primary: cluster-dc-a
-    source: cluster-dc-b
-
-  externalClusters:
-  - name: cluster-dc-a
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-a
-
-  - name: cluster-dc-b
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-b
-```
-
-## Configuring the plugin instance sidecar
-
-The Barman Cloud Plugin runs as a sidecar container next to each PostgreSQL
-instance pod. It manages backup, WAL archiving, and restore processes.
-
-Configuration comes from multiple `ObjectStore` resources:
-
-1. The one referenced in the
-   `.spec.plugins` section of the `Cluster`. This is the
-   object store used for WAL archiving and base backups.
-2. The one referenced in the external cluster
-   used in the `.spec.replica.source` section of the `Cluster`. This is
-   used by the log-shipping designated primary to get the WAL files.
-3. The one referenced in the
-   `.spec.bootstrap.recovery.source` section of the `Cluster`. Used by
-   the initial recovery job to create the cluster from an existing backup.
-
-You can fine-tune sidecar behavior in the `.spec.instanceSidecarConfiguration`
-of your ObjectStore. These settings apply to all PostgreSQL instances that use
-this object store. Any updates take effect at the next `Cluster` reconciliation,
-and could generate a rollout of the `Cluster`.
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-  # [...]
-  instanceSidecarConfiguration:
-    retentionPolicyIntervalSeconds: 1800
-    resources:
-      requests:
-        memory: "XXX"
-        cpu: "YYY"
-      limits:
-        memory: "XXX"
-        cpu: "YYY"
-```
-
-:::note
-If more than one `ObjectStore` applies, the `instanceSidecarConfiguration` of
-the one set in `.spec.plugins` has priority.
-:::

web/versioned_docs/version-0.3.0/welcome.md

@@ -1,15 +0,0 @@
----
-sidebar_position: 1
-sidebar_label: "Welcome"
----
-
-# Barman Cloud CNPG-I plugin
-
-**Status:** EXPERIMENTAL
-
-Welcome to the documentation of the [barman-cloud](https://pgbarman.org/) CNPG-I
-plugin for [CloudNativePG](https://cloudnative-pg.io/).
-
-Documentation for version **0.3.0** of the plugin is available in the
-[README](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/v0.3.0/README.md)
-on GitHub.

web/versioned_docs/version-0.4.0/compression.md

@@ -1,43 +0,0 @@
----
-sidebar_position: 80
----
-
-# Compression
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-By default, backups and WAL files are archived **uncompressed**. However, the
-Barman Cloud Plugin supports multiple compression algorithms via
-`barman-cloud-backup` and `barman-cloud-wal-archive`, allowing you to optimize
-for space, speed, or a balance of both.
-
-### Supported Compression Algorithms
-
-- `bzip2`
-- `gzip`
-- `lz4` (WAL only)
-- `snappy`
-- `xz` (WAL only)
-- `zstd` (WAL only)
-
-Compression settings for base backups and WAL archives are configured
-independently. For implementation details, refer to the corresponding API
-definitions:
-
-- [`DataBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#DataBackupConfiguration)
-- [`WALBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#WalBackupConfiguration)
-
-:::important
-Compression impacts both performance and storage efficiency. Choose the right
-algorithm based on your recovery time objectives (RTO), storage capacity, and
-network throughput.
-:::
-
-## Compression Benchmark (on MinIO)
-
-| Compression | Backup Time (ms) | Restore Time (ms) | Uncompressed Size (MB) | Compressed Size (MB) | Ratio |
-| ----------- | ---------------- | ----------------- | ---------------------- | -------------------- | ----- |
-| None        | 10,927           | 7,553             | 395                    | 395                  | 1.0:1 |
-| bzip2       | 25,404           | 13,886            | 395                    | 67                   | 5.9:1 |
-| gzip        | 116,281          | 3,077             | 395                    | 91                   | 4.3:1 |
-| snappy      | 8,134            | 8,341             | 395                    | 166                  | 2.4:1 |

web/versioned_docs/version-0.4.0/concepts.md

@@ -1,177 +0,0 @@
----
-sidebar_position: 10
----
-
-# Main Concepts
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-:::important
-Before proceeding, make sure to review the following sections of the
-CloudNativePG documentation:
-
-- [**Backup**](https://cloudnative-pg.io/documentation/current/backup/)
-- [**WAL Archiving**](https://cloudnative-pg.io/documentation/current/wal_archiving/)
-- [**Recovery**](https://cloudnative-pg.io/documentation/current/recovery/)
-:::
-
-The **Barman Cloud Plugin** enables **hot (online) backups** of PostgreSQL
-clusters in CloudNativePG through [`barman-cloud`](https://pgbarman.org),
-supporting continuous physical backups and WAL archiving to an **object
-store**—without interrupting write operations.
-
-It also supports both **full recovery** and **Point-in-Time Recovery (PITR)**
-of a PostgreSQL cluster.
-
-## The Object Store
-
-At the core is the [`ObjectStore` custom resource (CRD)](plugin-barman-cloud.v1.md#objectstorespec),
-which acts as the interface between the PostgreSQL cluster and the target
-object storage system. It allows you to configure:
-
-- **Authentication and bucket location** via the `.spec.configuration` section
-- **WAL archiving** settings—such as compression type, parallelism, and
-  server-side encryption—under `.spec.configuration.wal`
-- **Base backup options**—with similar settings for compression, concurrency,
-  and encryption—under `.spec.configuration.data`
-- **Retention policies** to manage the life-cycle of archived WALs and backups
-  via `.spec.configuration.retentionPolicy`
-
-WAL files are archived in the `wals` directory, while base backups are stored
-as **tarballs** in the `base` directory, following the
-[Barman Cloud convention](https://docs.pgbarman.org/cloud/latest/usage/#object-store-layout).
-
-The plugin also offers advanced capabilities, including
-[backup tagging](misc.md#backup-object-tagging) and
-[extra options for backups and WAL archiving](misc.md#extra-options-for-backup-and-wal-archiving).
-
-:::tip
-For details, refer to the
-[API reference for the `ObjectStore` resource](plugin-barman-cloud.v1.md#objectstorespec).
-:::
-
-## Integration with a CloudNativePG Cluster
-
-CloudNativePG can delegate continuous backup and recovery responsibilities to
-the **Barman Cloud Plugin** by configuring the `.spec.plugins` section of a
-`Cluster` resource. This setup requires a corresponding `ObjectStore` resource
-to be defined.
-
-:::important
-While it is technically possible to reuse the same `ObjectStore` for multiple
-`Cluster` resources within the same namespace, it is strongly recommended to
-dedicate one object store per PostgreSQL cluster to ensure data isolation and
-operational clarity.
-:::
-
-The following example demonstrates how to configure a CloudNativePG cluster
-named `cluster-example` to use a previously defined `ObjectStore` (also named
-`cluster-example`) in the same namespace. Setting `isWALArchiver: true` enables
-WAL archiving through the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  # Other cluster settings...
-  plugins:
-    - name: barman-cloud.cloudnative-pg.io
-      isWALArchiver: true
-      parameters:
-        barmanObjectName: cluster-example
-```
-
-## Backup of a Postgres Cluster
-
-Once the object store is defined and the `Cluster` is configured to use the
-Barman Cloud Plugin, **WAL archiving is activated immediately** on the
-PostgreSQL primary.
-
-Physical base backups are seamlessly managed by CloudNativePG using the
-`Backup` and `ScheduledBackup` resources, respectively for
-[on-demand](https://cloudnative-pg.io/documentation/current/backup/#on-demand-backups)
-and
-[scheduled](https://cloudnative-pg.io/documentation/current/backup/#scheduled-backups)
-backups.
-
-To use the Barman Cloud Plugin, you must set the `method` to `plugin` and
-configure the `pluginConfiguration` section as shown:
-
-```yaml
-[...]
-spec:
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-  [...]
-```
-
-With this configuration, CloudNativePG supports:
-
-- Backups from both **primary** and **standby** instances
-- Backups from **designated primaries** in a distributed topology using
-  [replica clusters](https://cloudnative-pg.io/documentation/current/replica_cluster/)
-
-:::tip
-For details on how to back up from a standby, refer to the official documentation:
-[Backup from a standby](https://cloudnative-pg.io/documentation/current/backup/#backup-from-a-standby).
-:::
-
-:::important
-Both backup and WAL archiving operations are executed by sidecar containers
-running in the same pod as the PostgreSQL `Cluster` primary instance—except
-when backups are taken from a standby, in which case the sidecar runs alongside
-the standby pod.
-The sidecar containers use a [dedicated container image](images.md) that
-includes only the supported version of Barman Cloud.
-:::
-
-## Recovery of a Postgres Cluster
-
-In PostgreSQL, *recovery* refers to the process of starting a database instance
-from an existing backup.  The Barman Cloud Plugin integrates with CloudNativePG
-to support both **full recovery** and **Point-in-Time Recovery (PITR)** from an
-object store.
-
-Recovery in this context is *not in-place*: it bootstraps a brand-new
-PostgreSQL cluster from a backup and replays the necessary WAL files to reach
-the desired recovery target.
-
-To perform a recovery, define an *external cluster* that references the
-appropriate `ObjectStore`, and use it as the source in the `bootstrap` section
-of the target cluster:
-
-```yaml
-[...]
-spec:
-  [...]
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: cluster-example
-        serverName: cluster-example
-  [...]
-```
-
-The critical element here is the `externalClusters` section of the `Cluster`
-resource, where the `plugin` stanza instructs CloudNativePG to use the Barman
-Cloud Plugin to access the object store for recovery.
-
-This same mechanism can be used for a variety of scenarios enabled by the
-CloudNativePG API, including:
-
-* **Full cluster recovery** from the latest backup
-* **Point-in-Time Recovery (PITR)**
-* Bootstrapping **replica clusters** in a distributed topology
-
-:::tip
-For complete instructions and advanced use cases, refer to the official
-[Recovery documentation](https://cloudnative-pg.io/documentation/current/recovery/).
-:::

web/versioned_docs/version-0.4.0/images.md

@@ -1,37 +0,0 @@
----
-sidebar_position: 99
----
-
-# Container Images
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin is distributed using two container images:
-
-- One for deploying the plugin components
-- One for the sidecar that runs alongside each PostgreSQL instance in a
-  CloudNativePG `Cluster` using the plugin
-
-## Plugin Container Image
-
-The plugin image contains the logic required to operate the Barman Cloud Plugin
-within your Kubernetes environment with CloudNativePG. It is published on the
-GitHub Container Registry at `ghcr.io/cloudnative-pg/plugin-barman-cloud`.
-
-This image is built from the
-[`Dockerfile.plugin`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.plugin)
-in the plugin repository.
-
-## Sidecar Container Image
-
-The sidecar image is used within each PostgreSQL pod in the cluster. It
-includes the latest supported version of Barman Cloud and is responsible for
-performing WAL archiving and backups on behalf of CloudNativePG.
-
-It is available at `ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar` and is
-built from the
-[`Dockerfile.sidecar`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.sidecar).
-
-These sidecar images are designed to work seamlessly with the
-[`minimal` PostgreSQL container images](https://github.com/cloudnative-pg/postgres-containers?tab=readme-ov-file#minimal-images)
-maintained by the CloudNativePG Community.

web/versioned_docs/version-0.4.0/installation.md

@@ -1,117 +0,0 @@
----
-sidebar_position: 20
----
-
-# Installation
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-:::important
-1. The plugin **must** be installed in the same namespace as the CloudNativePG
-   operator (typically `cnpg-system`).
-
-2. Keep in mind that the operator's **listening namespaces** may differ from its
-   installation namespace. Double-check this to avoid configuration issues.
-:::
-
-## Verifying the Requirements
-
-Before installing the plugin, make sure the [requirements](intro.md#requirements) are met.
-
-### CloudNativePG Version
-
-Ensure you're running a version of CloudNativePG that is compatible with the
-plugin. If installed in the default `cnpg-system` namespace, you can verify the
-version with:
-
-```sh
-kubectl get deployment -n cnpg-system cnpg-controller-manager -o yaml \
-  | grep ghcr.io/cloudnative-pg/cloudnative-pg
-```
-
-Example output:
-
-```output
-image: ghcr.io/cloudnative-pg/cloudnative-pg:1.26.0
-```
-
-The version **must be 1.26 or newer**.
-
-### cert-manager
-
-Use the [cmctl](https://cert-manager.io/docs/reference/cmctl/#installation)
-tool to confirm that `cert-manager` is installed and available:
-
-```sh
-cmctl check api
-```
-
-Example output:
-
-```output
-The cert-manager API is ready
-```
-
-Both checks are required before proceeding with the installation.
-
-## Installing the Barman Cloud Plugin
-
-Install the plugin using `kubectl` by applying the manifest for the latest
-release:
-
-<!-- x-release-please-start-version -->
-
-```sh
-kubectl apply -f \
-  https://github.com/cloudnative-pg/plugin-barman-cloud/releases/download/v0.4.0/manifest.yaml
-```
-
-<!-- x-release-please-end -->
-
-Example output:
-
-```output
-customresourcedefinition.apiextensions.k8s.io/objectstores.barmancloud.cnpg.io created
-serviceaccount/plugin-barman-cloud created
-role.rbac.authorization.k8s.io/leader-election-role created
-clusterrole.rbac.authorization.k8s.io/metrics-auth-role created
-clusterrole.rbac.authorization.k8s.io/metrics-reader created
-clusterrole.rbac.authorization.k8s.io/objectstore-editor-role created
-clusterrole.rbac.authorization.k8s.io/objectstore-viewer-role created
-clusterrole.rbac.authorization.k8s.io/plugin-barman-cloud created
-rolebinding.rbac.authorization.k8s.io/leader-election-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/metrics-auth-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/plugin-barman-cloud-binding created
-secret/plugin-barman-cloud-8tfddg42gf created
-service/barman-cloud created
-deployment.apps/barman-cloud configured
-certificate.cert-manager.io/barman-cloud-client created
-certificate.cert-manager.io/barman-cloud-server created
-issuer.cert-manager.io/selfsigned-issuer created
-```
-
-Finally, check that the deployment is up and running:
-
-```sh
-kubectl rollout status deployment \
-  -n cnpg-system barman-cloud
-```
-
-Example output:
-
-```output
-deployment "barman-cloud" successfully rolled out
-```
-
-This confirms that the plugin is deployed and ready to use.
-
-## Testing the latest development snapshot
-
-You can also test the latest development snapshot of the plugin with the
-following command:
-
-```sh
-kubectl apply -f \
-  https://raw.githubusercontent.com/cloudnative-pg/plugin-barman-cloud/refs/heads/main/manifest.yaml
-```
-

web/versioned_docs/version-0.4.0/intro.md

@@ -1,67 +0,0 @@
----
-sidebar_position: 1
-sidebar_label: "Introduction"
----
-
-# Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The **Barman Cloud Plugin** for [CloudNativePG](https://cloudnative-pg.io/)
-enables online continuous physical backups of PostgreSQL clusters to object storage
-using the `barman-cloud` suite from the [Barman](https://docs.pgbarman.org/release/latest/)
-project.
-
-:::important
-If you plan to migrate your existing CloudNativePG cluster to the new
-plugin-based approach using the Barman Cloud Plugin, see
-["Migrating from Built-in CloudNativePG Backup"](migration.md)
-for detailed instructions.
-:::
-
-## Requirements
-
-To use the Barman Cloud Plugin, you need:
-
-- [CloudNativePG](https://cloudnative-pg.io) version **1.26** <!-- ADD WHEN 1.27 IS OUT "or later" -->
-- [cert-manager](https://cert-manager.io/) to enable TLS communication between
-  the plugin and the operator
-
-## Key Features
-
-This plugin provides the following capabilities:
-
-- Physical online backup of the data directory
-- Physical restore of the data directory
-- Write-Ahead Log (WAL) archiving
-- WAL restore
-- Full cluster recovery
-- Point-in-Time Recovery (PITR)
-- Seamless integration with replica clusters for bootstrap and WAL restore from archive
-
-:::important
-The Barman Cloud Plugin is designed to **replace the in-tree object storage support**
-previously provided via the `.spec.backup.barmanObjectStore` section in the
-`Cluster` resource.
-Backups created using the in-tree approach are fully supported and compatible
-with this plugin.
-:::
-
-## Supported Object Storage Providers
-
-The plugin works with all storage backends supported by `barman-cloud`, including:
-
-- **Amazon S3**
-- **Google Cloud Storage**
-- **Microsoft Azure Blob Storage**
-
-In addition, the following S3-compatible and simulator solutions have been
-tested and verified:
-
-- [MinIO](https://min.io/) – An S3-compatible storage solution
-- [Azurite](https://github.com/Azure/Azurite) – A simulator for Azure Blob Storage
-- [fake-gcs-server](https://github.com/fsouza/fake-gcs-server) – A simulator for Google Cloud Storage
-
-:::tip
-For more details, refer to [Object Store Providers](object_stores.md).
-:::

web/versioned_docs/version-0.4.0/migration.md

@@ -1,259 +0,0 @@
----
-sidebar_position: 40
----
-
-# Migrating from Built-in CloudNativePG Backup
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The in-tree support for Barman Cloud in CloudNativePG is **deprecated starting
-from version 1.26** and will be removed in a future release.
-
-If you're currently relying on the built-in Barman Cloud integration, you can
-migrate seamlessly to the new **plugin-based architecture** using the Barman
-Cloud Plugin, with **no downtime**. Follow these steps:
-
-- [Install the Barman Cloud Plugin](installation.md)
-- Create an `ObjectStore` resource by translating the contents of the
-  `.spec.backup.barmanObjectStore` section from your existing `Cluster`
-  definition
-- Modify the `Cluster` resource in a single atomic change to switch from
-  in-tree backup to the plugin
-- Update any `ScheduledBackup` resources to use the plugin
-- Update the `externalClusters` configuration, where applicable
-
-:::tip
-For a working example, refer to [this commit](https://github.com/cloudnative-pg/cnpg-playground/commit/596f30e252896edf8f734991c3538df87630f6f7)
-from the [CloudNativePG Playground project](https://github.com/cloudnative-pg/cnpg-playground),
-which demonstrates a full migration.
-:::
-
----
-
-## Step 1: Define the `ObjectStore`
-
-Begin by creating an `ObjectStore` resource in the same namespace as your
-PostgreSQL `Cluster`.
-
-There is a **direct mapping** between the `.spec.backup.barmanObjectStore`
-section in CloudNativePG and the `.spec.configuration` field in the
-`ObjectStore` CR. The conversion is mostly mechanical, with one key difference:
-
-:::warning
-In the plugin architecture, retention policies are defined as part of the `ObjectStore`.
-In contrast, the in-tree implementation defined them at the `Cluster` level.
-:::
-
-If your `Cluster` used `.spec.backup.retentionPolicy`, move that configuration
-to `.spec.retentionPolicy` in the `ObjectStore`.
-
----
-
-### Example
-
-Here’s an excerpt from a traditional in-tree CloudNativePG backup configuration
-taken from the CloudNativePG Playground project:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-eu
-spec:
-  # [...]
-  backup:
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-This configuration translates to the following `ObjectStore` resource for the
-plugin:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-As you can see, the contents of `barmanObjectStore` have been copied directly
-under the `configuration` field of the `ObjectStore` resource, using the same
-secret references.
-
-## Step 2: Update the `Cluster` for plugin WAL archiving
-
-Once the `ObjectStore` resource is in place, update the `Cluster` resource as
-follows in a single atomic change:
-
-- Remove the `.spec.backup.barmanObjectStore` section
-- Remove `.spec.backup.retentionPolicy` if it was defined (as it is now in the
-  `ObjectStore`)
-- Remove the entire `spec.backup` section if it is now empty
-- Add `barman-cloud.cloudnative-pg.io` to the `plugins` list, as described in
-  [Configuring WAL archiving](usage.md#configuring-wal-archiving)
-
-This will trigger a rolling update of the `Cluster`, switching continuous
-backup from the in-tree implementation to the plugin-based approach.
-
-### Example
-
-The updated `pg-eu` cluster will have this configuration instead of the
-previous `backup` section:
-
-```yaml
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-eu
-```
-
----
-
-## Step 3: Update the `ScheduledBackup`
-
-After switching the `Cluster` to use the plugin, update your `ScheduledBackup`
-resources to match.
-
-Set the backup `method` to `plugin` and reference the plugin name via
-`pluginConfiguration`, as shown in ["Performing a base backup"](usage.md#performing-a-base-backup).
-
-### Example
-
-Original in-tree `ScheduledBackup`:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-```
-
-Updated version using the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
----
-
-## Step 4: Update the `externalClusters` configuration
-
-If your `Cluster` relies on one or more external clusters that use the in-tree
-Barman Cloud integration, you need to update those configurations to use the
-plugin-based architecture.
-
-When a replica cluster fetches WAL files or base backups from an external
-source that used the built-in backup method, follow these steps:
-
-1. Create a corresponding `ObjectStore` resource for the external cluster, as
-   shown in [Step 1](#step-1-define-the-objectstore)
-2. Update the `externalClusters` section of your replica cluster to use the
-   plugin instead of the in-tree `barmanObjectStore` field
-
-### Example
-
-Consider the original configuration using in-tree Barman Cloud:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      serverName: pg-eu
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-Create the `ObjectStore` resource for the external cluster:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-    accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-    secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-Update the external cluster configuration to use the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-eu
-        serverName: pg-eu
-```

web/versioned_docs/version-0.4.0/misc.md

@@ -1,76 +0,0 @@
----
-sidebar_position: 90
----
-
-# Miscellaneous
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-## Backup Object Tagging
-
-You can attach key-value metadata tags to backup artifacts—such as base
-backups, WAL files, and history files—via the `.spec.configuration` section of
-the `ObjectStore` resource.
-
-- `tags`: applied to base backups and WAL files
-- `historyTags`: applied to history files only
-
-### Example
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    [...]
-    tags:
-      backupRetentionPolicy: "expire"
-    historyTags:
-      backupRetentionPolicy: "keep"
-  [...]
-```
-
-## Extra Options for Backup and WAL Archiving
-
-You can pass additional command-line arguments to `barman-cloud-backup` and
-`barman-cloud-wal-archive` using the `additionalCommandArgs` field in the
-`ObjectStore` configuration.
-
-- `.spec.configuration.data.additionalCommandArgs`: for `barman-cloud-backup`
-- `.spec.configuration.wal.additionalCommandArgs`: for `barman-cloud-wal-archive`
-
-Each field accepts a list of string arguments. If an argument is already
-configured elsewhere in the plugin, the duplicate will be ignored.
-
-### Example: Extra Backup Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    data:
-      additionalCommandArgs:
-        - "--min-chunk-size=5MB"
-        - "--read-timeout=60"
-```
-
-### Example: Extra WAL Archive Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    wal:
-      additionalCommandArgs:
-        - "--max-concurrency=1"
-        - "--read-timeout=60"
-```
-
-For a complete list of supported options, refer to the
-[official Barman Cloud documentation](https://docs.pgbarman.org/release/latest/).

web/versioned_docs/version-0.4.0/object_stores.md

@@ -1,465 +0,0 @@
----
-sidebar_position: 50
----
-
-# Object Store Providers
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin enables the storage of PostgreSQL cluster backup files
-in any object storage service supported by the
-[Barman Cloud infrastructure](https://docs.pgbarman.org/release/latest/).
-
-Currently, Barman Cloud supports the following providers:
-
-- [Amazon S3](#aws-s3)
-- [Microsoft Azure Blob Storage](#azure-blob-storage)
-- [Google Cloud Storage](#google-cloud-storage)
-
-You may also use any S3- or Azure-compatible implementation of the above
-services.
-
-To configure object storage with Barman Cloud, you must define an
-[`ObjectStore` object](plugin-barman-cloud.v1.md#objectstore), which
-establishes the connection between your PostgreSQL cluster and the object
-storage backend.
-
-Configuration details — particularly around authentication — will vary depending on
-the specific object storage provider you are using.
-
-The following sections detail the setup for each.
-
----
-
-## AWS S3
-
-[AWS Simple Storage Service (S3)](https://aws.amazon.com/s3/) is one of the
-most widely adopted object storage solutions.
-
-The Barman Cloud plugin for CloudNativePG integrates with S3 through two
-primary authentication mechanisms:
-
-- [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) —
-  recommended for clusters running on EKS
-- Access keys — using `ACCESS_KEY_ID` and `ACCESS_SECRET_KEY` credentials
-
-### Access Keys
-
-To authenticate using access keys, you’ll need:
-
-- `ACCESS_KEY_ID`: the public key used to authenticate to S3
-- `ACCESS_SECRET_KEY`: the corresponding secret key
-- `ACCESS_SESSION_TOKEN`: (optional) a temporary session token, if required
-
-These credentials must be stored securely in a Kubernetes secret:
-
-```sh
-kubectl create secret generic aws-creds \
-  --from-literal=ACCESS_KEY_ID=<access key here> \
-  --from-literal=ACCESS_SECRET_KEY=<secret key here>
-# --from-literal=ACCESS_SESSION_TOKEN=<session token here> # if required
-```
-
-The credentials will be encrypted at rest if your Kubernetes environment
-supports it.
-
-You can then reference the secret in your `ObjectStore` definition:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: aws-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    s3Credentials:
-      accessKeyId:
-        name: aws-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: aws-creds
-        key: ACCESS_SECRET_KEY
-  [...]
-```
-
-### IAM Role for Service Account (IRSA)
-
-To use IRSA with EKS, configure the service account of the PostgreSQL cluster
-with the appropriate annotation:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  [...]
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        eks.amazonaws.com/role-arn: arn:[...]
-        [...]
-```
-
-### S3 Lifecycle Policy
-
-Barman Cloud uploads backup files to S3 but does not modify them afterward.
-To enhance data durability and protect against accidental or malicious loss,
-it's recommended to implement the following best practices:
-
-- Enable object versioning
-- Enable object locking to prevent objects from being deleted or overwritten
-  for a defined period or indefinitely (this provides an additional layer of
-  protection against accidental deletion and ransomware attacks)
-- Set lifecycle rules to expire current versions a few days after your Barman
-  retention window
-- Expire non-current versions after a longer period
-
-These strategies help you safeguard backups without requiring broad delete
-permissions, ensuring both security and compliance with minimal operational
-overhead.
-
-
-### S3-Compatible Storage Providers
-
-You can use S3-compatible services like **MinIO**, **Linode (Akamai) Object Storage**,
-or **DigitalOcean Spaces** by specifying a custom `endpointURL`.
-
-Example with Linode (Akamai) Object Storage (`us-east1`):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: linode-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/"
-    endpointURL: "https://us-east1.linodeobjects.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-Example with DigitalOcean Spaces (SFO3, path-style):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: digitalocean-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    endpointURL: "https://sfo3.digitaloceanspaces.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-### Using Object Storage with a Private CA
-
-For object storage services (e.g., MinIO) that use HTTPS with certificates
-signed by a private CA, set the `endpointCA` field in the `ObjectStore`
-definition. Unless you already have it, create a Kubernetes `Secret` with the
-CA bundle:
-
-```sh
-kubectl create secret generic my-ca-secret --from-file=ca.crt
-```
-
-Then reference it:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    endpointURL: <myEndpointURL>
-    endpointCA:
-      name: my-ca-secret
-      key: ca.crt
-  [...]
-```
-
-<!-- TODO: does this also apply to the plugin? -->
-:::note
-If you want `ConfigMaps` and `Secrets` to be **automatically** reloaded by
-instances, you can add a label with the key `cnpg.io/reload` to the
-`Secrets`/`ConfigMaps`. Otherwise, you will have to reload the instances using the
-`kubectl cnpg reload` subcommand.
-:::
-
----
-
-## Azure Blob Storage
-
-[Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/)
-is Microsoft’s cloud-based object storage solution.
-
-Barman Cloud supports the following authentication methods:
-
-- [Connection String](https://learn.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string)
-- Storage Account Name + [Access Key](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage)
-- Storage Account Name + [SAS Token](https://learn.microsoft.com/en-us/azure/storage/blobs/sas-service-create)
-- [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/introduction.html)
-
-### Azure AD Workload Identity
-
-This method avoids storing credentials in Kubernetes via the
-`.spec.configuration.inheritFromAzureAD` option:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      inheritFromAzureAD: true
-  [...]
-```
-
-### Access Key, SAS Token, or Connection String
-
-Store credentials in a Kubernetes secret:
-
-```sh
-kubectl create secret generic azure-creds \
-  --from-literal=AZURE_STORAGE_ACCOUNT=<storage account name> \
-  --from-literal=AZURE_STORAGE_KEY=<storage account key> \
-  --from-literal=AZURE_STORAGE_SAS_TOKEN=<SAS token> \
-  --from-literal=AZURE_STORAGE_CONNECTION_STRING=<connection string>
-```
-
-Then reference the required keys in your `ObjectStore`:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      connectionString:
-        name: azure-creds
-        key: AZURE_CONNECTION_STRING
-      storageAccount:
-        name: azure-creds
-        key: AZURE_STORAGE_ACCOUNT
-      storageKey:
-        name: azure-creds
-        key: AZURE_STORAGE_KEY
-      storageSasToken:
-        name: azure-creds
-        key: AZURE_STORAGE_SAS_TOKEN
-  [...]
-```
-
-For Azure Blob, the destination path format is:
-
-```
-<http|https>://<account-name>.<service-name>.core.windows.net/<container>/<blob>
-```
-
-### Azure-Compatible Providers
-
-If you're using a different implementation (e.g., Azurite or emulator):
-
-```
-<http|https>://<local-machine-address>:<port>/<account-name>/<container>/<blob>
-```
-
----
-
-## Google Cloud Storage
-
-[Google Cloud Storage](https://cloud.google.com/storage/) is supported with two
-authentication modes:
-
-- **GKE Workload Identity** (recommended inside Google Kubernetes Engine)
-- **Service Account JSON key** via the `GOOGLE_APPLICATION_CREDENTIALS` environment variable
-
-### GKE Workload Identity
-
-Use the [Workload Identity authentication](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
-when running in GKE:
-
-1. Set `googleCredentials.gkeEnvironment` to `true` in the `ObjectStore`
-   resource
-2. Annotate the `serviceAccountTemplate` in the `Cluster` resource with the GCP
-   service account
-
-For example, in the `ObjectStore` resource:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      gkeEnvironment: true
-```
-
-And in the `Cluster` resource:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        iam.gke.io/gcp-service-account: [...].iam.gserviceaccount.com
-```
-
-### Service Account JSON Key
-
-Follow Google’s [authentication setup](https://cloud.google.com/docs/authentication/getting-started),
-then:
-
-```sh
-kubectl create secret generic backup-creds --from-file=gcsCredentials=gcs_credentials_file.json
-```
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      applicationCredentials:
-        name: backup-creds
-        key: gcsCredentials
-  [...]
-```
-
-:::important
-This authentication method generates a JSON file within the container
-with all the credentials required to access your Google Cloud Storage
-bucket. As a result, if someone gains access to the `Pod`, they will also have
-write permissions to the bucket.
-:::
-
----
-
-
-## MinIO Gateway
-
-MinIO Gateway can proxy requests to cloud object storage providers like S3 or GCS.
-For more information, refer to [MinIO official documentation](https://docs.min.io/).
-
-### Setup
-
-Create MinIO access credentials:
-
-```sh
-kubectl create secret generic minio-creds \
-  --from-literal=MINIO_ACCESS_KEY=<minio access key> \
-  --from-literal=MINIO_SECRET_KEY=<minio secret key>
-```
-
-:::note
-Cloud Object Storage credentials will be used only by MinIO Gateway in this
-case.
-:::
-
-Expose MinIO Gateway via `ClusterIP`:
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: minio-gateway-service
-spec:
-  type: ClusterIP
-  ports:
-    - port: 9000
-      targetPort: 9000
-      protocol: TCP
-  selector:
-    app: minio
-```
-
-Here follows an excerpt of an example of deployment relaying to S3:
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-[...]
-spec:
-  containers:
-  - name: minio
-    image: minio/minio:RELEASE.2020-06-03T22-13-49Z
-    args: ["gateway", "s3"]
-    ports:
-    - containerPort: 9000
-    env:
-    - 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
-    - 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
-```
-
-Proceed by configuring MinIO Gateway service as the `endpointURL` in the
-`ObjectStore` definition, then choose a bucket name to replace `BUCKET_NAME`:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    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
-  [...]
-```
-
-:::important
-Verify on `s3://BUCKET_NAME/` the presence of archived WAL files before
-proceeding with a backup.
-:::
-
----

web/versioned_docs/version-0.4.0/parameters.md

@@ -1,19 +0,0 @@
----
-sidebar_position: 100
----
-
-# Parameters
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The following parameters are available for the Barman Cloud Plugin:
-
-- `barmanObjectName`: references the `ObjectStore` resource to be used by the
-  plugin.
-- `serverName`: Specifies the server name in the object store.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::

web/versioned_docs/version-0.4.0/plugin-barman-cloud.v1.md

@@ -1,105 +0,0 @@
-# API Reference
-
-## Packages
-- [barmancloud.cnpg.io/v1](#barmancloudcnpgiov1)
-
-
-## barmancloud.cnpg.io/v1
-
-Package v1 contains API Schema definitions for the barmancloud v1 API group
-
-### Resource Types
-- [ObjectStore](#objectstore)
-
-
-
-#### InstanceSidecarConfiguration
-
-
-
-InstanceSidecarConfiguration defines the configuration for the sidecar that runs in the instance pods.
-
-
-
-_Appears in:_
-- [ObjectStoreSpec](#objectstorespec)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `env` _[EnvVar](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#envvar-v1-core) array_ | The environment to be explicitly passed to the sidecar |  |  |  |
-| `retentionPolicyIntervalSeconds` _integer_ | The retentionCheckInterval defines the frequency at which the<br />system checks and enforces retention policies. |  | 1800 |  |
-| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | Resources define cpu/memory requests and limits for the sidecar that runs in the instance pods. |  |  |  |
-
-
-#### ObjectStore
-
-
-
-ObjectStore is the Schema for the objectstores API.
-
-
-
-
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `apiVersion` _string_ | `barmancloud.cnpg.io/v1` | True | | |
-| `kind` _string_ | `ObjectStore` | True | | |
-| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | True |  |  |
-| `spec` _[ObjectStoreSpec](#objectstorespec)_ | Specification of the desired behavior of the ObjectStore.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status | True |  |  |
-| `status` _[ObjectStoreStatus](#objectstorestatus)_ | Most recently observed status of the ObjectStore. This data may not be up to<br />date. Populated by the system. Read-only.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status |  |  |  |
-
-
-#### ObjectStoreSpec
-
-
-
-ObjectStoreSpec defines the desired state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `configuration` _[BarmanObjectStoreConfiguration](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration)_ | The configuration for the barman-cloud tool suite | True |  |  |
-| `retentionPolicy` _string_ | RetentionPolicy is the retention policy to be used for backups<br />and WALs (i.e. '60d'). The retention policy is expressed in the form<br />of `XXu` where `XX` is a positive integer and `u` is in `[dwm]` -<br />days, weeks, months. |  |  | Pattern: `^[1-9][0-9]*[dwm]$` <br /> |
-| `instanceSidecarConfiguration` _[InstanceSidecarConfiguration](#instancesidecarconfiguration)_ | The configuration for the sidecar that runs in the instance pods |  |  |  |
-
-
-#### ObjectStoreStatus
-
-
-
-ObjectStoreStatus defines the observed state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `serverRecoveryWindow` _object (keys:string, values:[RecoveryWindow](#recoverywindow))_ | ServerRecoveryWindow maps each server to its recovery window | True |  |  |
-
-
-#### RecoveryWindow
-
-
-
-RecoveryWindow represents the time span between the first
-recoverability point and the last successful backup of a PostgreSQL
-server, defining the period during which data can be restored.
-
-
-
-_Appears in:_
-- [ObjectStoreStatus](#objectstorestatus)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `firstRecoverabilityPoint` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The first recoverability point in a PostgreSQL server refers to<br />the earliest point in time to which the database can be<br />restored. | True |  |  |
-| `lastSuccussfulBackupTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The last successful backup time | True |  |  |
-
-

web/versioned_docs/version-0.4.0/retention.md

@@ -1,38 +0,0 @@
----
-sidebar_position: 60
----
-
-# Retention Policies
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin supports **automated cleanup of obsolete backups** via
-retention policies, configured in the `.spec.retentionPolicy` field of the
-`ObjectStore` resource.
-
-:::note
-This feature uses the `barman-cloud-backup-delete` command with the
-`--retention-policy "RECOVERY WINDOW OF {{ value }} {{ unit }}"` syntax.
-:::
-
-#### Example: 30-Day Retention Policy
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  [...]
-  retentionPolicy: "30d"
-````
-
-:::note
-A **recovery window retention policy** ensures the cluster can be restored to
-any point in time between the calculated *Point of Recoverability* (PoR) and
-the latest WAL archive. The PoR is defined as `current time - recovery window`.
-The **first valid backup** is the most recent backup completed before the PoR.
-Backups older than that are marked as *obsolete* and deleted after the next
-backup completes.
-:::
-

web/versioned_docs/version-0.4.0/usage.md

@@ -1,258 +0,0 @@
----
-sidebar_position: 30
----
-
-# Using the Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-After [installing the plugin](installation.md) in the same namespace as the
-CloudNativePG operator, enabling your PostgreSQL cluster to use the Barman
-Cloud Plugin involves just a few steps:
-
-- Defining the object store containing your WAL archive and base backups, using
-  your preferred [provider](object_stores.md)
-- Instructing the Postgres cluster to use the Barman Cloud Plugin
-
-From that moment, you’ll be able to issue on-demand backups or define a backup
-schedule, as well as rely on the object store for recovery operations.
-
-The rest of this page details each step, using MinIO as object store provider.
-
-## Defining the `ObjectStore`
-
-An `ObjectStore` resource must be created for each object store used in your
-PostgreSQL architecture. Here's an example configuration using MinIO:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-The `.spec.configuration` schema follows the same format as the
-[in-tree barman-cloud support](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration).
-Refer to [the CloudNativePG documentation](https://cloudnative-pg.io/documentation/current/appendixes/backup_barmanobjectstore/)
-for additional details.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::
-
-## Configuring WAL Archiving
-
-Once the `ObjectStore` is defined, you can configure your PostgreSQL cluster
-to archive WALs by referencing the store in the `.spec.plugins` section:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  instances: 3
-  imagePullPolicy: Always
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store
-  storage:
-    size: 1Gi
-```
-
-This configuration enables both WAL archiving and data directory backups.
-
-## Performing a Base Backup
-
-Once WAL archiving is enabled, the cluster is ready for backups. To issue an
-on-demand backup, use the following configuration with the plugin method:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Backup
-metadata:
-  name: backup-example
-spec:
-  cluster:
-    name: cluster-example
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
-:::note
-You can apply the same concept to the `ScheduledBackup` resource.
-:::
-
-## Restoring a Cluster
-
-To restore a cluster from an object store, create a new `Cluster` resource that
-references the store containing the backup. Below is an example configuration:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-:::important
-The above configuration does **not** enable WAL archiving for the restored cluster.
-:::
-
-To enable WAL archiving for the restored cluster, include the `.spec.plugins`
-section alongside the `externalClusters.plugin` section, as shown below:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      # Backup Object Store (push, read-write)
-      barmanObjectName: minio-store-bis
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        # Recovery Object Store (pull, read-only)
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-The same object store may be used for both transaction log archiving and
-restoring a cluster, or you can configure separate stores for these purposes.
-
-## Configuring Replica Clusters
-
-You can set up a distributed topology by combining the previously defined
-configurations with the `.spec.replica` section. Below is an example of how to
-define a replica cluster:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-dc-a
-spec:
-  instances: 3
-  primaryUpdateStrategy: unsupervised
-
-  storage:
-    storageClass: csi-hostpath-sc
-    size: 1Gi
-
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store-a
-
-  replica:
-    self: cluster-dc-a
-    primary: cluster-dc-a
-    source: cluster-dc-b
-
-  externalClusters:
-  - name: cluster-dc-a
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-a
-
-  - name: cluster-dc-b
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-b
-```
-
-## Configuring the plugin instance sidecar
-
-The Barman Cloud Plugin runs as a sidecar container next to each PostgreSQL
-instance pod. It manages backup, WAL archiving, and restore processes.
-
-Configuration comes from multiple `ObjectStore` resources:
-
-1. The one referenced in the
-   `.spec.plugins` section of the `Cluster`. This is the
-   object store used for WAL archiving and base backups.
-2. The one referenced in the external cluster
-   used in the `.spec.replica.source` section of the `Cluster`. This is
-   used by the log-shipping designated primary to get the WAL files.
-3. The one referenced in the
-   `.spec.bootstrap.recovery.source` section of the `Cluster`. Used by
-   the initial recovery job to create the cluster from an existing backup.
-
-You can fine-tune sidecar behavior in the `.spec.instanceSidecarConfiguration`
-of your ObjectStore. These settings apply to all PostgreSQL instances that use
-this object store. Any updates take effect at the next `Cluster` reconciliation,
-and could generate a rollout of the `Cluster`.
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-  # [...]
-  instanceSidecarConfiguration:
-    retentionPolicyIntervalSeconds: 1800
-    resources:
-      requests:
-        memory: "XXX"
-        cpu: "YYY"
-      limits:
-        memory: "XXX"
-        cpu: "YYY"
-```
-
-:::note
-If more than one `ObjectStore` applies, the `instanceSidecarConfiguration` of
-the one set in `.spec.plugins` has priority.
-:::

web/versioned_docs/version-0.4.1/compression.md

@@ -1,43 +0,0 @@
----
-sidebar_position: 80
----
-
-# Compression
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-By default, backups and WAL files are archived **uncompressed**. However, the
-Barman Cloud Plugin supports multiple compression algorithms via
-`barman-cloud-backup` and `barman-cloud-wal-archive`, allowing you to optimize
-for space, speed, or a balance of both.
-
-### Supported Compression Algorithms
-
-- `bzip2`
-- `gzip`
-- `lz4` (WAL only)
-- `snappy`
-- `xz` (WAL only)
-- `zstd` (WAL only)
-
-Compression settings for base backups and WAL archives are configured
-independently. For implementation details, refer to the corresponding API
-definitions:
-
-- [`DataBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#DataBackupConfiguration)
-- [`WALBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#WalBackupConfiguration)
-
-:::important
-Compression impacts both performance and storage efficiency. Choose the right
-algorithm based on your recovery time objectives (RTO), storage capacity, and
-network throughput.
-:::
-
-## Compression Benchmark (on MinIO)
-
-| Compression | Backup Time (ms) | Restore Time (ms) | Uncompressed Size (MB) | Compressed Size (MB) | Ratio |
-| ----------- | ---------------- | ----------------- | ---------------------- | -------------------- | ----- |
-| None        | 10,927           | 7,553             | 395                    | 395                  | 1.0:1 |
-| bzip2       | 25,404           | 13,886            | 395                    | 67                   | 5.9:1 |
-| gzip        | 116,281          | 3,077             | 395                    | 91                   | 4.3:1 |
-| snappy      | 8,134            | 8,341             | 395                    | 166                  | 2.4:1 |

web/versioned_docs/version-0.4.1/concepts.md

@@ -1,177 +0,0 @@
----
-sidebar_position: 10
----
-
-# Main Concepts
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-:::important
-Before proceeding, make sure to review the following sections of the
-CloudNativePG documentation:
-
-- [**Backup**](https://cloudnative-pg.io/documentation/current/backup/)
-- [**WAL Archiving**](https://cloudnative-pg.io/documentation/current/wal_archiving/)
-- [**Recovery**](https://cloudnative-pg.io/documentation/current/recovery/)
-:::
-
-The **Barman Cloud Plugin** enables **hot (online) backups** of PostgreSQL
-clusters in CloudNativePG through [`barman-cloud`](https://pgbarman.org),
-supporting continuous physical backups and WAL archiving to an **object
-store**—without interrupting write operations.
-
-It also supports both **full recovery** and **Point-in-Time Recovery (PITR)**
-of a PostgreSQL cluster.
-
-## The Object Store
-
-At the core is the [`ObjectStore` custom resource (CRD)](plugin-barman-cloud.v1.md#objectstorespec),
-which acts as the interface between the PostgreSQL cluster and the target
-object storage system. It allows you to configure:
-
-- **Authentication and bucket location** via the `.spec.configuration` section
-- **WAL archiving** settings—such as compression type, parallelism, and
-  server-side encryption—under `.spec.configuration.wal`
-- **Base backup options**—with similar settings for compression, concurrency,
-  and encryption—under `.spec.configuration.data`
-- **Retention policies** to manage the life-cycle of archived WALs and backups
-  via `.spec.configuration.retentionPolicy`
-
-WAL files are archived in the `wals` directory, while base backups are stored
-as **tarballs** in the `base` directory, following the
-[Barman Cloud convention](https://docs.pgbarman.org/cloud/latest/usage/#object-store-layout).
-
-The plugin also offers advanced capabilities, including
-[backup tagging](misc.md#backup-object-tagging) and
-[extra options for backups and WAL archiving](misc.md#extra-options-for-backup-and-wal-archiving).
-
-:::tip
-For details, refer to the
-[API reference for the `ObjectStore` resource](plugin-barman-cloud.v1.md#objectstorespec).
-:::
-
-## Integration with a CloudNativePG Cluster
-
-CloudNativePG can delegate continuous backup and recovery responsibilities to
-the **Barman Cloud Plugin** by configuring the `.spec.plugins` section of a
-`Cluster` resource. This setup requires a corresponding `ObjectStore` resource
-to be defined.
-
-:::important
-While it is technically possible to reuse the same `ObjectStore` for multiple
-`Cluster` resources within the same namespace, it is strongly recommended to
-dedicate one object store per PostgreSQL cluster to ensure data isolation and
-operational clarity.
-:::
-
-The following example demonstrates how to configure a CloudNativePG cluster
-named `cluster-example` to use a previously defined `ObjectStore` (also named
-`cluster-example`) in the same namespace. Setting `isWALArchiver: true` enables
-WAL archiving through the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  # Other cluster settings...
-  plugins:
-    - name: barman-cloud.cloudnative-pg.io
-      isWALArchiver: true
-      parameters:
-        barmanObjectName: cluster-example
-```
-
-## Backup of a Postgres Cluster
-
-Once the object store is defined and the `Cluster` is configured to use the
-Barman Cloud Plugin, **WAL archiving is activated immediately** on the
-PostgreSQL primary.
-
-Physical base backups are seamlessly managed by CloudNativePG using the
-`Backup` and `ScheduledBackup` resources, respectively for
-[on-demand](https://cloudnative-pg.io/documentation/current/backup/#on-demand-backups)
-and
-[scheduled](https://cloudnative-pg.io/documentation/current/backup/#scheduled-backups)
-backups.
-
-To use the Barman Cloud Plugin, you must set the `method` to `plugin` and
-configure the `pluginConfiguration` section as shown:
-
-```yaml
-[...]
-spec:
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-  [...]
-```
-
-With this configuration, CloudNativePG supports:
-
-- Backups from both **primary** and **standby** instances
-- Backups from **designated primaries** in a distributed topology using
-  [replica clusters](https://cloudnative-pg.io/documentation/current/replica_cluster/)
-
-:::tip
-For details on how to back up from a standby, refer to the official documentation:
-[Backup from a standby](https://cloudnative-pg.io/documentation/current/backup/#backup-from-a-standby).
-:::
-
-:::important
-Both backup and WAL archiving operations are executed by sidecar containers
-running in the same pod as the PostgreSQL `Cluster` primary instance—except
-when backups are taken from a standby, in which case the sidecar runs alongside
-the standby pod.
-The sidecar containers use a [dedicated container image](images.md) that
-includes only the supported version of Barman Cloud.
-:::
-
-## Recovery of a Postgres Cluster
-
-In PostgreSQL, *recovery* refers to the process of starting a database instance
-from an existing backup.  The Barman Cloud Plugin integrates with CloudNativePG
-to support both **full recovery** and **Point-in-Time Recovery (PITR)** from an
-object store.
-
-Recovery in this context is *not in-place*: it bootstraps a brand-new
-PostgreSQL cluster from a backup and replays the necessary WAL files to reach
-the desired recovery target.
-
-To perform a recovery, define an *external cluster* that references the
-appropriate `ObjectStore`, and use it as the source in the `bootstrap` section
-of the target cluster:
-
-```yaml
-[...]
-spec:
-  [...]
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: cluster-example
-        serverName: cluster-example
-  [...]
-```
-
-The critical element here is the `externalClusters` section of the `Cluster`
-resource, where the `plugin` stanza instructs CloudNativePG to use the Barman
-Cloud Plugin to access the object store for recovery.
-
-This same mechanism can be used for a variety of scenarios enabled by the
-CloudNativePG API, including:
-
-* **Full cluster recovery** from the latest backup
-* **Point-in-Time Recovery (PITR)**
-* Bootstrapping **replica clusters** in a distributed topology
-
-:::tip
-For complete instructions and advanced use cases, refer to the official
-[Recovery documentation](https://cloudnative-pg.io/documentation/current/recovery/).
-:::

web/versioned_docs/version-0.4.1/images.md

@@ -1,37 +0,0 @@
----
-sidebar_position: 99
----
-
-# Container Images
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin is distributed using two container images:
-
-- One for deploying the plugin components
-- One for the sidecar that runs alongside each PostgreSQL instance in a
-  CloudNativePG `Cluster` using the plugin
-
-## Plugin Container Image
-
-The plugin image contains the logic required to operate the Barman Cloud Plugin
-within your Kubernetes environment with CloudNativePG. It is published on the
-GitHub Container Registry at `ghcr.io/cloudnative-pg/plugin-barman-cloud`.
-
-This image is built from the
-[`Dockerfile.plugin`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.plugin)
-in the plugin repository.
-
-## Sidecar Container Image
-
-The sidecar image is used within each PostgreSQL pod in the cluster. It
-includes the latest supported version of Barman Cloud and is responsible for
-performing WAL archiving and backups on behalf of CloudNativePG.
-
-It is available at `ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar` and is
-built from the
-[`Dockerfile.sidecar`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.sidecar).
-
-These sidecar images are designed to work seamlessly with the
-[`minimal` PostgreSQL container images](https://github.com/cloudnative-pg/postgres-containers?tab=readme-ov-file#minimal-images)
-maintained by the CloudNativePG Community.

web/versioned_docs/version-0.4.1/installation.mdx

@@ -1,109 +0,0 @@
----
-sidebar_position: 20
----
-
-# Installation
-
-:::important
-1. The plugin **must** be installed in the same namespace as the CloudNativePG
-   operator (typically `cnpg-system`).
-
-2. Keep in mind that the operator's **listening namespaces** may differ from its
-   installation namespace. Double-check this to avoid configuration issues.
-:::
-
-## Verifying the Requirements
-
-Before installing the plugin, make sure the [requirements](intro.md#requirements) are met.
-
-### CloudNativePG Version
-
-Ensure you're running a version of CloudNativePG that is compatible with the
-plugin. If installed in the default `cnpg-system` namespace, you can verify the
-version with:
-
-```sh
-kubectl get deployment -n cnpg-system cnpg-controller-manager -o yaml \
-  | grep ghcr.io/cloudnative-pg/cloudnative-pg
-```
-
-Example output:
-
-```output
-image: ghcr.io/cloudnative-pg/cloudnative-pg:1.26.0
-```
-
-The version **must be 1.26 or newer**.
-
-### cert-manager
-
-Use the [cmctl](https://cert-manager.io/docs/reference/cmctl/#installation)
-tool to confirm that `cert-manager` is installed and available:
-
-```sh
-cmctl check api
-```
-
-Example output:
-
-```output
-The cert-manager API is ready
-```
-
-Both checks are required before proceeding with the installation.
-
-## Installing the Barman Cloud Plugin
-
-import { InstallationSnippet } from '@site/src/components/Installation';
-
-Install the plugin using `kubectl` by applying the manifest for the latest
-release:
-
-<InstallationSnippet />
-
-Example output:
-
-```output
-customresourcedefinition.apiextensions.k8s.io/objectstores.barmancloud.cnpg.io created
-serviceaccount/plugin-barman-cloud created
-role.rbac.authorization.k8s.io/leader-election-role created
-clusterrole.rbac.authorization.k8s.io/metrics-auth-role created
-clusterrole.rbac.authorization.k8s.io/metrics-reader created
-clusterrole.rbac.authorization.k8s.io/objectstore-editor-role created
-clusterrole.rbac.authorization.k8s.io/objectstore-viewer-role created
-clusterrole.rbac.authorization.k8s.io/plugin-barman-cloud created
-rolebinding.rbac.authorization.k8s.io/leader-election-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/metrics-auth-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/plugin-barman-cloud-binding created
-secret/plugin-barman-cloud-8tfddg42gf created
-service/barman-cloud created
-deployment.apps/barman-cloud configured
-certificate.cert-manager.io/barman-cloud-client created
-certificate.cert-manager.io/barman-cloud-server created
-issuer.cert-manager.io/selfsigned-issuer created
-```
-
-Finally, check that the deployment is up and running:
-
-```sh
-kubectl rollout status deployment \
-  -n cnpg-system barman-cloud
-```
-
-Example output:
-
-```output
-deployment "barman-cloud" successfully rolled out
-```
-
-This confirms that the plugin is deployed and ready to use.
-
-## Testing the latest development snapshot
-
-You can also test the latest development snapshot of the plugin with the
-following command:
-
-```sh
-kubectl apply -f \
-  https://raw.githubusercontent.com/cloudnative-pg/plugin-barman-cloud/refs/heads/main/manifest.yaml
-```

web/versioned_docs/version-0.4.1/intro.md

@@ -1,67 +0,0 @@
----
-sidebar_position: 1
-sidebar_label: "Introduction"
----
-
-# Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The **Barman Cloud Plugin** for [CloudNativePG](https://cloudnative-pg.io/)
-enables online continuous physical backups of PostgreSQL clusters to object storage
-using the `barman-cloud` suite from the [Barman](https://docs.pgbarman.org/release/latest/)
-project.
-
-:::important
-If you plan to migrate your existing CloudNativePG cluster to the new
-plugin-based approach using the Barman Cloud Plugin, see
-["Migrating from Built-in CloudNativePG Backup"](migration.md)
-for detailed instructions.
-:::
-
-## Requirements
-
-To use the Barman Cloud Plugin, you need:
-
-- [CloudNativePG](https://cloudnative-pg.io) version **1.26** <!-- ADD WHEN 1.27 IS OUT "or later" -->
-- [cert-manager](https://cert-manager.io/) to enable TLS communication between
-  the plugin and the operator
-
-## Key Features
-
-This plugin provides the following capabilities:
-
-- Physical online backup of the data directory
-- Physical restore of the data directory
-- Write-Ahead Log (WAL) archiving
-- WAL restore
-- Full cluster recovery
-- Point-in-Time Recovery (PITR)
-- Seamless integration with replica clusters for bootstrap and WAL restore from archive
-
-:::important
-The Barman Cloud Plugin is designed to **replace the in-tree object storage support**
-previously provided via the `.spec.backup.barmanObjectStore` section in the
-`Cluster` resource.
-Backups created using the in-tree approach are fully supported and compatible
-with this plugin.
-:::
-
-## Supported Object Storage Providers
-
-The plugin works with all storage backends supported by `barman-cloud`, including:
-
-- **Amazon S3**
-- **Google Cloud Storage**
-- **Microsoft Azure Blob Storage**
-
-In addition, the following S3-compatible and simulator solutions have been
-tested and verified:
-
-- [MinIO](https://min.io/) – An S3-compatible storage solution
-- [Azurite](https://github.com/Azure/Azurite) – A simulator for Azure Blob Storage
-- [fake-gcs-server](https://github.com/fsouza/fake-gcs-server) – A simulator for Google Cloud Storage
-
-:::tip
-For more details, refer to [Object Store Providers](object_stores.md).
-:::

web/versioned_docs/version-0.4.1/migration.md

@@ -1,259 +0,0 @@
----
-sidebar_position: 40
----
-
-# Migrating from Built-in CloudNativePG Backup
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The in-tree support for Barman Cloud in CloudNativePG is **deprecated starting
-from version 1.26** and will be removed in a future release.
-
-If you're currently relying on the built-in Barman Cloud integration, you can
-migrate seamlessly to the new **plugin-based architecture** using the Barman
-Cloud Plugin, without data loss. Follow these steps:
-
-- [Install the Barman Cloud Plugin](installation.mdx)
-- Create an `ObjectStore` resource by translating the contents of the
-  `.spec.backup.barmanObjectStore` section from your existing `Cluster`
-  definition
-- Modify the `Cluster` resource in a single atomic change to switch from
-  in-tree backup to the plugin
-- Update any `ScheduledBackup` resources to use the plugin
-- Update the `externalClusters` configuration, where applicable
-
-:::tip
-For a working example, refer to [this commit](https://github.com/cloudnative-pg/cnpg-playground/commit/596f30e252896edf8f734991c3538df87630f6f7)
-from the [CloudNativePG Playground project](https://github.com/cloudnative-pg/cnpg-playground),
-which demonstrates a full migration.
-:::
-
----
-
-## Step 1: Define the `ObjectStore`
-
-Begin by creating an `ObjectStore` resource in the same namespace as your
-PostgreSQL `Cluster`.
-
-There is a **direct mapping** between the `.spec.backup.barmanObjectStore`
-section in CloudNativePG and the `.spec.configuration` field in the
-`ObjectStore` CR. The conversion is mostly mechanical, with one key difference:
-
-:::warning
-In the plugin architecture, retention policies are defined as part of the `ObjectStore`.
-In contrast, the in-tree implementation defined them at the `Cluster` level.
-:::
-
-If your `Cluster` used `.spec.backup.retentionPolicy`, move that configuration
-to `.spec.retentionPolicy` in the `ObjectStore`.
-
----
-
-### Example
-
-Here’s an excerpt from a traditional in-tree CloudNativePG backup configuration
-taken from the CloudNativePG Playground project:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-eu
-spec:
-  # [...]
-  backup:
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-This configuration translates to the following `ObjectStore` resource for the
-plugin:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-As you can see, the contents of `barmanObjectStore` have been copied directly
-under the `configuration` field of the `ObjectStore` resource, using the same
-secret references.
-
-## Step 2: Update the `Cluster` for plugin WAL archiving
-
-Once the `ObjectStore` resource is in place, update the `Cluster` resource as
-follows in a single atomic change:
-
-- Remove the `.spec.backup.barmanObjectStore` section
-- Remove `.spec.backup.retentionPolicy` if it was defined (as it is now in the
-  `ObjectStore`)
-- Remove the entire `spec.backup` section if it is now empty
-- Add `barman-cloud.cloudnative-pg.io` to the `plugins` list, as described in
-  [Configuring WAL archiving](usage.md#configuring-wal-archiving)
-
-This will trigger a rolling update of the `Cluster`, switching continuous
-backup from the in-tree implementation to the plugin-based approach.
-
-### Example
-
-The updated `pg-eu` cluster will have this configuration instead of the
-previous `backup` section:
-
-```yaml
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-eu
-```
-
----
-
-## Step 3: Update the `ScheduledBackup`
-
-After switching the `Cluster` to use the plugin, update your `ScheduledBackup`
-resources to match.
-
-Set the backup `method` to `plugin` and reference the plugin name via
-`pluginConfiguration`, as shown in ["Performing a base backup"](usage.md#performing-a-base-backup).
-
-### Example
-
-Original in-tree `ScheduledBackup`:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-```
-
-Updated version using the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
----
-
-## Step 4: Update the `externalClusters` configuration
-
-If your `Cluster` relies on one or more external clusters that use the in-tree
-Barman Cloud integration, you need to update those configurations to use the
-plugin-based architecture.
-
-When a replica cluster fetches WAL files or base backups from an external
-source that used the built-in backup method, follow these steps:
-
-1. Create a corresponding `ObjectStore` resource for the external cluster, as
-   shown in [Step 1](#step-1-define-the-objectstore)
-2. Update the `externalClusters` section of your replica cluster to use the
-   plugin instead of the in-tree `barmanObjectStore` field
-
-### Example
-
-Consider the original configuration using in-tree Barman Cloud:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      serverName: pg-eu
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-Create the `ObjectStore` resource for the external cluster:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-    accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-    secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-Update the external cluster configuration to use the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-eu
-        serverName: pg-eu
-```

web/versioned_docs/version-0.4.1/misc.md

@@ -1,76 +0,0 @@
----
-sidebar_position: 90
----
-
-# Miscellaneous
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-## Backup Object Tagging
-
-You can attach key-value metadata tags to backup artifacts—such as base
-backups, WAL files, and history files—via the `.spec.configuration` section of
-the `ObjectStore` resource.
-
-- `tags`: applied to base backups and WAL files
-- `historyTags`: applied to history files only
-
-### Example
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    [...]
-    tags:
-      backupRetentionPolicy: "expire"
-    historyTags:
-      backupRetentionPolicy: "keep"
-  [...]
-```
-
-## Extra Options for Backup and WAL Archiving
-
-You can pass additional command-line arguments to `barman-cloud-backup` and
-`barman-cloud-wal-archive` using the `additionalCommandArgs` field in the
-`ObjectStore` configuration.
-
-- `.spec.configuration.data.additionalCommandArgs`: for `barman-cloud-backup`
-- `.spec.configuration.wal.additionalCommandArgs`: for `barman-cloud-wal-archive`
-
-Each field accepts a list of string arguments. If an argument is already
-configured elsewhere in the plugin, the duplicate will be ignored.
-
-### Example: Extra Backup Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    data:
-      additionalCommandArgs:
-        - "--min-chunk-size=5MB"
-        - "--read-timeout=60"
-```
-
-### Example: Extra WAL Archive Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    wal:
-      additionalCommandArgs:
-        - "--max-concurrency=1"
-        - "--read-timeout=60"
-```
-
-For a complete list of supported options, refer to the
-[official Barman Cloud documentation](https://docs.pgbarman.org/release/latest/).

web/versioned_docs/version-0.4.1/object_stores.md

@@ -1,465 +0,0 @@
----
-sidebar_position: 50
----
-
-# Object Store Providers
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin enables the storage of PostgreSQL cluster backup files
-in any object storage service supported by the
-[Barman Cloud infrastructure](https://docs.pgbarman.org/release/latest/).
-
-Currently, Barman Cloud supports the following providers:
-
-- [Amazon S3](#aws-s3)
-- [Microsoft Azure Blob Storage](#azure-blob-storage)
-- [Google Cloud Storage](#google-cloud-storage)
-
-You may also use any S3- or Azure-compatible implementation of the above
-services.
-
-To configure object storage with Barman Cloud, you must define an
-[`ObjectStore` object](plugin-barman-cloud.v1.md#objectstore), which
-establishes the connection between your PostgreSQL cluster and the object
-storage backend.
-
-Configuration details — particularly around authentication — will vary depending on
-the specific object storage provider you are using.
-
-The following sections detail the setup for each.
-
----
-
-## AWS S3
-
-[AWS Simple Storage Service (S3)](https://aws.amazon.com/s3/) is one of the
-most widely adopted object storage solutions.
-
-The Barman Cloud plugin for CloudNativePG integrates with S3 through two
-primary authentication mechanisms:
-
-- [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) —
-  recommended for clusters running on EKS
-- Access keys — using `ACCESS_KEY_ID` and `ACCESS_SECRET_KEY` credentials
-
-### Access Keys
-
-To authenticate using access keys, you’ll need:
-
-- `ACCESS_KEY_ID`: the public key used to authenticate to S3
-- `ACCESS_SECRET_KEY`: the corresponding secret key
-- `ACCESS_SESSION_TOKEN`: (optional) a temporary session token, if required
-
-These credentials must be stored securely in a Kubernetes secret:
-
-```sh
-kubectl create secret generic aws-creds \
-  --from-literal=ACCESS_KEY_ID=<access key here> \
-  --from-literal=ACCESS_SECRET_KEY=<secret key here>
-# --from-literal=ACCESS_SESSION_TOKEN=<session token here> # if required
-```
-
-The credentials will be encrypted at rest if your Kubernetes environment
-supports it.
-
-You can then reference the secret in your `ObjectStore` definition:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: aws-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    s3Credentials:
-      accessKeyId:
-        name: aws-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: aws-creds
-        key: ACCESS_SECRET_KEY
-  [...]
-```
-
-### IAM Role for Service Account (IRSA)
-
-To use IRSA with EKS, configure the service account of the PostgreSQL cluster
-with the appropriate annotation:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  [...]
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        eks.amazonaws.com/role-arn: arn:[...]
-        [...]
-```
-
-### S3 Lifecycle Policy
-
-Barman Cloud uploads backup files to S3 but does not modify them afterward.
-To enhance data durability and protect against accidental or malicious loss,
-it's recommended to implement the following best practices:
-
-- Enable object versioning
-- Enable object locking to prevent objects from being deleted or overwritten
-  for a defined period or indefinitely (this provides an additional layer of
-  protection against accidental deletion and ransomware attacks)
-- Set lifecycle rules to expire current versions a few days after your Barman
-  retention window
-- Expire non-current versions after a longer period
-
-These strategies help you safeguard backups without requiring broad delete
-permissions, ensuring both security and compliance with minimal operational
-overhead.
-
-
-### S3-Compatible Storage Providers
-
-You can use S3-compatible services like **MinIO**, **Linode (Akamai) Object Storage**,
-or **DigitalOcean Spaces** by specifying a custom `endpointURL`.
-
-Example with Linode (Akamai) Object Storage (`us-east1`):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: linode-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/"
-    endpointURL: "https://us-east1.linodeobjects.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-Example with DigitalOcean Spaces (SFO3, path-style):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: digitalocean-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    endpointURL: "https://sfo3.digitaloceanspaces.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-### Using Object Storage with a Private CA
-
-For object storage services (e.g., MinIO) that use HTTPS with certificates
-signed by a private CA, set the `endpointCA` field in the `ObjectStore`
-definition. Unless you already have it, create a Kubernetes `Secret` with the
-CA bundle:
-
-```sh
-kubectl create secret generic my-ca-secret --from-file=ca.crt
-```
-
-Then reference it:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    endpointURL: <myEndpointURL>
-    endpointCA:
-      name: my-ca-secret
-      key: ca.crt
-  [...]
-```
-
-<!-- TODO: does this also apply to the plugin? -->
-:::note
-If you want `ConfigMaps` and `Secrets` to be **automatically** reloaded by
-instances, you can add a label with the key `cnpg.io/reload` to the
-`Secrets`/`ConfigMaps`. Otherwise, you will have to reload the instances using the
-`kubectl cnpg reload` subcommand.
-:::
-
----
-
-## Azure Blob Storage
-
-[Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/)
-is Microsoft’s cloud-based object storage solution.
-
-Barman Cloud supports the following authentication methods:
-
-- [Connection String](https://learn.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string)
-- Storage Account Name + [Access Key](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage)
-- Storage Account Name + [SAS Token](https://learn.microsoft.com/en-us/azure/storage/blobs/sas-service-create)
-- [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/introduction.html)
-
-### Azure AD Workload Identity
-
-This method avoids storing credentials in Kubernetes via the
-`.spec.configuration.inheritFromAzureAD` option:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      inheritFromAzureAD: true
-  [...]
-```
-
-### Access Key, SAS Token, or Connection String
-
-Store credentials in a Kubernetes secret:
-
-```sh
-kubectl create secret generic azure-creds \
-  --from-literal=AZURE_STORAGE_ACCOUNT=<storage account name> \
-  --from-literal=AZURE_STORAGE_KEY=<storage account key> \
-  --from-literal=AZURE_STORAGE_SAS_TOKEN=<SAS token> \
-  --from-literal=AZURE_STORAGE_CONNECTION_STRING=<connection string>
-```
-
-Then reference the required keys in your `ObjectStore`:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      connectionString:
-        name: azure-creds
-        key: AZURE_CONNECTION_STRING
-      storageAccount:
-        name: azure-creds
-        key: AZURE_STORAGE_ACCOUNT
-      storageKey:
-        name: azure-creds
-        key: AZURE_STORAGE_KEY
-      storageSasToken:
-        name: azure-creds
-        key: AZURE_STORAGE_SAS_TOKEN
-  [...]
-```
-
-For Azure Blob, the destination path format is:
-
-```
-<http|https>://<account-name>.<service-name>.core.windows.net/<container>/<blob>
-```
-
-### Azure-Compatible Providers
-
-If you're using a different implementation (e.g., Azurite or emulator):
-
-```
-<http|https>://<local-machine-address>:<port>/<account-name>/<container>/<blob>
-```
-
----
-
-## Google Cloud Storage
-
-[Google Cloud Storage](https://cloud.google.com/storage/) is supported with two
-authentication modes:
-
-- **GKE Workload Identity** (recommended inside Google Kubernetes Engine)
-- **Service Account JSON key** via the `GOOGLE_APPLICATION_CREDENTIALS` environment variable
-
-### GKE Workload Identity
-
-Use the [Workload Identity authentication](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
-when running in GKE:
-
-1. Set `googleCredentials.gkeEnvironment` to `true` in the `ObjectStore`
-   resource
-2. Annotate the `serviceAccountTemplate` in the `Cluster` resource with the GCP
-   service account
-
-For example, in the `ObjectStore` resource:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      gkeEnvironment: true
-```
-
-And in the `Cluster` resource:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        iam.gke.io/gcp-service-account: [...].iam.gserviceaccount.com
-```
-
-### Service Account JSON Key
-
-Follow Google’s [authentication setup](https://cloud.google.com/docs/authentication/getting-started),
-then:
-
-```sh
-kubectl create secret generic backup-creds --from-file=gcsCredentials=gcs_credentials_file.json
-```
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      applicationCredentials:
-        name: backup-creds
-        key: gcsCredentials
-  [...]
-```
-
-:::important
-This authentication method generates a JSON file within the container
-with all the credentials required to access your Google Cloud Storage
-bucket. As a result, if someone gains access to the `Pod`, they will also have
-write permissions to the bucket.
-:::
-
----
-
-
-## MinIO Gateway
-
-MinIO Gateway can proxy requests to cloud object storage providers like S3 or GCS.
-For more information, refer to [MinIO official documentation](https://docs.min.io/).
-
-### Setup
-
-Create MinIO access credentials:
-
-```sh
-kubectl create secret generic minio-creds \
-  --from-literal=MINIO_ACCESS_KEY=<minio access key> \
-  --from-literal=MINIO_SECRET_KEY=<minio secret key>
-```
-
-:::note
-Cloud Object Storage credentials will be used only by MinIO Gateway in this
-case.
-:::
-
-Expose MinIO Gateway via `ClusterIP`:
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: minio-gateway-service
-spec:
-  type: ClusterIP
-  ports:
-    - port: 9000
-      targetPort: 9000
-      protocol: TCP
-  selector:
-    app: minio
-```
-
-Here follows an excerpt of an example of deployment relaying to S3:
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-[...]
-spec:
-  containers:
-  - name: minio
-    image: minio/minio:RELEASE.2020-06-03T22-13-49Z
-    args: ["gateway", "s3"]
-    ports:
-    - containerPort: 9000
-    env:
-    - 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
-    - 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
-```
-
-Proceed by configuring MinIO Gateway service as the `endpointURL` in the
-`ObjectStore` definition, then choose a bucket name to replace `BUCKET_NAME`:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    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
-  [...]
-```
-
-:::important
-Verify on `s3://BUCKET_NAME/` the presence of archived WAL files before
-proceeding with a backup.
-:::
-
----

web/versioned_docs/version-0.4.1/parameters.md

@@ -1,19 +0,0 @@
----
-sidebar_position: 100
----
-
-# Parameters
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The following parameters are available for the Barman Cloud Plugin:
-
-- `barmanObjectName`: references the `ObjectStore` resource to be used by the
-  plugin.
-- `serverName`: Specifies the server name in the object store.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::

web/versioned_docs/version-0.4.1/plugin-barman-cloud.v1.md

@@ -1,105 +0,0 @@
-# API Reference
-
-## Packages
-- [barmancloud.cnpg.io/v1](#barmancloudcnpgiov1)
-
-
-## barmancloud.cnpg.io/v1
-
-Package v1 contains API Schema definitions for the barmancloud v1 API group
-
-### Resource Types
-- [ObjectStore](#objectstore)
-
-
-
-#### InstanceSidecarConfiguration
-
-
-
-InstanceSidecarConfiguration defines the configuration for the sidecar that runs in the instance pods.
-
-
-
-_Appears in:_
-- [ObjectStoreSpec](#objectstorespec)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `env` _[EnvVar](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#envvar-v1-core) array_ | The environment to be explicitly passed to the sidecar |  |  |  |
-| `retentionPolicyIntervalSeconds` _integer_ | The retentionCheckInterval defines the frequency at which the<br />system checks and enforces retention policies. |  | 1800 |  |
-| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | Resources define cpu/memory requests and limits for the sidecar that runs in the instance pods. |  |  |  |
-
-
-#### ObjectStore
-
-
-
-ObjectStore is the Schema for the objectstores API.
-
-
-
-
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `apiVersion` _string_ | `barmancloud.cnpg.io/v1` | True | | |
-| `kind` _string_ | `ObjectStore` | True | | |
-| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | True |  |  |
-| `spec` _[ObjectStoreSpec](#objectstorespec)_ | Specification of the desired behavior of the ObjectStore.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status | True |  |  |
-| `status` _[ObjectStoreStatus](#objectstorestatus)_ | Most recently observed status of the ObjectStore. This data may not be up to<br />date. Populated by the system. Read-only.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status |  |  |  |
-
-
-#### ObjectStoreSpec
-
-
-
-ObjectStoreSpec defines the desired state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `configuration` _[BarmanObjectStoreConfiguration](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration)_ | The configuration for the barman-cloud tool suite | True |  |  |
-| `retentionPolicy` _string_ | RetentionPolicy is the retention policy to be used for backups<br />and WALs (i.e. '60d'). The retention policy is expressed in the form<br />of `XXu` where `XX` is a positive integer and `u` is in `[dwm]` -<br />days, weeks, months. |  |  | Pattern: `^[1-9][0-9]*[dwm]$` <br /> |
-| `instanceSidecarConfiguration` _[InstanceSidecarConfiguration](#instancesidecarconfiguration)_ | The configuration for the sidecar that runs in the instance pods |  |  |  |
-
-
-#### ObjectStoreStatus
-
-
-
-ObjectStoreStatus defines the observed state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `serverRecoveryWindow` _object (keys:string, values:[RecoveryWindow](#recoverywindow))_ | ServerRecoveryWindow maps each server to its recovery window | True |  |  |
-
-
-#### RecoveryWindow
-
-
-
-RecoveryWindow represents the time span between the first
-recoverability point and the last successful backup of a PostgreSQL
-server, defining the period during which data can be restored.
-
-
-
-_Appears in:_
-- [ObjectStoreStatus](#objectstorestatus)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `firstRecoverabilityPoint` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The first recoverability point in a PostgreSQL server refers to<br />the earliest point in time to which the database can be<br />restored. | True |  |  |
-| `lastSuccussfulBackupTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The last successful backup time | True |  |  |
-
-

web/versioned_docs/version-0.4.1/retention.md

@@ -1,38 +0,0 @@
----
-sidebar_position: 60
----
-
-# Retention Policies
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin supports **automated cleanup of obsolete backups** via
-retention policies, configured in the `.spec.retentionPolicy` field of the
-`ObjectStore` resource.
-
-:::note
-This feature uses the `barman-cloud-backup-delete` command with the
-`--retention-policy "RECOVERY WINDOW OF {{ value }} {{ unit }}"` syntax.
-:::
-
-#### Example: 30-Day Retention Policy
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  [...]
-  retentionPolicy: "30d"
-````
-
-:::note
-A **recovery window retention policy** ensures the cluster can be restored to
-any point in time between the calculated *Point of Recoverability* (PoR) and
-the latest WAL archive. The PoR is defined as `current time - recovery window`.
-The **first valid backup** is the most recent backup completed before the PoR.
-Backups older than that are marked as *obsolete* and deleted after the next
-backup completes.
-:::
-

web/versioned_docs/version-0.4.1/usage.md

@@ -1,258 +0,0 @@
----
-sidebar_position: 30
----
-
-# Using the Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-After [installing the plugin](installation.mdx) in the same namespace as the
-CloudNativePG operator, enabling your PostgreSQL cluster to use the Barman
-Cloud Plugin involves just a few steps:
-
-- Defining the object store containing your WAL archive and base backups, using
-  your preferred [provider](object_stores.md)
-- Instructing the Postgres cluster to use the Barman Cloud Plugin
-
-From that moment, you’ll be able to issue on-demand backups or define a backup
-schedule, as well as rely on the object store for recovery operations.
-
-The rest of this page details each step, using MinIO as object store provider.
-
-## Defining the `ObjectStore`
-
-An `ObjectStore` resource must be created for each object store used in your
-PostgreSQL architecture. Here's an example configuration using MinIO:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-The `.spec.configuration` schema follows the same format as the
-[in-tree barman-cloud support](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration).
-Refer to [the CloudNativePG documentation](https://cloudnative-pg.io/documentation/current/appendixes/backup_barmanobjectstore/)
-for additional details.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::
-
-## Configuring WAL Archiving
-
-Once the `ObjectStore` is defined, you can configure your PostgreSQL cluster
-to archive WALs by referencing the store in the `.spec.plugins` section:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  instances: 3
-  imagePullPolicy: Always
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store
-  storage:
-    size: 1Gi
-```
-
-This configuration enables both WAL archiving and data directory backups.
-
-## Performing a Base Backup
-
-Once WAL archiving is enabled, the cluster is ready for backups. To issue an
-on-demand backup, use the following configuration with the plugin method:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Backup
-metadata:
-  name: backup-example
-spec:
-  cluster:
-    name: cluster-example
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
-:::note
-You can apply the same concept to the `ScheduledBackup` resource.
-:::
-
-## Restoring a Cluster
-
-To restore a cluster from an object store, create a new `Cluster` resource that
-references the store containing the backup. Below is an example configuration:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-:::important
-The above configuration does **not** enable WAL archiving for the restored cluster.
-:::
-
-To enable WAL archiving for the restored cluster, include the `.spec.plugins`
-section alongside the `externalClusters.plugin` section, as shown below:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      # Backup Object Store (push, read-write)
-      barmanObjectName: minio-store-bis
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        # Recovery Object Store (pull, read-only)
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-The same object store may be used for both transaction log archiving and
-restoring a cluster, or you can configure separate stores for these purposes.
-
-## Configuring Replica Clusters
-
-You can set up a distributed topology by combining the previously defined
-configurations with the `.spec.replica` section. Below is an example of how to
-define a replica cluster:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-dc-a
-spec:
-  instances: 3
-  primaryUpdateStrategy: unsupervised
-
-  storage:
-    storageClass: csi-hostpath-sc
-    size: 1Gi
-
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store-a
-
-  replica:
-    self: cluster-dc-a
-    primary: cluster-dc-a
-    source: cluster-dc-b
-
-  externalClusters:
-  - name: cluster-dc-a
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-a
-
-  - name: cluster-dc-b
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-b
-```
-
-## Configuring the plugin instance sidecar
-
-The Barman Cloud Plugin runs as a sidecar container next to each PostgreSQL
-instance pod. It manages backup, WAL archiving, and restore processes.
-
-Configuration comes from multiple `ObjectStore` resources:
-
-1. The one referenced in the
-   `.spec.plugins` section of the `Cluster`. This is the
-   object store used for WAL archiving and base backups.
-2. The one referenced in the external cluster
-   used in the `.spec.replica.source` section of the `Cluster`. This is
-   used by the log-shipping designated primary to get the WAL files.
-3. The one referenced in the
-   `.spec.bootstrap.recovery.source` section of the `Cluster`. Used by
-   the initial recovery job to create the cluster from an existing backup.
-
-You can fine-tune sidecar behavior in the `.spec.instanceSidecarConfiguration`
-of your ObjectStore. These settings apply to all PostgreSQL instances that use
-this object store. Any updates take effect at the next `Cluster` reconciliation,
-and could generate a rollout of the `Cluster`.
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-  # [...]
-  instanceSidecarConfiguration:
-    retentionPolicyIntervalSeconds: 1800
-    resources:
-      requests:
-        memory: "XXX"
-        cpu: "YYY"
-      limits:
-        memory: "XXX"
-        cpu: "YYY"
-```
-
-:::note
-If more than one `ObjectStore` applies, the `instanceSidecarConfiguration` of
-the one set in `.spec.plugins` has priority.
-:::

web/versioned_docs/version-0.5.0/compression.md

@@ -1,43 +0,0 @@
----
-sidebar_position: 80
----
-
-# Compression
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-By default, backups and WAL files are archived **uncompressed**. However, the
-Barman Cloud Plugin supports multiple compression algorithms via
-`barman-cloud-backup` and `barman-cloud-wal-archive`, allowing you to optimize
-for space, speed, or a balance of both.
-
-### Supported Compression Algorithms
-
-- `bzip2`
-- `gzip`
-- `lz4` (WAL only)
-- `snappy`
-- `xz` (WAL only)
-- `zstd` (WAL only)
-
-Compression settings for base backups and WAL archives are configured
-independently. For implementation details, refer to the corresponding API
-definitions:
-
-- [`DataBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#DataBackupConfiguration)
-- [`WALBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#WalBackupConfiguration)
-
-:::important
-Compression impacts both performance and storage efficiency. Choose the right
-algorithm based on your recovery time objectives (RTO), storage capacity, and
-network throughput.
-:::
-
-## Compression Benchmark (on MinIO)
-
-| Compression | Backup Time (ms) | Restore Time (ms) | Uncompressed Size (MB) | Compressed Size (MB) | Ratio |
-| ----------- | ---------------- | ----------------- | ---------------------- | -------------------- | ----- |
-| None        | 10,927           | 7,553             | 395                    | 395                  | 1.0:1 |
-| bzip2       | 25,404           | 13,886            | 395                    | 67                   | 5.9:1 |
-| gzip        | 116,281          | 3,077             | 395                    | 91                   | 4.3:1 |
-| snappy      | 8,134            | 8,341             | 395                    | 166                  | 2.4:1 |

web/versioned_docs/version-0.5.0/concepts.md

@@ -1,177 +0,0 @@
----
-sidebar_position: 10
----
-
-# Main Concepts
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-:::important
-Before proceeding, make sure to review the following sections of the
-CloudNativePG documentation:
-
-- [**Backup**](https://cloudnative-pg.io/documentation/current/backup/)
-- [**WAL Archiving**](https://cloudnative-pg.io/documentation/current/wal_archiving/)
-- [**Recovery**](https://cloudnative-pg.io/documentation/current/recovery/)
-:::
-
-The **Barman Cloud Plugin** enables **hot (online) backups** of PostgreSQL
-clusters in CloudNativePG through [`barman-cloud`](https://pgbarman.org),
-supporting continuous physical backups and WAL archiving to an **object
-store**—without interrupting write operations.
-
-It also supports both **full recovery** and **Point-in-Time Recovery (PITR)**
-of a PostgreSQL cluster.
-
-## The Object Store
-
-At the core is the [`ObjectStore` custom resource (CRD)](plugin-barman-cloud.v1.md#objectstorespec),
-which acts as the interface between the PostgreSQL cluster and the target
-object storage system. It allows you to configure:
-
-- **Authentication and bucket location** via the `.spec.configuration` section
-- **WAL archiving** settings—such as compression type, parallelism, and
-  server-side encryption—under `.spec.configuration.wal`
-- **Base backup options**—with similar settings for compression, concurrency,
-  and encryption—under `.spec.configuration.data`
-- **Retention policies** to manage the life-cycle of archived WALs and backups
-  via `.spec.configuration.retentionPolicy`
-
-WAL files are archived in the `wals` directory, while base backups are stored
-as **tarballs** in the `base` directory, following the
-[Barman Cloud convention](https://docs.pgbarman.org/cloud/latest/usage/#object-store-layout).
-
-The plugin also offers advanced capabilities, including
-[backup tagging](misc.md#backup-object-tagging) and
-[extra options for backups and WAL archiving](misc.md#extra-options-for-backup-and-wal-archiving).
-
-:::tip
-For details, refer to the
-[API reference for the `ObjectStore` resource](plugin-barman-cloud.v1.md#objectstorespec).
-:::
-
-## Integration with a CloudNativePG Cluster
-
-CloudNativePG can delegate continuous backup and recovery responsibilities to
-the **Barman Cloud Plugin** by configuring the `.spec.plugins` section of a
-`Cluster` resource. This setup requires a corresponding `ObjectStore` resource
-to be defined.
-
-:::important
-While it is technically possible to reuse the same `ObjectStore` for multiple
-`Cluster` resources within the same namespace, it is strongly recommended to
-dedicate one object store per PostgreSQL cluster to ensure data isolation and
-operational clarity.
-:::
-
-The following example demonstrates how to configure a CloudNativePG cluster
-named `cluster-example` to use a previously defined `ObjectStore` (also named
-`cluster-example`) in the same namespace. Setting `isWALArchiver: true` enables
-WAL archiving through the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  # Other cluster settings...
-  plugins:
-    - name: barman-cloud.cloudnative-pg.io
-      isWALArchiver: true
-      parameters:
-        barmanObjectName: cluster-example
-```
-
-## Backup of a Postgres Cluster
-
-Once the object store is defined and the `Cluster` is configured to use the
-Barman Cloud Plugin, **WAL archiving is activated immediately** on the
-PostgreSQL primary.
-
-Physical base backups are seamlessly managed by CloudNativePG using the
-`Backup` and `ScheduledBackup` resources, respectively for
-[on-demand](https://cloudnative-pg.io/documentation/current/backup/#on-demand-backups)
-and
-[scheduled](https://cloudnative-pg.io/documentation/current/backup/#scheduled-backups)
-backups.
-
-To use the Barman Cloud Plugin, you must set the `method` to `plugin` and
-configure the `pluginConfiguration` section as shown:
-
-```yaml
-[...]
-spec:
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-  [...]
-```
-
-With this configuration, CloudNativePG supports:
-
-- Backups from both **primary** and **standby** instances
-- Backups from **designated primaries** in a distributed topology using
-  [replica clusters](https://cloudnative-pg.io/documentation/current/replica_cluster/)
-
-:::tip
-For details on how to back up from a standby, refer to the official documentation:
-[Backup from a standby](https://cloudnative-pg.io/documentation/current/backup/#backup-from-a-standby).
-:::
-
-:::important
-Both backup and WAL archiving operations are executed by sidecar containers
-running in the same pod as the PostgreSQL `Cluster` primary instance—except
-when backups are taken from a standby, in which case the sidecar runs alongside
-the standby pod.
-The sidecar containers use a [dedicated container image](images.md) that
-includes only the supported version of Barman Cloud.
-:::
-
-## Recovery of a Postgres Cluster
-
-In PostgreSQL, *recovery* refers to the process of starting a database instance
-from an existing backup.  The Barman Cloud Plugin integrates with CloudNativePG
-to support both **full recovery** and **Point-in-Time Recovery (PITR)** from an
-object store.
-
-Recovery in this context is *not in-place*: it bootstraps a brand-new
-PostgreSQL cluster from a backup and replays the necessary WAL files to reach
-the desired recovery target.
-
-To perform a recovery, define an *external cluster* that references the
-appropriate `ObjectStore`, and use it as the source in the `bootstrap` section
-of the target cluster:
-
-```yaml
-[...]
-spec:
-  [...]
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: cluster-example
-        serverName: cluster-example
-  [...]
-```
-
-The critical element here is the `externalClusters` section of the `Cluster`
-resource, where the `plugin` stanza instructs CloudNativePG to use the Barman
-Cloud Plugin to access the object store for recovery.
-
-This same mechanism can be used for a variety of scenarios enabled by the
-CloudNativePG API, including:
-
-* **Full cluster recovery** from the latest backup
-* **Point-in-Time Recovery (PITR)**
-* Bootstrapping **replica clusters** in a distributed topology
-
-:::tip
-For complete instructions and advanced use cases, refer to the official
-[Recovery documentation](https://cloudnative-pg.io/documentation/current/recovery/).
-:::

web/versioned_docs/version-0.5.0/images.md

@@ -1,37 +0,0 @@
----
-sidebar_position: 99
----
-
-# Container Images
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin is distributed using two container images:
-
-- One for deploying the plugin components
-- One for the sidecar that runs alongside each PostgreSQL instance in a
-  CloudNativePG `Cluster` using the plugin
-
-## Plugin Container Image
-
-The plugin image contains the logic required to operate the Barman Cloud Plugin
-within your Kubernetes environment with CloudNativePG. It is published on the
-GitHub Container Registry at `ghcr.io/cloudnative-pg/plugin-barman-cloud`.
-
-This image is built from the
-[`Dockerfile.plugin`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.plugin)
-in the plugin repository.
-
-## Sidecar Container Image
-
-The sidecar image is used within each PostgreSQL pod in the cluster. It
-includes the latest supported version of Barman Cloud and is responsible for
-performing WAL archiving and backups on behalf of CloudNativePG.
-
-It is available at `ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar` and is
-built from the
-[`Dockerfile.sidecar`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.sidecar).
-
-These sidecar images are designed to work seamlessly with the
-[`minimal` PostgreSQL container images](https://github.com/cloudnative-pg/postgres-containers?tab=readme-ov-file#minimal-images)
-maintained by the CloudNativePG Community.

web/versioned_docs/version-0.5.0/installation.mdx

@@ -1,109 +0,0 @@
----
-sidebar_position: 20
----
-
-# Installation
-
-:::important
-1. The plugin **must** be installed in the same namespace as the CloudNativePG
-   operator (typically `cnpg-system`).
-
-2. Keep in mind that the operator's **listening namespaces** may differ from its
-   installation namespace. Double-check this to avoid configuration issues.
-:::
-
-## Verifying the Requirements
-
-Before installing the plugin, make sure the [requirements](intro.md#requirements) are met.
-
-### CloudNativePG Version
-
-Ensure you're running a version of CloudNativePG that is compatible with the
-plugin. If installed in the default `cnpg-system` namespace, you can verify the
-version with:
-
-```sh
-kubectl get deployment -n cnpg-system cnpg-controller-manager -o yaml \
-  | grep ghcr.io/cloudnative-pg/cloudnative-pg
-```
-
-Example output:
-
-```output
-image: ghcr.io/cloudnative-pg/cloudnative-pg:1.26.0
-```
-
-The version **must be 1.26 or newer**.
-
-### cert-manager
-
-Use the [cmctl](https://cert-manager.io/docs/reference/cmctl/#installation)
-tool to confirm that `cert-manager` is installed and available:
-
-```sh
-cmctl check api
-```
-
-Example output:
-
-```output
-The cert-manager API is ready
-```
-
-Both checks are required before proceeding with the installation.
-
-## Installing the Barman Cloud Plugin
-
-import { InstallationSnippet } from '@site/src/components/Installation';
-
-Install the plugin using `kubectl` by applying the manifest for the latest
-release:
-
-<InstallationSnippet />
-
-Example output:
-
-```output
-customresourcedefinition.apiextensions.k8s.io/objectstores.barmancloud.cnpg.io created
-serviceaccount/plugin-barman-cloud created
-role.rbac.authorization.k8s.io/leader-election-role created
-clusterrole.rbac.authorization.k8s.io/metrics-auth-role created
-clusterrole.rbac.authorization.k8s.io/metrics-reader created
-clusterrole.rbac.authorization.k8s.io/objectstore-editor-role created
-clusterrole.rbac.authorization.k8s.io/objectstore-viewer-role created
-clusterrole.rbac.authorization.k8s.io/plugin-barman-cloud created
-rolebinding.rbac.authorization.k8s.io/leader-election-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/metrics-auth-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/plugin-barman-cloud-binding created
-secret/plugin-barman-cloud-8tfddg42gf created
-service/barman-cloud created
-deployment.apps/barman-cloud configured
-certificate.cert-manager.io/barman-cloud-client created
-certificate.cert-manager.io/barman-cloud-server created
-issuer.cert-manager.io/selfsigned-issuer created
-```
-
-Finally, check that the deployment is up and running:
-
-```sh
-kubectl rollout status deployment \
-  -n cnpg-system barman-cloud
-```
-
-Example output:
-
-```output
-deployment "barman-cloud" successfully rolled out
-```
-
-This confirms that the plugin is deployed and ready to use.
-
-## Testing the latest development snapshot
-
-You can also test the latest development snapshot of the plugin with the
-following command:
-
-```sh
-kubectl apply -f \
-  https://raw.githubusercontent.com/cloudnative-pg/plugin-barman-cloud/refs/heads/main/manifest.yaml
-```

web/versioned_docs/version-0.5.0/intro.md

@@ -1,67 +0,0 @@
----
-sidebar_position: 1
-sidebar_label: "Introduction"
----
-
-# Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The **Barman Cloud Plugin** for [CloudNativePG](https://cloudnative-pg.io/)
-enables online continuous physical backups of PostgreSQL clusters to object storage
-using the `barman-cloud` suite from the [Barman](https://docs.pgbarman.org/release/latest/)
-project.
-
-:::important
-If you plan to migrate your existing CloudNativePG cluster to the new
-plugin-based approach using the Barman Cloud Plugin, see
-["Migrating from Built-in CloudNativePG Backup"](migration.md)
-for detailed instructions.
-:::
-
-## Requirements
-
-To use the Barman Cloud Plugin, you need:
-
-- [CloudNativePG](https://cloudnative-pg.io) version **1.26** <!-- ADD WHEN 1.27 IS OUT "or later" -->
-- [cert-manager](https://cert-manager.io/) to enable TLS communication between
-  the plugin and the operator
-
-## Key Features
-
-This plugin provides the following capabilities:
-
-- Physical online backup of the data directory
-- Physical restore of the data directory
-- Write-Ahead Log (WAL) archiving
-- WAL restore
-- Full cluster recovery
-- Point-in-Time Recovery (PITR)
-- Seamless integration with replica clusters for bootstrap and WAL restore from archive
-
-:::important
-The Barman Cloud Plugin is designed to **replace the in-tree object storage support**
-previously provided via the `.spec.backup.barmanObjectStore` section in the
-`Cluster` resource.
-Backups created using the in-tree approach are fully supported and compatible
-with this plugin.
-:::
-
-## Supported Object Storage Providers
-
-The plugin works with all storage backends supported by `barman-cloud`, including:
-
-- **Amazon S3**
-- **Google Cloud Storage**
-- **Microsoft Azure Blob Storage**
-
-In addition, the following S3-compatible and simulator solutions have been
-tested and verified:
-
-- [MinIO](https://min.io/) – An S3-compatible storage solution
-- [Azurite](https://github.com/Azure/Azurite) – A simulator for Azure Blob Storage
-- [fake-gcs-server](https://github.com/fsouza/fake-gcs-server) – A simulator for Google Cloud Storage
-
-:::tip
-For more details, refer to [Object Store Providers](object_stores.md).
-:::

web/versioned_docs/version-0.5.0/migration.md

@@ -1,259 +0,0 @@
----
-sidebar_position: 40
----
-
-# Migrating from Built-in CloudNativePG Backup
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The in-tree support for Barman Cloud in CloudNativePG is **deprecated starting
-from version 1.26** and will be removed in a future release.
-
-If you're currently relying on the built-in Barman Cloud integration, you can
-migrate seamlessly to the new **plugin-based architecture** using the Barman
-Cloud Plugin, without data loss. Follow these steps:
-
-- [Install the Barman Cloud Plugin](installation.mdx)
-- Create an `ObjectStore` resource by translating the contents of the
-  `.spec.backup.barmanObjectStore` section from your existing `Cluster`
-  definition
-- Modify the `Cluster` resource in a single atomic change to switch from
-  in-tree backup to the plugin
-- Update any `ScheduledBackup` resources to use the plugin
-- Update the `externalClusters` configuration, where applicable
-
-:::tip
-For a working example, refer to [this commit](https://github.com/cloudnative-pg/cnpg-playground/commit/596f30e252896edf8f734991c3538df87630f6f7)
-from the [CloudNativePG Playground project](https://github.com/cloudnative-pg/cnpg-playground),
-which demonstrates a full migration.
-:::
-
----
-
-## Step 1: Define the `ObjectStore`
-
-Begin by creating an `ObjectStore` resource in the same namespace as your
-PostgreSQL `Cluster`.
-
-There is a **direct mapping** between the `.spec.backup.barmanObjectStore`
-section in CloudNativePG and the `.spec.configuration` field in the
-`ObjectStore` CR. The conversion is mostly mechanical, with one key difference:
-
-:::warning
-In the plugin architecture, retention policies are defined as part of the `ObjectStore`.
-In contrast, the in-tree implementation defined them at the `Cluster` level.
-:::
-
-If your `Cluster` used `.spec.backup.retentionPolicy`, move that configuration
-to `.spec.retentionPolicy` in the `ObjectStore`.
-
----
-
-### Example
-
-Here’s an excerpt from a traditional in-tree CloudNativePG backup configuration
-taken from the CloudNativePG Playground project:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-eu
-spec:
-  # [...]
-  backup:
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-This configuration translates to the following `ObjectStore` resource for the
-plugin:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-As you can see, the contents of `barmanObjectStore` have been copied directly
-under the `configuration` field of the `ObjectStore` resource, using the same
-secret references.
-
-## Step 2: Update the `Cluster` for plugin WAL archiving
-
-Once the `ObjectStore` resource is in place, update the `Cluster` resource as
-follows in a single atomic change:
-
-- Remove the `.spec.backup.barmanObjectStore` section
-- Remove `.spec.backup.retentionPolicy` if it was defined (as it is now in the
-  `ObjectStore`)
-- Remove the entire `spec.backup` section if it is now empty
-- Add `barman-cloud.cloudnative-pg.io` to the `plugins` list, as described in
-  [Configuring WAL archiving](usage.md#configuring-wal-archiving)
-
-This will trigger a rolling update of the `Cluster`, switching continuous
-backup from the in-tree implementation to the plugin-based approach.
-
-### Example
-
-The updated `pg-eu` cluster will have this configuration instead of the
-previous `backup` section:
-
-```yaml
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-eu
-```
-
----
-
-## Step 3: Update the `ScheduledBackup`
-
-After switching the `Cluster` to use the plugin, update your `ScheduledBackup`
-resources to match.
-
-Set the backup `method` to `plugin` and reference the plugin name via
-`pluginConfiguration`, as shown in ["Performing a base backup"](usage.md#performing-a-base-backup).
-
-### Example
-
-Original in-tree `ScheduledBackup`:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-```
-
-Updated version using the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: ScheduledBackup
-metadata:
-  name: pg-eu-backup
-spec:
-  cluster:
-    name: pg-eu
-  schedule: '0 0 0 * * *'
-  backupOwnerReference: self
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
----
-
-## Step 4: Update the `externalClusters` configuration
-
-If your `Cluster` relies on one or more external clusters that use the in-tree
-Barman Cloud integration, you need to update those configurations to use the
-plugin-based architecture.
-
-When a replica cluster fetches WAL files or base backups from an external
-source that used the built-in backup method, follow these steps:
-
-1. Create a corresponding `ObjectStore` resource for the external cluster, as
-   shown in [Step 1](#step-1-define-the-objectstore)
-2. Update the `externalClusters` section of your replica cluster to use the
-   plugin instead of the in-tree `barmanObjectStore` field
-
-### Example
-
-Consider the original configuration using in-tree Barman Cloud:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    barmanObjectStore:
-      destinationPath: s3://backups/
-      endpointURL: http://minio-eu:9000
-      serverName: pg-eu
-      s3Credentials:
-        accessKeyId:
-          name: minio-eu
-          key: ACCESS_KEY_ID
-        secretAccessKey:
-          name: minio-eu
-          key: ACCESS_SECRET_KEY
-      wal:
-        compression: gzip
-```
-
-Create the `ObjectStore` resource for the external cluster:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-eu
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio-eu:9000
-    s3Credentials:
-    accessKeyId:
-        name: minio-eu
-        key: ACCESS_KEY_ID
-    secretAccessKey:
-        name: minio-eu
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-Update the external cluster configuration to use the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: pg-us
-spec:
-  # [...]
-  externalClusters:
-  - name: pg-eu
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-eu
-        serverName: pg-eu
-```

web/versioned_docs/version-0.5.0/misc.md

@@ -1,76 +0,0 @@
----
-sidebar_position: 90
----
-
-# Miscellaneous
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-## Backup Object Tagging
-
-You can attach key-value metadata tags to backup artifacts—such as base
-backups, WAL files, and history files—via the `.spec.configuration` section of
-the `ObjectStore` resource.
-
-- `tags`: applied to base backups and WAL files
-- `historyTags`: applied to history files only
-
-### Example
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    [...]
-    tags:
-      backupRetentionPolicy: "expire"
-    historyTags:
-      backupRetentionPolicy: "keep"
-  [...]
-```
-
-## Extra Options for Backup and WAL Archiving
-
-You can pass additional command-line arguments to `barman-cloud-backup` and
-`barman-cloud-wal-archive` using the `additionalCommandArgs` field in the
-`ObjectStore` configuration.
-
-- `.spec.configuration.data.additionalCommandArgs`: for `barman-cloud-backup`
-- `.spec.configuration.wal.additionalCommandArgs`: for `barman-cloud-wal-archive`
-
-Each field accepts a list of string arguments. If an argument is already
-configured elsewhere in the plugin, the duplicate will be ignored.
-
-### Example: Extra Backup Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    data:
-      additionalCommandArgs:
-        - "--min-chunk-size=5MB"
-        - "--read-timeout=60"
-```
-
-### Example: Extra WAL Archive Options
-
-```yaml
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  configuration:
-    wal:
-      additionalCommandArgs:
-        - "--max-concurrency=1"
-        - "--read-timeout=60"
-```
-
-For a complete list of supported options, refer to the
-[official Barman Cloud documentation](https://docs.pgbarman.org/release/latest/).

web/versioned_docs/version-0.5.0/object_stores.md

@@ -1,465 +0,0 @@
----
-sidebar_position: 50
----
-
-# Object Store Providers
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin enables the storage of PostgreSQL cluster backup files
-in any object storage service supported by the
-[Barman Cloud infrastructure](https://docs.pgbarman.org/release/latest/).
-
-Currently, Barman Cloud supports the following providers:
-
-- [Amazon S3](#aws-s3)
-- [Microsoft Azure Blob Storage](#azure-blob-storage)
-- [Google Cloud Storage](#google-cloud-storage)
-
-You may also use any S3- or Azure-compatible implementation of the above
-services.
-
-To configure object storage with Barman Cloud, you must define an
-[`ObjectStore` object](plugin-barman-cloud.v1.md#objectstore), which
-establishes the connection between your PostgreSQL cluster and the object
-storage backend.
-
-Configuration details — particularly around authentication — will vary depending on
-the specific object storage provider you are using.
-
-The following sections detail the setup for each.
-
----
-
-## AWS S3
-
-[AWS Simple Storage Service (S3)](https://aws.amazon.com/s3/) is one of the
-most widely adopted object storage solutions.
-
-The Barman Cloud plugin for CloudNativePG integrates with S3 through two
-primary authentication mechanisms:
-
-- [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) —
-  recommended for clusters running on EKS
-- Access keys — using `ACCESS_KEY_ID` and `ACCESS_SECRET_KEY` credentials
-
-### Access Keys
-
-To authenticate using access keys, you’ll need:
-
-- `ACCESS_KEY_ID`: the public key used to authenticate to S3
-- `ACCESS_SECRET_KEY`: the corresponding secret key
-- `ACCESS_SESSION_TOKEN`: (optional) a temporary session token, if required
-
-These credentials must be stored securely in a Kubernetes secret:
-
-```sh
-kubectl create secret generic aws-creds \
-  --from-literal=ACCESS_KEY_ID=<access key here> \
-  --from-literal=ACCESS_SECRET_KEY=<secret key here>
-# --from-literal=ACCESS_SESSION_TOKEN=<session token here> # if required
-```
-
-The credentials will be encrypted at rest if your Kubernetes environment
-supports it.
-
-You can then reference the secret in your `ObjectStore` definition:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: aws-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    s3Credentials:
-      accessKeyId:
-        name: aws-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: aws-creds
-        key: ACCESS_SECRET_KEY
-  [...]
-```
-
-### IAM Role for Service Account (IRSA)
-
-To use IRSA with EKS, configure the service account of the PostgreSQL cluster
-with the appropriate annotation:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  [...]
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        eks.amazonaws.com/role-arn: arn:[...]
-        [...]
-```
-
-### S3 Lifecycle Policy
-
-Barman Cloud uploads backup files to S3 but does not modify them afterward.
-To enhance data durability and protect against accidental or malicious loss,
-it's recommended to implement the following best practices:
-
-- Enable object versioning
-- Enable object locking to prevent objects from being deleted or overwritten
-  for a defined period or indefinitely (this provides an additional layer of
-  protection against accidental deletion and ransomware attacks)
-- Set lifecycle rules to expire current versions a few days after your Barman
-  retention window
-- Expire non-current versions after a longer period
-
-These strategies help you safeguard backups without requiring broad delete
-permissions, ensuring both security and compliance with minimal operational
-overhead.
-
-
-### S3-Compatible Storage Providers
-
-You can use S3-compatible services like **MinIO**, **Linode (Akamai) Object Storage**,
-or **DigitalOcean Spaces** by specifying a custom `endpointURL`.
-
-Example with Linode (Akamai) Object Storage (`us-east1`):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: linode-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/"
-    endpointURL: "https://us-east1.linodeobjects.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-Example with DigitalOcean Spaces (SFO3, path-style):
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: digitalocean-store
-spec:
-  configuration:
-    destinationPath: "s3://BUCKET_NAME/path/to/folder"
-    endpointURL: "https://sfo3.digitaloceanspaces.com"
-    s3Credentials:
-    [...]
-  [...]
-```
-
-### Using Object Storage with a Private CA
-
-For object storage services (e.g., MinIO) that use HTTPS with certificates
-signed by a private CA, set the `endpointCA` field in the `ObjectStore`
-definition. Unless you already have it, create a Kubernetes `Secret` with the
-CA bundle:
-
-```sh
-kubectl create secret generic my-ca-secret --from-file=ca.crt
-```
-
-Then reference it:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    endpointURL: <myEndpointURL>
-    endpointCA:
-      name: my-ca-secret
-      key: ca.crt
-  [...]
-```
-
-<!-- TODO: does this also apply to the plugin? -->
-:::note
-If you want `ConfigMaps` and `Secrets` to be **automatically** reloaded by
-instances, you can add a label with the key `cnpg.io/reload` to the
-`Secrets`/`ConfigMaps`. Otherwise, you will have to reload the instances using the
-`kubectl cnpg reload` subcommand.
-:::
-
----
-
-## Azure Blob Storage
-
-[Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/)
-is Microsoft’s cloud-based object storage solution.
-
-Barman Cloud supports the following authentication methods:
-
-- [Connection String](https://learn.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string)
-- Storage Account Name + [Access Key](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage)
-- Storage Account Name + [SAS Token](https://learn.microsoft.com/en-us/azure/storage/blobs/sas-service-create)
-- [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/introduction.html)
-
-### Azure AD Workload Identity
-
-This method avoids storing credentials in Kubernetes via the
-`.spec.configuration.inheritFromAzureAD` option:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      inheritFromAzureAD: true
-  [...]
-```
-
-### Access Key, SAS Token, or Connection String
-
-Store credentials in a Kubernetes secret:
-
-```sh
-kubectl create secret generic azure-creds \
-  --from-literal=AZURE_STORAGE_ACCOUNT=<storage account name> \
-  --from-literal=AZURE_STORAGE_KEY=<storage account key> \
-  --from-literal=AZURE_STORAGE_SAS_TOKEN=<SAS token> \
-  --from-literal=AZURE_STORAGE_CONNECTION_STRING=<connection string>
-```
-
-Then reference the required keys in your `ObjectStore`:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: azure-store
-spec:
-  configuration:
-    destinationPath: "<destination path here>"
-    azureCredentials:
-      connectionString:
-        name: azure-creds
-        key: AZURE_CONNECTION_STRING
-      storageAccount:
-        name: azure-creds
-        key: AZURE_STORAGE_ACCOUNT
-      storageKey:
-        name: azure-creds
-        key: AZURE_STORAGE_KEY
-      storageSasToken:
-        name: azure-creds
-        key: AZURE_STORAGE_SAS_TOKEN
-  [...]
-```
-
-For Azure Blob, the destination path format is:
-
-```
-<http|https>://<account-name>.<service-name>.core.windows.net/<container>/<blob>
-```
-
-### Azure-Compatible Providers
-
-If you're using a different implementation (e.g., Azurite or emulator):
-
-```
-<http|https>://<local-machine-address>:<port>/<account-name>/<container>/<blob>
-```
-
----
-
-## Google Cloud Storage
-
-[Google Cloud Storage](https://cloud.google.com/storage/) is supported with two
-authentication modes:
-
-- **GKE Workload Identity** (recommended inside Google Kubernetes Engine)
-- **Service Account JSON key** via the `GOOGLE_APPLICATION_CREDENTIALS` environment variable
-
-### GKE Workload Identity
-
-Use the [Workload Identity authentication](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
-when running in GKE:
-
-1. Set `googleCredentials.gkeEnvironment` to `true` in the `ObjectStore`
-   resource
-2. Annotate the `serviceAccountTemplate` in the `Cluster` resource with the GCP
-   service account
-
-For example, in the `ObjectStore` resource:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      gkeEnvironment: true
-```
-
-And in the `Cluster` resource:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-spec:
-  serviceAccountTemplate:
-    metadata:
-      annotations:
-        iam.gke.io/gcp-service-account: [...].iam.gserviceaccount.com
-```
-
-### Service Account JSON Key
-
-Follow Google’s [authentication setup](https://cloud.google.com/docs/authentication/getting-started),
-then:
-
-```sh
-kubectl create secret generic backup-creds --from-file=gcsCredentials=gcs_credentials_file.json
-```
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: google-store
-spec:
-  configuration:
-    destinationPath: "gs://<bucket>/<folder>"
-    googleCredentials:
-      applicationCredentials:
-        name: backup-creds
-        key: gcsCredentials
-  [...]
-```
-
-:::important
-This authentication method generates a JSON file within the container
-with all the credentials required to access your Google Cloud Storage
-bucket. As a result, if someone gains access to the `Pod`, they will also have
-write permissions to the bucket.
-:::
-
----
-
-
-## MinIO Gateway
-
-MinIO Gateway can proxy requests to cloud object storage providers like S3 or GCS.
-For more information, refer to [MinIO official documentation](https://docs.min.io/).
-
-### Setup
-
-Create MinIO access credentials:
-
-```sh
-kubectl create secret generic minio-creds \
-  --from-literal=MINIO_ACCESS_KEY=<minio access key> \
-  --from-literal=MINIO_SECRET_KEY=<minio secret key>
-```
-
-:::note
-Cloud Object Storage credentials will be used only by MinIO Gateway in this
-case.
-:::
-
-Expose MinIO Gateway via `ClusterIP`:
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: minio-gateway-service
-spec:
-  type: ClusterIP
-  ports:
-    - port: 9000
-      targetPort: 9000
-      protocol: TCP
-  selector:
-    app: minio
-```
-
-Here follows an excerpt of an example of deployment relaying to S3:
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-[...]
-spec:
-  containers:
-  - name: minio
-    image: minio/minio:RELEASE.2020-06-03T22-13-49Z
-    args: ["gateway", "s3"]
-    ports:
-    - containerPort: 9000
-    env:
-    - 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
-    - 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
-```
-
-Proceed by configuring MinIO Gateway service as the `endpointURL` in the
-`ObjectStore` definition, then choose a bucket name to replace `BUCKET_NAME`:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    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
-  [...]
-```
-
-:::important
-Verify on `s3://BUCKET_NAME/` the presence of archived WAL files before
-proceeding with a backup.
-:::
-
----

web/versioned_docs/version-0.5.0/parameters.md

@@ -1,19 +0,0 @@
----
-sidebar_position: 100
----
-
-# Parameters
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The following parameters are available for the Barman Cloud Plugin:
-
-- `barmanObjectName`: references the `ObjectStore` resource to be used by the
-  plugin.
-- `serverName`: Specifies the server name in the object store.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::

web/versioned_docs/version-0.5.0/plugin-barman-cloud.v1.md

@@ -1,105 +0,0 @@
-# API Reference
-
-## Packages
-- [barmancloud.cnpg.io/v1](#barmancloudcnpgiov1)
-
-
-## barmancloud.cnpg.io/v1
-
-Package v1 contains API Schema definitions for the barmancloud v1 API group
-
-### Resource Types
-- [ObjectStore](#objectstore)
-
-
-
-#### InstanceSidecarConfiguration
-
-
-
-InstanceSidecarConfiguration defines the configuration for the sidecar that runs in the instance pods.
-
-
-
-_Appears in:_
-- [ObjectStoreSpec](#objectstorespec)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `env` _[EnvVar](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#envvar-v1-core) array_ | The environment to be explicitly passed to the sidecar |  |  |  |
-| `retentionPolicyIntervalSeconds` _integer_ | The retentionCheckInterval defines the frequency at which the<br />system checks and enforces retention policies. |  | 1800 |  |
-| `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | Resources define cpu/memory requests and limits for the sidecar that runs in the instance pods. |  |  |  |
-
-
-#### ObjectStore
-
-
-
-ObjectStore is the Schema for the objectstores API.
-
-
-
-
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `apiVersion` _string_ | `barmancloud.cnpg.io/v1` | True | | |
-| `kind` _string_ | `ObjectStore` | True | | |
-| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | True |  |  |
-| `spec` _[ObjectStoreSpec](#objectstorespec)_ | Specification of the desired behavior of the ObjectStore.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status | True |  |  |
-| `status` _[ObjectStoreStatus](#objectstorestatus)_ | Most recently observed status of the ObjectStore. This data may not be up to<br />date. Populated by the system. Read-only.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status |  |  |  |
-
-
-#### ObjectStoreSpec
-
-
-
-ObjectStoreSpec defines the desired state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `configuration` _[BarmanObjectStoreConfiguration](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration)_ | The configuration for the barman-cloud tool suite | True |  |  |
-| `retentionPolicy` _string_ | RetentionPolicy is the retention policy to be used for backups<br />and WALs (i.e. '60d'). The retention policy is expressed in the form<br />of `XXu` where `XX` is a positive integer and `u` is in `[dwm]` -<br />days, weeks, months. |  |  | Pattern: `^[1-9][0-9]*[dwm]$` <br /> |
-| `instanceSidecarConfiguration` _[InstanceSidecarConfiguration](#instancesidecarconfiguration)_ | The configuration for the sidecar that runs in the instance pods |  |  |  |
-
-
-#### ObjectStoreStatus
-
-
-
-ObjectStoreStatus defines the observed state of ObjectStore.
-
-
-
-_Appears in:_
-- [ObjectStore](#objectstore)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `serverRecoveryWindow` _object (keys:string, values:[RecoveryWindow](#recoverywindow))_ | ServerRecoveryWindow maps each server to its recovery window | True |  |  |
-
-
-#### RecoveryWindow
-
-
-
-RecoveryWindow represents the time span between the first
-recoverability point and the last successful backup of a PostgreSQL
-server, defining the period during which data can be restored.
-
-
-
-_Appears in:_
-- [ObjectStoreStatus](#objectstorestatus)
-
-| Field | Description | Required | Default | Validation |
-| --- | --- | --- | --- | --- |
-| `firstRecoverabilityPoint` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The first recoverability point in a PostgreSQL server refers to<br />the earliest point in time to which the database can be<br />restored. | True |  |  |
-| `lastSuccussfulBackupTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The last successful backup time | True |  |  |
-
-

web/versioned_docs/version-0.5.0/retention.md

@@ -1,38 +0,0 @@
----
-sidebar_position: 60
----
-
-# Retention Policies
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin supports **automated cleanup of obsolete backups** via
-retention policies, configured in the `.spec.retentionPolicy` field of the
-`ObjectStore` resource.
-
-:::note
-This feature uses the `barman-cloud-backup-delete` command with the
-`--retention-policy "RECOVERY WINDOW OF {{ value }} {{ unit }}"` syntax.
-:::
-
-#### Example: 30-Day Retention Policy
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: my-store
-spec:
-  [...]
-  retentionPolicy: "30d"
-````
-
-:::note
-A **recovery window retention policy** ensures the cluster can be restored to
-any point in time between the calculated *Point of Recoverability* (PoR) and
-the latest WAL archive. The PoR is defined as `current time - recovery window`.
-The **first valid backup** is the most recent backup completed before the PoR.
-Backups older than that are marked as *obsolete* and deleted after the next
-backup completes.
-:::
-

web/versioned_docs/version-0.5.0/usage.md

@@ -1,258 +0,0 @@
----
-sidebar_position: 30
----
-
-# Using the Barman Cloud Plugin
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-After [installing the plugin](installation.mdx) in the same namespace as the
-CloudNativePG operator, enabling your PostgreSQL cluster to use the Barman
-Cloud Plugin involves just a few steps:
-
-- Defining the object store containing your WAL archive and base backups, using
-  your preferred [provider](object_stores.md)
-- Instructing the Postgres cluster to use the Barman Cloud Plugin
-
-From that moment, you’ll be able to issue on-demand backups or define a backup
-schedule, as well as rely on the object store for recovery operations.
-
-The rest of this page details each step, using MinIO as object store provider.
-
-## Defining the `ObjectStore`
-
-An `ObjectStore` resource must be created for each object store used in your
-PostgreSQL architecture. Here's an example configuration using MinIO:
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-    destinationPath: s3://backups/
-    endpointURL: http://minio:9000
-    s3Credentials:
-      accessKeyId:
-        name: minio
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: minio
-        key: ACCESS_SECRET_KEY
-    wal:
-      compression: gzip
-```
-
-The `.spec.configuration` schema follows the same format as the
-[in-tree barman-cloud support](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration).
-Refer to [the CloudNativePG documentation](https://cloudnative-pg.io/documentation/current/appendixes/backup_barmanobjectstore/)
-for additional details.
-
-:::important
-The `serverName` parameter in the `ObjectStore` resource is retained solely for
-API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
-When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
-:::
-
-## Configuring WAL Archiving
-
-Once the `ObjectStore` is defined, you can configure your PostgreSQL cluster
-to archive WALs by referencing the store in the `.spec.plugins` section:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  instances: 3
-  imagePullPolicy: Always
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store
-  storage:
-    size: 1Gi
-```
-
-This configuration enables both WAL archiving and data directory backups.
-
-## Performing a Base Backup
-
-Once WAL archiving is enabled, the cluster is ready for backups. To issue an
-on-demand backup, use the following configuration with the plugin method:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Backup
-metadata:
-  name: backup-example
-spec:
-  cluster:
-    name: cluster-example
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-```
-
-:::note
-You can apply the same concept to the `ScheduledBackup` resource.
-:::
-
-## Restoring a Cluster
-
-To restore a cluster from an object store, create a new `Cluster` resource that
-references the store containing the backup. Below is an example configuration:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-:::important
-The above configuration does **not** enable WAL archiving for the restored cluster.
-:::
-
-To enable WAL archiving for the restored cluster, include the `.spec.plugins`
-section alongside the `externalClusters.plugin` section, as shown below:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-restore
-spec:
-  instances: 3
-  imagePullPolicy: IfNotPresent
-  bootstrap:
-    recovery:
-      source: source
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      # Backup Object Store (push, read-write)
-      barmanObjectName: minio-store-bis
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        # Recovery Object Store (pull, read-only)
-        barmanObjectName: minio-store
-        serverName: cluster-example
-  storage:
-    size: 1Gi
-```
-
-The same object store may be used for both transaction log archiving and
-restoring a cluster, or you can configure separate stores for these purposes.
-
-## Configuring Replica Clusters
-
-You can set up a distributed topology by combining the previously defined
-configurations with the `.spec.replica` section. Below is an example of how to
-define a replica cluster:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-dc-a
-spec:
-  instances: 3
-  primaryUpdateStrategy: unsupervised
-
-  storage:
-    storageClass: csi-hostpath-sc
-    size: 1Gi
-
-  plugins:
-  - name: barman-cloud.cloudnative-pg.io
-    isWALArchiver: true
-    parameters:
-      barmanObjectName: minio-store-a
-
-  replica:
-    self: cluster-dc-a
-    primary: cluster-dc-a
-    source: cluster-dc-b
-
-  externalClusters:
-  - name: cluster-dc-a
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-a
-
-  - name: cluster-dc-b
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: minio-store-b
-```
-
-## Configuring the plugin instance sidecar
-
-The Barman Cloud Plugin runs as a sidecar container next to each PostgreSQL
-instance pod. It manages backup, WAL archiving, and restore processes.
-
-Configuration comes from multiple `ObjectStore` resources:
-
-1. The one referenced in the
-   `.spec.plugins` section of the `Cluster`. This is the
-   object store used for WAL archiving and base backups.
-2. The one referenced in the external cluster
-   used in the `.spec.replica.source` section of the `Cluster`. This is
-   used by the log-shipping designated primary to get the WAL files.
-3. The one referenced in the
-   `.spec.bootstrap.recovery.source` section of the `Cluster`. Used by
-   the initial recovery job to create the cluster from an existing backup.
-
-You can fine-tune sidecar behavior in the `.spec.instanceSidecarConfiguration`
-of your ObjectStore. These settings apply to all PostgreSQL instances that use
-this object store. Any updates take effect at the next `Cluster` reconciliation,
-and could generate a rollout of the `Cluster`.
-
-```yaml
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: minio-store
-spec:
-  configuration:
-  # [...]
-  instanceSidecarConfiguration:
-    retentionPolicyIntervalSeconds: 1800
-    resources:
-      requests:
-        memory: "XXX"
-        cpu: "YYY"
-      limits:
-        memory: "XXX"
-        cpu: "YYY"
-```
-
-:::note
-If more than one `ObjectStore` applies, the `instanceSidecarConfiguration` of
-the one set in `.spec.plugins` has priority.
-:::

web/versioned_docs/version-0.6.0/compression.md

@@ -1,43 +0,0 @@
----
-sidebar_position: 80
----
-
-# Compression
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-By default, backups and WAL files are archived **uncompressed**. However, the
-Barman Cloud Plugin supports multiple compression algorithms via
-`barman-cloud-backup` and `barman-cloud-wal-archive`, allowing you to optimize
-for space, speed, or a balance of both.
-
-### Supported Compression Algorithms
-
-- `bzip2`
-- `gzip`
-- `lz4` (WAL only)
-- `snappy`
-- `xz` (WAL only)
-- `zstd` (WAL only)
-
-Compression settings for base backups and WAL archives are configured
-independently. For implementation details, refer to the corresponding API
-definitions:
-
-- [`DataBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#DataBackupConfiguration)
-- [`WALBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#WalBackupConfiguration)
-
-:::important
-Compression impacts both performance and storage efficiency. Choose the right
-algorithm based on your recovery time objectives (RTO), storage capacity, and
-network throughput.
-:::
-
-## Compression Benchmark (on MinIO)
-
-| Compression | Backup Time (ms) | Restore Time (ms) | Uncompressed Size (MB) | Compressed Size (MB) | Ratio |
-| ----------- | ---------------- | ----------------- | ---------------------- | -------------------- | ----- |
-| None        | 10,927           | 7,553             | 395                    | 395                  | 1.0:1 |
-| bzip2       | 25,404           | 13,886            | 395                    | 67                   | 5.9:1 |
-| gzip        | 116,281          | 3,077             | 395                    | 91                   | 4.3:1 |
-| snappy      | 8,134            | 8,341             | 395                    | 166                  | 2.4:1 |

web/versioned_docs/version-0.6.0/concepts.md

@@ -1,177 +0,0 @@
----
-sidebar_position: 10
----
-
-# Main Concepts
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-:::important
-Before proceeding, make sure to review the following sections of the
-CloudNativePG documentation:
-
-- [**Backup**](https://cloudnative-pg.io/documentation/current/backup/)
-- [**WAL Archiving**](https://cloudnative-pg.io/documentation/current/wal_archiving/)
-- [**Recovery**](https://cloudnative-pg.io/documentation/current/recovery/)
-:::
-
-The **Barman Cloud Plugin** enables **hot (online) backups** of PostgreSQL
-clusters in CloudNativePG through [`barman-cloud`](https://pgbarman.org),
-supporting continuous physical backups and WAL archiving to an **object
-store**—without interrupting write operations.
-
-It also supports both **full recovery** and **Point-in-Time Recovery (PITR)**
-of a PostgreSQL cluster.
-
-## The Object Store
-
-At the core is the [`ObjectStore` custom resource (CRD)](plugin-barman-cloud.v1.md#objectstorespec),
-which acts as the interface between the PostgreSQL cluster and the target
-object storage system. It allows you to configure:
-
-- **Authentication and bucket location** via the `.spec.configuration` section
-- **WAL archiving** settings—such as compression type, parallelism, and
-  server-side encryption—under `.spec.configuration.wal`
-- **Base backup options**—with similar settings for compression, concurrency,
-  and encryption—under `.spec.configuration.data`
-- **Retention policies** to manage the life-cycle of archived WALs and backups
-  via `.spec.configuration.retentionPolicy`
-
-WAL files are archived in the `wals` directory, while base backups are stored
-as **tarballs** in the `base` directory, following the
-[Barman Cloud convention](https://docs.pgbarman.org/cloud/latest/usage/#object-store-layout).
-
-The plugin also offers advanced capabilities, including
-[backup tagging](misc.md#backup-object-tagging) and
-[extra options for backups and WAL archiving](misc.md#extra-options-for-backup-and-wal-archiving).
-
-:::tip
-For details, refer to the
-[API reference for the `ObjectStore` resource](plugin-barman-cloud.v1.md#objectstorespec).
-:::
-
-## Integration with a CloudNativePG Cluster
-
-CloudNativePG can delegate continuous backup and recovery responsibilities to
-the **Barman Cloud Plugin** by configuring the `.spec.plugins` section of a
-`Cluster` resource. This setup requires a corresponding `ObjectStore` resource
-to be defined.
-
-:::important
-While it is technically possible to reuse the same `ObjectStore` for multiple
-`Cluster` resources within the same namespace, it is strongly recommended to
-dedicate one object store per PostgreSQL cluster to ensure data isolation and
-operational clarity.
-:::
-
-The following example demonstrates how to configure a CloudNativePG cluster
-named `cluster-example` to use a previously defined `ObjectStore` (also named
-`cluster-example`) in the same namespace. Setting `isWALArchiver: true` enables
-WAL archiving through the plugin:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: cluster-example
-spec:
-  # Other cluster settings...
-  plugins:
-    - name: barman-cloud.cloudnative-pg.io
-      isWALArchiver: true
-      parameters:
-        barmanObjectName: cluster-example
-```
-
-## Backup of a Postgres Cluster
-
-Once the object store is defined and the `Cluster` is configured to use the
-Barman Cloud Plugin, **WAL archiving is activated immediately** on the
-PostgreSQL primary.
-
-Physical base backups are seamlessly managed by CloudNativePG using the
-`Backup` and `ScheduledBackup` resources, respectively for
-[on-demand](https://cloudnative-pg.io/documentation/current/backup/#on-demand-backups)
-and
-[scheduled](https://cloudnative-pg.io/documentation/current/backup/#scheduled-backups)
-backups.
-
-To use the Barman Cloud Plugin, you must set the `method` to `plugin` and
-configure the `pluginConfiguration` section as shown:
-
-```yaml
-[...]
-spec:
-  method: plugin
-  pluginConfiguration:
-    name: barman-cloud.cloudnative-pg.io
-  [...]
-```
-
-With this configuration, CloudNativePG supports:
-
-- Backups from both **primary** and **standby** instances
-- Backups from **designated primaries** in a distributed topology using
-  [replica clusters](https://cloudnative-pg.io/documentation/current/replica_cluster/)
-
-:::tip
-For details on how to back up from a standby, refer to the official documentation:
-[Backup from a standby](https://cloudnative-pg.io/documentation/current/backup/#backup-from-a-standby).
-:::
-
-:::important
-Both backup and WAL archiving operations are executed by sidecar containers
-running in the same pod as the PostgreSQL `Cluster` primary instance—except
-when backups are taken from a standby, in which case the sidecar runs alongside
-the standby pod.
-The sidecar containers use a [dedicated container image](images.md) that
-includes only the supported version of Barman Cloud.
-:::
-
-## Recovery of a Postgres Cluster
-
-In PostgreSQL, *recovery* refers to the process of starting a database instance
-from an existing backup.  The Barman Cloud Plugin integrates with CloudNativePG
-to support both **full recovery** and **Point-in-Time Recovery (PITR)** from an
-object store.
-
-Recovery in this context is *not in-place*: it bootstraps a brand-new
-PostgreSQL cluster from a backup and replays the necessary WAL files to reach
-the desired recovery target.
-
-To perform a recovery, define an *external cluster* that references the
-appropriate `ObjectStore`, and use it as the source in the `bootstrap` section
-of the target cluster:
-
-```yaml
-[...]
-spec:
-  [...]
-  bootstrap:
-    recovery:
-      source: source
-  externalClusters:
-  - name: source
-    plugin:
-      name: barman-cloud.cloudnative-pg.io
-      parameters:
-        barmanObjectName: cluster-example
-        serverName: cluster-example
-  [...]
-```
-
-The critical element here is the `externalClusters` section of the `Cluster`
-resource, where the `plugin` stanza instructs CloudNativePG to use the Barman
-Cloud Plugin to access the object store for recovery.
-
-This same mechanism can be used for a variety of scenarios enabled by the
-CloudNativePG API, including:
-
-* **Full cluster recovery** from the latest backup
-* **Point-in-Time Recovery (PITR)**
-* Bootstrapping **replica clusters** in a distributed topology
-
-:::tip
-For complete instructions and advanced use cases, refer to the official
-[Recovery documentation](https://cloudnative-pg.io/documentation/current/recovery/).
-:::

web/versioned_docs/version-0.6.0/images.md

@@ -1,37 +0,0 @@
----
-sidebar_position: 99
----
-
-# Container Images
-
-<!-- SPDX-License-Identifier: CC-BY-4.0 -->
-
-The Barman Cloud Plugin is distributed using two container images:
-
-- One for deploying the plugin components
-- One for the sidecar that runs alongside each PostgreSQL instance in a
-  CloudNativePG `Cluster` using the plugin
-
-## Plugin Container Image
-
-The plugin image contains the logic required to operate the Barman Cloud Plugin
-within your Kubernetes environment with CloudNativePG. It is published on the
-GitHub Container Registry at `ghcr.io/cloudnative-pg/plugin-barman-cloud`.
-
-This image is built from the
-[`Dockerfile.plugin`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.plugin)
-in the plugin repository.
-
-## Sidecar Container Image
-
-The sidecar image is used within each PostgreSQL pod in the cluster. It
-includes the latest supported version of Barman Cloud and is responsible for
-performing WAL archiving and backups on behalf of CloudNativePG.
-
-It is available at `ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar` and is
-built from the
-[`Dockerfile.sidecar`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.sidecar).
-
-These sidecar images are designed to work seamlessly with the
-[`minimal` PostgreSQL container images](https://github.com/cloudnative-pg/postgres-containers?tab=readme-ov-file#minimal-images)
-maintained by the CloudNativePG Community.

web/versioned_docs/version-0.6.0/installation.mdx

@@ -1,109 +0,0 @@
----
-sidebar_position: 20
----
-
-# Installation
-
-:::important
-1. The plugin **must** be installed in the same namespace as the CloudNativePG
-   operator (typically `cnpg-system`).
-
-2. Keep in mind that the operator's **listening namespaces** may differ from its
-   installation namespace. Double-check this to avoid configuration issues.
-:::
-
-## Verifying the Requirements
-
-Before installing the plugin, make sure the [requirements](intro.md#requirements) are met.
-
-### CloudNativePG Version
-
-Ensure you're running a version of CloudNativePG that is compatible with the
-plugin. If installed in the default `cnpg-system` namespace, you can verify the
-version with:
-
-```sh
-kubectl get deployment -n cnpg-system cnpg-controller-manager \
-  -o jsonpath="{.spec.template.spec.containers[*].image}"
-```
-
-Example output:
-
-```output
-ghcr.io/cloudnative-pg/cloudnative-pg:1.26.0
-```
-
-The version **must be 1.26 or newer**.
-
-### cert-manager
-
-Use the [cmctl](https://cert-manager.io/docs/reference/cmctl/#installation)
-tool to confirm that `cert-manager` is installed and available:
-
-```sh
-cmctl check api
-```
-
-Example output:
-
-```output
-The cert-manager API is ready
-```
-
-Both checks are required before proceeding with the installation.
-
-## Installing the Barman Cloud Plugin
-
-import { InstallationSnippet } from '@site/src/components/Installation';
-
-Install the plugin using `kubectl` by applying the manifest for the latest
-release:
-
-<InstallationSnippet />
-
-Example output:
-
-```output
-customresourcedefinition.apiextensions.k8s.io/objectstores.barmancloud.cnpg.io created
-serviceaccount/plugin-barman-cloud created
-role.rbac.authorization.k8s.io/leader-election-role created
-clusterrole.rbac.authorization.k8s.io/metrics-auth-role created
-clusterrole.rbac.authorization.k8s.io/metrics-reader created
-clusterrole.rbac.authorization.k8s.io/objectstore-editor-role created
-clusterrole.rbac.authorization.k8s.io/objectstore-viewer-role created
-clusterrole.rbac.authorization.k8s.io/plugin-barman-cloud created
-rolebinding.rbac.authorization.k8s.io/leader-election-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/metrics-auth-rolebinding created
-clusterrolebinding.rbac.authorization.k8s.io/plugin-barman-cloud-binding created
-secret/plugin-barman-cloud-8tfddg42gf created
-service/barman-cloud created
-deployment.apps/barman-cloud configured
-certificate.cert-manager.io/barman-cloud-client created
-certificate.cert-manager.io/barman-cloud-server created
-issuer.cert-manager.io/selfsigned-issuer created
-```
-
-Finally, check that the deployment is up and running:
-
-```sh
-kubectl rollout status deployment \
-  -n cnpg-system barman-cloud
-```
-
-Example output:
-
-```output
-deployment "barman-cloud" successfully rolled out
-```
-
-This confirms that the plugin is deployed and ready to use.
-
-## Testing the latest development snapshot
-
-You can also test the latest development snapshot of the plugin with the
-following command:
-
-```sh
-kubectl apply -f \
-  https://raw.githubusercontent.com/cloudnative-pg/plugin-barman-cloud/refs/heads/main/manifest.yaml
-```