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,
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 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.
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-ecoded
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.yamlshell>kubectl apply -f examples/tungsten_v1_backupconfiguration.yaml