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.
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, shows an example on how to configure an rclone backend using environment variables:
apiVersion: tungsten.continuent.com/v1alpha1
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:
backend: sample-rclone-backend
backendConfigurations:
- name: sample-rclone-backend
type: rclone
rclone:
type: mysqldump
destination:
bucket: "backups"
directory: "test"
flags:
purgeRemoteBackupOnDeletion: true
overwriteExistingPhysicalResource: false
env:
- name: RCLONE_CONFIG_REMOTE_TYPE
value: s3
- name: RCLONE_CONFIG_REMOTE_ENDPOINT
value: "http://minio.default.svc.cluster.local"
- 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 effect
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.
Using the example above, you would then apply this to the cluster as follows:
shell> kubectl apply -f tungsten_v1alpha1_backupconfiguration.yaml