Making scheduled backups

Since backups are stored separately on the Amazon S3, a secret with AWS_ACCESS_KEY_ID and 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 contents.

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 name value is the Kubernetes secret name which will be used further, and AWS_ACCESS_KEY_ID 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, 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:

• storages contains data needed to access the S3-compatible cloud to store backups.
• tasks subsection 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:

endpointUrl: https://storage.googleapis.com

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 secret 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 example).

The schedule is specified in crontab format as explained in Operator Custom Resource options.

Making on-demand backup

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.

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

Restore the cluster from a previously saved backup

Following steps are needed to restore a previously saved backup:

1. First of all make sure that the cluster is running.

2. 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
   

3. When both correct names are known, run the actual restoration process:

   kubectl apply -f deploy/backup/restore.yaml
   

   Note

   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: PerconaServerMongoDBRestore
   metadata:
     name: restore1
   spec:
     clusterName: my-cluster-name
     backupName: backup1
   EOF
   

Delete the unneeded backup

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>