The Operator usually stores Server for MongoDB backups on Amazon S3 or S3-compatible storage outside the Kubernetes cluster:
The 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 use the Percona Backup for MongoDB tool.
Since backups are stored separately on the Amazon S3, a secret with
AWS_SECRET_ACCESS_KEY should be present on
the Kubernetes cluster. The secrets file with these base64-encoded keys should
be created: for example
deploy/backup-s3.yaml file with the following
apiVersion: v1 kind: Secret metadata: name: my-cluster-name-backup-s3 type: Opaque data: AWS_ACCESS_KEY_ID: UkVQTEFDRS1XSVRILUFXUy1BQ0NFU1MtS0VZ AWS_SECRET_ACCESS_KEY: UkVQTEFDRS1XSVRILUFXUy1TRUNSRVQtS0VZ
The following command can be used to get a base64-encoded string from
a plain text one:
$ echo -n 'plain-text-string' | base64
name value is the Kubernetes
name which will be used further, and
AWS_SECRET_ACCESS_KEY are the keys to access S3 storage (and
obviously they should contain proper values to make this access
possible). To have effect secrets file should be applied with the
appropriate command to create the secret object,
kubectl apply -f deploy/backup-s3.yaml (for Kubernetes).
Backups schedule is defined in the
backup section of the
file. This section contains three subsections:
storagescontains data needed to access the S3-compatible cloud to store backups.
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: "sat-night-backup" schedule: "0 0 * * 6" storageName: s3-us-west ...
if you use some S3-compatible storage instead of the original
Amazon S3, the endpointURL is needed in the
s3 subsection which points to the actual cloud used for backups and
is specific to the cloud provider. For example, using Google Cloud involves the following endpointUrl:
The options within these three subsections are further explained in the Operator Custom Resource options.
One option which should be mentioned separately is
credentialsSecret which is a Kubernetes
for backups. Value of this key should be the same as the name used to
create the secret object (
my-cluster-name-backup-s3 in the last
The schedule is specified in crontab format as explained in Operator Custom Resource options.
To make on-demand backup, user should use YAML file with correct names for the backup and the Percona Server for MongoDB Cluster, and correct PVC settings. The example of such file is deploy/backup/backup.yaml.
When the backup config file is ready, actual backup command is executed:
kubectl apply -f deploy/backup/backup.yaml
The example of such file is deploy/backup/restore.yaml.
Storing backup settings in a separate file can be replaced by
passing its content to the
kubectl apply command as follows:
cat <<EOF | kubectl apply -f- apiVersion: psmdb.percona.com/v1 kind: PerconaServerMongoDBBackup metadata: name: backup1 spec: psmdbCluster: my-cluster-name storageName: s3-us-west EOF
Following steps are needed to restore a previously saved backup:
First of all make sure that the cluster is running.
Now find out correct names for the backup and the cluster. Available backups can be listed with the following command:
kubectl get psmdb-backup
And the following command will list available clusters:
kubectl get psmdb
When both correct names are known, run the actual restoration process:
kubectl apply -f deploy/backup/restore.yaml
Storing backup settings in a separate file can be replaced by passing its content to the
kubectl applycommand as follows:
cat <<EOF | kubectl apply -f- apiVersion: psmdb.percona.com/v1 kind: PerconaServerMongoDBRestore metadata: name: restore1 spec: clusterName: my-cluster-name backupName: backup1 EOF
Deleting a previously saved backup requires not more than the backup name. This name can be taken from the list of available backups returned by the following command:
kubectl get psmdb-backup
When the name is known, backup can be deleted as follows:
kubectl delete psmdb-backup/<backup-name>