Configuring Backups

The backup functionality in Tungsten Operator is managed through two main resources: TungstenBackup and BackupConfiguration.

Two sample yaml files are provided that allow you to configure and schedule backups, these are tungsten_v1alpha1_backupconfiguration.yaml and tungsten_v1alpha1_mysqlcluster_with_backup.yaml.

TungstenBackup is a custom resource that represents a single backup operation. It includes details such as the source cluster, plus the status and size of the backup. Once a TungstenBackup resource is created, the backup process is initiated.

BackupConfiguration is another custom resource that defines the configuration for backups. It includes details such as backup policies and storage destination and backend configuration.

Configuring backup backends

To build the BackupConfiguration, the example yaml file tungsten_v1alpha1_backupconfiguration.yaml can be used.

BackupConfiguration contains an array of backendConfigurations. Multiple backends can be configured, but only one will be active for new backups at any given moment. This allows the user to switch backends, while supporting restoration and rotation of TungstenBackup that were created on a previous backend.

Currently the only supported backend uploader type is rclone. rclone itself supports all major object storage destinations.

The sample yaml file, examples/tungsten_v1_backupconfiguration.yaml, shows an example configuration file for an rclone backend using environment variables:

apiVersion: tungsten.continuent.com/v1
kind: BackupConfiguration
metadata:
  labels:
    app.kubernetes.io/name: backupconfiguration
    app.kubernetes.io/instance: backupconfiguration-sample
    app.kubernetes.io/part-of: tungsten-operator
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: tungsten-operator
  name: backupconfiguration-sample
spec:
  defaultBackend: sample-rclone-backend
  backendConfigurations:
  - name: sample-rclone-backend
    type: rclone
    rclone:
      destination:
        bucket: "demo-backup-k8s"
        directory: "test"
      flags:
        purgeRemoteBackupOnDeletion: false
        overwriteExistingPhysicalResource: false
      env:
        - name: RCLONE_CONFIG_REMOTE_TYPE
          value: s3
        - name: RCLONE_CONFIG_REMOTE_PROVIDER
          value: "AWS"
        - name: RCLONE_CONFIG_REMOTE_REGION
          value: "us-east-1"  # Specify your region
        - name: RCLONE_CONFIG_REMOTE_ACCESS_KEY_ID
          valueFrom:
            secretKeyRef:
              name: backups-user-1
              key: CONSOLE_ACCESS_KEY
        - name: RCLONE_CONFIG_REMOTE_SECRET_ACCESS_KEY
          valueFrom:
            secretKeyRef:
              name: backups-user-1
              key: CONSOLE_SECRET_KEY

The type defines the method of backup, Currently this can be set to either mysqldump or xtrabackup.

The destination block determines which backend from backendConfigurations will be used for all new backups.

The flags field includes several options that affect behaviour of backups:

• purgeRemoteBackupOnDeletion: This boolean field determines whether the remote physical backup file should be deleted when the TungstenBackup resource is deleted. If set to true, the remote backup will be deleted upon deletion of the TungstenBackup resource. As alternative, life cycle rules of the object storage backend can be used to ensure desired backup retention and rotation, and the Tungsten Operator can be configured to only upload backup artifacts.
• overwriteExistingPhysicalResource: This boolean field determines whether an existing physical resource should be overwritten during the backup process. If set to true, the backup process will overwrite any existing physical resource with the same name. This should be usually set to false.

When making major changes to the backend, such as changing the type or endpoint, it might be better to introduce a new backend instead, if you are not planning to copy old data between storage destinations. This way new instances of TungstenBackups can use the latest backend, while old backups still stay on the old backend.

A user credentials file must also be created, for example examples/backups-user-1-secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: backups-user-1
type: Opaque
data:
  CONSOLE_ACCESS_KEY: {Insert base64-encode AWS_ACCESS_KEY here - see below}
  CONSOLE_SECRET_KEY: {Insert base64-encode AWS_SECRET_KEY here - see below}

To populate the CONSOLE_ACCESS_KEY: and CONSOLE_SECRET_KEY: fields, use the base64-encoded values of the AWS Access and Secret keys:

shell> echo -n "$AWS_ACCESS_KEY" | base64
shell> echo -n "$AWS_SECRET_KEY" | base64

Using the example above, you would then apply this to the cluster as follows:

shell> kubectl apply -f examples/backups-user-1-secret.yaml
shell> kubectl apply -f examples/tungsten_v1_backupconfiguration.yaml

Running a Manual Backup

To execute a manual backup, first ensure that there is a configuration file to apply, i.e. tungsten_v1_backup.yaml:

apiVersion: tungsten.continuent.com/v1
kind: Backup
metadata:
  labels:
    app.kubernetes.io/name: backup
    app.kubernetes.io/instance: backup-sample
    app.kubernetes.io/part-of: tungsten-operator
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: tungsten-operator
  name: backup-sample-new
spec:
  clusterRef:
    name: sample-with-backup

To invoke the backup manually, execute the kubectl apply:

shell> kubectl apply -f tungsten_v1_backup.yaml

Scheduling the backup

The backup configuration and schedule is defined via the MySQLCluster resource's backups field. The schedule is specified in cron format and determines how frequently TungstenBackup resources are created and thus, how frequently backups are taken. If retention is specified, then successful TungstenBackup resources are deleted when count exceeds the value in keep.

An example yaml file is available in the examples directory called tungsten_v1alpha1_mysqlcluster_with_backup.yaml and the specific backup properties are shown below:

...
spec:
  configuration:
    customPasswordSecret: tungsten-passwords-sample-secret
  backup:
    configurationRef:
      name: tungstenbackupconfiguration-sample
    schedule: "15 2 * * *"
    keep: 5
...

The crontab entry 15 2 * * * would run the backup every day at 02:15am.

The name refers to the name given in the BackupConfiguration

The lifecycle of a backup operation can be tracked through the TungstenBackup resource's status field. The possible states are Pending, Processing, Succeeded, and Failed.