---
title: "How to back up the OPCP controller data"
description: "Find out how to manually back up the OPCP controller data"
url: https://docs.ovhcloud.com/de/guides/hosted-private-cloud/opcp/how-to-create-a-backup
lang: de
lastUpdated: 2026-09-25
---
> For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/de/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/de/llms-full.txt.

# How to back up the OPCP controller data

## Objective

OPCP backs up its controller data, so you can recover from physical or logical failures. These backups do not cover any other data, such as the data stored on the OPCP servers.

Backups of OPCP controller data are automatically scheduled hourly for databases, PVs, KMS autounsealer shares and `tfstate`. Database backups rely on the Kubernetes `ScheduledBackups` resource; PV, KMS autounsealer share and `tfstate` backups rely on [Velero](https://velero.io/).

The backups of `tfstate` contain the state of [OpenTofu](https://opentofu.org/) within the setup of OPCP. OpenTofu uses it, for example, to set up IAM.

PVs are the Kubernetes Persistent Volume resources. This is stateful data stored in the controller's Kubernetes cluster.

The KMS autounsealer shares are secrets needed to unseal the secrets management system.

## Requirements

Make sure your backups are stored outside the cluster: run `opcp-cli config edit` and check that `backups.endpoint.url` points outside the cluster. Also `backups.endpoint.region` must be set accordingly. The buckets configured in `backups.db.bucket` and `backups.pv.bucket` must exist.

Credentials must also be set correctly with `opcp-cli secrets passwords --edit`
. The keys `stringData.backup_access_key_id`
 and `stringData.backup_secret_access_key`
 must be set with the secrets provided by the S31
 provider. Make sure the user has access to all the buckets.
## Instructions

You can trigger backups manually from the terminal.

### Quick procedure

Run the following lines as `root` (using `sudo -i`) on the OPCP controller node.

```bash
kubectl get cluster -A -o jsonpath='{range .items[*]}kubectl cnpg backup {.metadata.name} -n {.metadata.namespace}{"\n"}{end}' | bash # schedule backups NOW for all database clusters
velero get schedule -o json | jq -r '.items[] | .metadata.name as $name | {cmd: ("velero backup create --from-schedule " + $name)} | .cmd' | bash # schedule backups NOW for all resources backed up by velero
```

Verify by running the following on the OPCP controller node.

```bash
kubectl get backup -A
velero backup get
```

Store your KMS shares:

```bash
touch kms-shares-backup.yaml
for i in {1..3}; do
  echo "---" >> kms-shares-backup.yaml
  kubectl -n kms get secret ovhcloud-kms-share-${i} -o yaml >> kms-shares-backup.yaml
done
```

Store the contents of `kms-shares-backup.yaml` in a safe place, ideally in your trusted password manager.

### Databases

To list all databases, run `kubectl get cluster -A`. Do a backup by running `kubectl cnpg backup {db-name} -n {namespace}`. Replace `{db-name}` with the database cluster name and `{namespace}` with the corresponding namespace.

There is a shortcut to trigger backups of all the database clusters: `kubectl get cluster -A -o jsonpath='{range .items[*]}kubectl cnpg backup {.metadata.name} -n {.metadata.namespace}{"\n"}{end}' | bash`.

### KMS autounsealer shares

Create a backup of `kms-autounsealer-shares-backup`:

```bash
velero backup create --from-schedule kms-autounsealer-shares-backup
```

### PVs

Create a backup of the PVs:

```bash
velero backup create --from-schedule pvs-backup
```

### tfstate

OPCP relies on [OpenTofu](https://opentofu.org/) during setup. Its state must be backed up. Create a backup by running:

```bash
velero backup create --from-schedule tfstate-backup
```

### Verification

To check the database backups, run `kubectl get backup -A`: it lists all available database backups.

To verify PV, KMS autounsealer shares and `tfstate` backups are present, run `velero backup get`.

Also check your S3 buckets, for example with [s3cmd](https://s3tools.org/s3cmd): if they contain no data, the backup configuration is wrong. First configure `s3cmd` to read from your bucket:

```bash
cat << EOF > ~/.s3cfg
[default]
access_key = ${ACCESS_KEY_ID}
secret_key = ${SECRET_ACCESS_KEY}
bucket_location = ${REGION}
host_base = s3.gra.io.cloud.ovh.net
host_bucket = %(bucket)s.s3.gra.io.cloud.ovh.net
EOF
```

Adjust the values as needed. Then run `s3cmd ls s3://bucket-name` to check that the bucket contains data.

### KMS unsealer shares

The KMS deployed in OPCP is based on [Shamir's secret sharing](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing): the secret is divided into three shares, two of which are required for decryption. As of OPCP version 3.1.0, these shares are not backed up, as they are considered highly sensitive.

To back them up, store the Kubernetes secrets within your trusted password manager, completely separate from the OPCP installation.

You can retrieve the secrets by running:

```bash
kubectl -n kms get secret -o yaml ovhcloud-kms-share-1
kubectl -n kms get secret -o yaml ovhcloud-kms-share-2
kubectl -n kms get secret -o yaml ovhcloud-kms-share-3
```

Store the output in a safe place, ideally in your password manager.

## Go further

For more information about how to configure your backups, see the [How to update the backup S3 buckets](https://docs.ovhcloud.com/de/guides/hosted-private-cloud/opcp/how-to-update-backup-s3-buckets.md) guide.

For training or technical assistance implementing our solutions, contact your sales representative or visit our [Professional Services](https://www.ovhcloud.com/de/professional-services/) page to request a quote and have your project analysed by our experts.

Join our [community of users](https://community.ovhcloud.com/).

1
: S3 is a trademark of Amazon Technologies, Inc. OVHcloud's service is not sponsored by, endorsed by, or otherwise affiliated with Amazon Technologies, Inc.