Percona Server for MongoDB Operator allows doing cluster backup in two ways. Scheduled backups are configured in the deploy/cr.yaml file to be executed automatically in proper time. On-demand backups can be done manually at any moment. Both ways are using the Percona Backup for MongoDB tool to do the job.
The backup process is controlled by the Backup Coordinator daemon residing in the Kubernetes cluster alongside the Percona Server for MongoDB, while actual backup images are stored separately on any Amazon S3 compatible storage.
Making scheduled backups
Since backups are stored separately on the Amazon S3, a secret with
AWS_SECRET_ACCESS_KEY should be present on the Kubernetes cluster. These keys should be saved to the deploy/backup-s3.yaml file and applied with the appropriate command, e.g.
kubectl apply -f deploy/backup-s3.yaml (for Kubernetes).
Backups schedule is defined in the
backup section of the deploy/cr.yaml file.
This section contains three subsections:
s3subsection contains data needed to access the Amazon S3 cloud to store backups.
coordinatorsubsections allows to configure Kubernetes limits and claims for the Percona Backup for MongoDB Coordinator daemon.
taskssubsection allows to actually schedule backups (the schedule is specified in crontab format).
The options within these three subsections are explained in the Operator Options.
Making on-demand backup
To make on-demand backup, user should run the PBM Control tool inside of the coordinator container, supplying it with needed options, like in the following example:
kubectl run -it --rm pbmctl --image=percona/percona-server-mongodb-operator:0.2.1-backup-pbmctl --restart=Never -- --server-address=my-cluster-name-backup-coordinator:10001 run backup --destination-type=aws --compression-algorithm=gzip --description=my-backup
Restore the cluster from a previously saved backup
Previously saved backups can be restored with a special backup restore job, configured with the deploy/backup-restore.yaml file. Following keys in this file should be edited before the job can be run:
- Both entries of the
secretKeyRef.namekey should be the same as the
s3.secretkey value in the deploy/cr.yaml backup section
BUCKET_NAMEis the S3 bucket name, and it should be same as the
s3.bucketkey value in the deploy/cr.yaml backup section
BACKUP_NAMEis the unique name (without the
.dump.gzsuffix) of the particular backup to be restored (the list of available backups can be seen in the S3 browser)
MONGODB_DSNis a connect string starting with
BACKUP-PASSWORD-HEREparts should be changed to the proper username and password of the backup user, same as ones in deploy/mongodb-users.yaml secret file.
When the editing is done, the restore job can be started in the following way (e.g. on the OpenShift platform):
oc create -f deploy/backup-restore.yaml