Making on-demand backup¶

To make an on-demand backup, you should first check your Custom Resource for the necessary options and make changes, if needed, using the deploy/cr.yaml configuration file:
- the backup.enabled key should be set to true,
- backup.storages subsection should contain at least one configured storage.
You can apply changes in the deploy/cr.yaml file with the usual kubectl apply -f deploy/cr.yaml command.
Now use a special backup configuration YAML file with the following keys:
- metadata.name key should be set to the backup name (this name will be needed later to restore the bakup),
- spec.clusterName key should be set to the name of your cluster (prior to the Operator version 1.12.0 this key was named spec.psmdbCluster),
- spec.storageName key should be set to the name of your already configured storage.
- optionally you can set the spec.type key to physical if you would like to make physical backups instead of logical ones (please see the physical backups limitations). Otherwise set this key to logical, or just omit it.
You can find the example of such file in deploy/backup/backup.yaml :
```
apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDBBackup
metadata:
  finalizers:
  - delete-backup
  name: backup1
spec:
  clusterName: my-cluster-name
  storageName: s3-us-west
  type: logical
```

Run the actual backup command using this file:

$ kubectl apply -f deploy/backup/backup.yaml

Note

If you plan to restore backup to a new Kubernetes-based environment, make sure you will be able to create there a Secrets object with the same user passwords as in the original cluster. More details about secrets can be found in System Users. The name of the current Secrets object you will need to recreate can be found out from the spec.secrets key in the deploy/cr.yaml (my-cluster-name-secrets by default).

You can track the backup process with the PerconaServerMongoDBBackup Custom Resource as follows:
```
$ kubectl get psmdb-backup
```
Expected output
```
NAME      CLUSTER           STORAGE      DESTINATION            STATUS    COMPLETED   AGE
backup1   my-cluster-name   s3-us-west   2022-09-08T03:22:19Z   running               49s
```
It should show the status as READY when the backup process is over.

If you have any issues with the backup, you can view logs from the backup-agent container of the appropriate Pod as follows:
```
$ kubectl logs pod/my-cluster-name-rs0 -c backup-agent
```
Alternatively, getting ssh access to the same container will allow you to carry on Percona Backup for MongoDB diagnostics .

Note

In both cases you will need the name of the Pod that made the backup. You can find the pbmPodName field in the output of the kubectl get psmdb-backup <backup_name> -o yaml command.

Get expert help¶

If you need assistance, visit the community forum for comprehensive and free database knowledge, or contact our Percona Database Experts for professional support and services. Join K8S Squad to benefit from early access to features and “ask me anything” sessions with the Experts.

Community Forum Get a Percona Expert Join K8S Squad

Last update: 2024-09-15