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 or 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:
storagessubsection contains data needed to access the S3-compatible cloud to store backups.
coordinatorsubsection 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).
Here is an example which uses Amazon S3 storage for backups:
... backup: enabled: true version: 0.3.0 ... storages: s3-us-west: type: s3 s3: bucket: S3-BACKUP-BUCKET-NAME-HERE region: us-west-2 credentialsSecret: my-cluster-name-backup-s3 tasks: - name: daily-s3-us-west enabled: true schedule: "0 0 * * *" storageName: s3-us-west compressionType: gzip ...
Note: if you use some S3-compatible storage instead of the original Amazon S3, one more key is needed in the
s3 subsection: the
endpointUrl, which points to the actual cloud used for backups and is specific to the cloud provider. For example, using Google Cloud involves the following one:
The options within these three subsections are further explained in the Operator Options.
The only option which should be mentioned separately is
credentialsSecret which is a Kubernetes secret for backups. Sample backup-s3.yaml can be used to create this secret object. Check that it contains proper
name value (equal to the one specified for
my-cluster-name-backup-s3 in the last example), and also proper
AWS_SECRET_ACCESS_KEY keys. After editing is finished, secrets object should be created (or updated with the new name and/or keys) using the following command:
$ kubectl apply -f deploy/backup-s3.yaml
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.3.0-backup-pbmctl --restart=Never -- \ run backup \ --server-address=<cluster-name>-backup-coordinator:10001 \ --storage <storage> \ --compression-algorithm=gzip \ --description=my-backup```
Don’t forget to specify the name of your cluster instead of the
<cluster-name> part of the Backup Coordinator URL (the same cluster name which is specified in the deploy/cr.yaml file). Also
<storage> should be substituted with the actual storage name, which is featured as a subsection inside of the
backups one in deploy/cr.yaml file. In the upper example it is
Restore the cluster from a previously saved backup
To restore a previously saved backup you will need to specify the backup name. List of available backups can be obtained from the Backup Coordinator as follows (supposedly that you once again use the Backup Coordinator’s proper URL and the storage name like you did to make on-demand backup):
kubectl run -it --rm pbmctl --image=percona/percona-server-mongodb-operator:0.3.0-backup-pbmctl --restart=Never -- list backups --server-address=<cluster-name>-backup-coordinator:10001
Now, restore the backup, using its name instead of the
kubectl run -it --rm pbmctl --image=percona/percona-server-mongodb-operator:0.3.0-backup-pbmctl --restart=Never -- \ run restore \ --server-address=<cluster-name>-backup-coordinator:10001 \ --storage <storage> \ backup-name