KubeDB
Run Production-Grade Databases on Kubernetes
arrow_forward
Stash
Backup and Recovery Solution for Kubernetes
arrow_forward
KubeVault
Run Production-Grade Vault on Kubernetes
arrow_forward
Voyager
Secure Ingress Controller for Kubernetes
arrow_forward
ConfigSyncer
Kubernetes Configuration Syncer
arrow_forward
Guard
Kubernetes Authentication WebHook Server
arrow_forward
KubeDB simplifies Provisioning, Upgrading, Scaling, Volume Expansion, Monitor, Backup, Restore for various Databases in Kubernetes on any Public & Private Cloud
- task_altLower administrative burden
- task_altNative Kubernetes Support
- task_altPerformance
- task_altAvailability and durability
- task_altManageability
- task_altCost-effectiveness
- task_altSecurity
A complete Kubernetes native disaster recovery solution for backup and restore your volumes and databases in Kubernetes on any public and private clouds.
- task_altDeclarative API
- task_altBackup Kubernetes Volumes
- task_altBackup Database
- task_altMultiple Storage Support
- task_altDeduplication
- task_altData Encryption
- task_altVolume Snapshot
- task_altPolicy Based Backup
KubeVault is a Git-Ops ready, production-grade solution for deploying and configuring Hashicorp's Vault on Kubernetes.
- task_altVault Kubernetes Deployment
- task_altAuto Initialization & Unsealing
- task_altVault Backup & Restore
- task_altConsume KubeVault Secrets with CSI
- task_altManage DB Users Privileges
- task_altStorage Backend
- task_altAuthentication Method
- task_altDatabase Secret Engine
Secure Ingress Controller for Kubernetes
- task_altHTTP & TCP
- task_altSSL
- task_altPlatform support
- task_altHAProxy
- task_altPrometheus
- task_altLet's Encrypt
Kubernetes Configuration Syncer
- task_altConfiguration Syncer
Kubernetes Authentication WebHook Server
- task_altIdentity Providers
- task_altCLI
- task_altRBAC
RESOURCES
Blog
Docs
Webinars
Learn
Demos
RECENT NEWS/BLOG
See More arrow_forward
Webinar New

You are looking at the documentation of a prior release. To read the documentation of the latest release, please visit here.

Backup MySQL using Stash Auto-Backup

Stash can be configured to automatically backup any MySQL database in your cluster. Stash enables cluster administrators to deploy backup blueprints ahead of time so that the database owners can easily backup their database with just a few annotations.

In this tutorial, we are going to show how you can configure a backup blueprint for MySQL databases in your cluster and backup them with few annotations.

Before You Begin

At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.
Install Stash Enterprise in your cluster following the steps here.
Install KubeDB in your cluster following the steps here.
If you are not familiar with how Stash backup and restore MySQL databases, please check the following guide here.
If you are not familiar with how auto-backup works in Stash, please check the following guide here.
If you are not familiar with the available auto-backup options for databases in Stash, please check the following guide here.

You should be familiar with the following Stash concepts:

In this tutorial, we are going to show backup of three different MySQL databases on three different namespaces named demo, demo-2, and demo-3. Create the namespaces as below if you haven’t done it already.

❯ kubectl create ns demo
namespace/demo created

❯ kubectl create ns demo-2
namespace/demo-2 created

❯ kubectl create ns demo-3
namespace/demo-3 created

When you install the Stash Enterprise edition, it automatically installs all the official database addons. Verify that it has installed the MySQL addons using the following command.

❯ kubectl get tasks.stash.appscode.com | grep mysql
mysql-backup-5.7.25            2d2h
mysql-backup-8.0.14            2d2h
mysql-backup-8.0.21            2d2h
mysql-backup-8.0.3             2d2h
mysql-restore-5.7.25           2d2h
mysql-restore-8.0.14           2d2h
mysql-restore-8.0.21           2d2h
mysql-restore-8.0.3            2d2h

Prepare Backup Blueprint

To backup an MySQL database using Stash, you have to create a Secret containing the backend credentials, a Repository containing the backend information, and a BackupConfiguration containing the schedule and target information. A BackupBlueprint allows you to specify a template for the Repository and the BackupConfiguration.

The BackupBlueprint is a non-namespaced CRD. So, once you have created a BackupBlueprint, you can use it to backup any MySQL database of any namespace just by creating the storage Secret in that namespace and adding few annotations to your MySQL CRO. Then, Stash will automatically create a Repository and a BackupConfiguration according to the template to backup the database.

Below is the BackupBlueprint object that we are going to use in this tutorial,

apiVersion: stash.appscode.com/v1beta1
kind: BackupBlueprint
metadata:
  name: mysql-backup-template
spec:
  # ============== Blueprint for Repository ==========================
  backend:
    gcs:
      bucket: stash-testing
      prefix: mysql-backup/${TARGET_NAMESPACE}/${TARGET_APP_RESOURCE}/${TARGET_NAME}
    storageSecretName: gcs-secret
  # ============== Blueprint for BackupConfiguration =================
  schedule: "*/5 * * * *"
  retentionPolicy:
    name: 'keep-last-5'
    keepLast: 5
    prune: true

Here, we are using a GCS bucket as our backend. We are providing gcs-secret at the storageSecretName field. Hence, we have to create a secret named gcs-secret with the access credentials of our bucket in every namespace where we want to enable backup through this blueprint.

Notice the prefix field of backend section. We have used some variables in form of ${VARIABLE_NAME}. Stash will automatically resolve those variables from the database information to make the backend prefix unique for each database instance.

Let’s create the BackupBlueprint we have shown above,

❯ kubectl apply -f https://github.com/kubedb/docs/raw/v2022.03.28/docs/guides/mysql/backup/auto-backup/examples/backupblueprint.yaml
backupblueprint.stash.appscode.com/mysql-backup-template created

Now, we are ready to backup our MySQL databases using few annotations. You can check available auto-backup annotations for a databases from here.

Auto-backup with default configurations

In this section, we are going to backup an MySQL database of demo namespace. We are going to use the default configurations specified in the BackupBlueprint.

Create Storage Secret

At first, let’s create the gcs-secret in demo namespace with the access credentials to our GCS bucket.

❯ echo -n 'changeit' > RESTIC_PASSWORD
❯ echo -n '<your-project-id>' > GOOGLE_PROJECT_ID
❯ cat downloaded-sa-key.json > GOOGLE_SERVICE_ACCOUNT_JSON_KEY
❯ kubectl create secret generic -n demo gcs-secret \
    --from-file=./RESTIC_PASSWORD \
    --from-file=./GOOGLE_PROJECT_ID \
    --from-file=./GOOGLE_SERVICE_ACCOUNT_JSON_KEY
secret/gcs-secret created

Create Database

Now, we are going to create an MySQL CRO in demo namespace. Below is the YAML of the MySQL object that we are going to create,

apiVersion: kubedb.com/v1alpha2
kind: MySQL
metadata:
  name: sample-mysql
  namespace: demo
  annotations:
    stash.appscode.com/backup-blueprint: mysql-backup-template
spec:
  version: "8.0.27"
  replicas: 1
  storageType: Durable
  storage:
    storageClassName: "standard"
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 50Mi
  terminationPolicy: WipeOut

Notice the annotations section. We are pointing to the BackupBlueprint that we have created earlier though stash.appscode.com/backup-blueprint annotation. Stash will watch this annotation and create a Repository and a BackupConfiguration according to the BackupBlueprint.

Let’s create the above MySQL CRO,

❯ kubectl apply -f https://github.com/kubedb/docs/raw/v2022.03.28/docs/guides/mysql/backup/auto-backup/examples/sample-mysql.yaml
mysql.kubedb.com/sample-mysql created

Verify Auto-backup configured

In this section, we are going to verify whether Stash has created the respective Repository and BackupConfiguration for our MySQL database we have just deployed or not.

Verify Repository

At first, let’s verify whether Stash has created a Repository for our MySQL or not.

❯ kubectl get repository -n demo
NAME                 INTEGRITY   SIZE   SNAPSHOT-COUNT   LAST-SUCCESSFUL-BACKUP   AGE
app-sample-mysql                                                                  10s

Now, let’s check the YAML of the Repository.

❯ kubectl get repository -n demo app-sample-mysql -o yaml
apiVersion: stash.appscode.com/v1alpha1
kind: Repository
metadata:
  creationTimestamp: "2022-02-03T09:10:24Z"
  finalizers:
  - stash
  generation: 1
  name: app-sample-mysql
  namespace: demo
  resourceVersion: "363862"
  uid: 23781855-6cd9-4ef8-84d4-c6360a88bbef
spec:
  backend:
    gcs:
      bucket: stash-testing
      prefix: mysql-backup/demo/mysql/sample-mysql
    storageSecretName: gcs-secret

Here, you can see that Stash has resolved the variables in prefix field and substituted them with the equivalent information from this database.

Verify BackupConfiguration

If everything goes well, Stash should create a BackupConfiguration for our MySQL in demo namespace and the phase of that BackupConfiguration should be Ready. Verify the BackupConfiguration crd by the following command,

❯ kubectl get backupconfiguration -n demo
NAMESPACE   NAME               TASK   SCHEDULE      PAUSED   PHASE   AGE
demo        app-sample-mysql          */5 * * * *            Ready   3m56s

Now, let’s check the YAML of the BackupConfiguration.

❯ kubectl get backupconfiguration -n demo app-sample-mysql -o yaml
apiVersion: stash.appscode.com/v1beta1
kind: BackupConfiguration
metadata:
  creationTimestamp: "2022-02-03T09:10:24Z"
  finalizers:
  - stash.appscode.com
  generation: 1
  name: app-sample-mysql
  namespace: demo
  ownerReferences:
  - apiVersion: appcatalog.appscode.com/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: AppBinding
    name: sample-mysql
    uid: 02bacaf0-9f3c-4b48-84d4-305a7d854eb2
  resourceVersion: "363877"
  uid: d101e8fc-4507-42cc-93f7-782f29d8898d
spec:
  driver: Restic
  repository:
    name: app-sample-mysql
  retentionPolicy:
    keepLast: 5
    name: keep-last-5
    prune: true
  runtimeSettings: {}
  schedule: '*/5 * * * *'
  target:
    ref:
      apiVersion: appcatalog.appscode.com/v1alpha1
      kind: AppBinding
      name: sample-mysql
  task: {}
  tempDir: {}
status:
  conditions:
  - lastTransitionTime: "2022-02-03T09:10:24Z"
    message: Repository demo/app-sample-mysql exist.
    reason: RepositoryAvailable
    status: "True"
    type: RepositoryFound
  - lastTransitionTime: "2022-02-03T09:10:24Z"
    message: Backend Secret demo/gcs-secret exist.
    reason: BackendSecretAvailable
    status: "True"
    type: BackendSecretFound
  - lastTransitionTime: "2022-02-03T09:10:24Z"
    message: Backup target appcatalog.appscode.com/v1alpha1 appbinding/sample-mysql
      found.
    reason: TargetAvailable
    status: "True"
    type: BackupTargetFound
  - lastTransitionTime: "2022-02-03T09:10:24Z"
    message: Successfully created backup triggering CronJob.
    reason: CronJobCreationSucceeded
    status: "True"
    type: CronJobCreated
  observedGeneration: 1

Notice the target section. Stash has automatically added the MySQL as the target of this BackupConfiguration.

Verify Backup

Now, let’s wait for a backup run to complete. You can watch for BackupSession as below,

❯ kubectl get backupsession -n demo -w
NAME                          INVOKER-TYPE          INVOKER-NAME       PHASE     DURATION   AGE
app-sample-mysql-1643879707   BackupConfiguration   app-sample-mysql   Running              40s

Once the backup has been completed successfully, you should see the backed up data has been stored in the bucket at the directory pointed by the prefix field of the Repository.

Auto-backup with a custom schedule

In this section, we are going to backup an MySQL database of demo-2 namespace. This time, we are going to overwrite the default schedule used in the BackupBlueprint.

Create Storage Secret

At first, let’s create the gcs-secret in demo-2 namespace with the access credentials to our GCS bucket.

❯ kubectl create secret generic -n demo-2 gcs-secret \
    --from-file=./RESTIC_PASSWORD \
    --from-file=./GOOGLE_PROJECT_ID \
    --from-file=./GOOGLE_SERVICE_ACCOUNT_JSON_KEY
secret/gcs-secret created

Create Database

Now, we are going to create an MySQL CRO in demo-2 namespace. Below is the YAML of the MySQL object that we are going to create,

apiVersion: kubedb.com/v1alpha2
kind: MySQL
metadata:
  name: sample-mysql-2
  namespace: demo-2
  annotations:
    stash.appscode.com/backup-blueprint: mysql-backup-template
    stash.appscode.com/schedule: "*/3 * * * *"
spec:
  version: "8.0.27"
  replicas: 1
  storageType: Durable
  storage:
    storageClassName: "standard"
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 50Mi
  terminationPolicy: WipeOut

Notice the annotations section. This time, we have passed a schedule via stash.appscode.com/schedule annotation along with the stash.appscode.com/backup-blueprint annotation.

Let’s create the above MySQL CRO,

❯ kubectl apply -f https://github.com/kubedb/docs/raw/v2022.03.28/docs/guides/mysql/backup/auto-backup/examples/sample-mysql-2.yaml
mysql.kubedb.com/sample-mysql-2 created

Verify Auto-backup configured

Now, let’s verify whether the auto-backup has been configured properly or not.

Verify Repository

At first, let’s verify whether Stash has created a Repository for our MySQL or not.

❯ kubectl get repository -n demo-2
NAME                   INTEGRITY   SIZE   SNAPSHOT-COUNT   LAST-SUCCESSFUL-BACKUP   AGE
app-sample-myaql-2                                                                  4s

Now, let’s check the YAML of the Repository.

❯ kubectl get repository -n demo-2 app-sample-mysql-2  -o yaml
apiVersion: stash.appscode.com/v1alpha1
kind: Repository
metadata:
  creationTimestamp: "2022-02-03T09:26:15Z"
  finalizers:
  - stash
  generation: 1
  name: app-sample-mysql-2
  namespace: demo-2
  resourceVersion: "365836"
  uid: f37e737c-c5f1-4620-9c22-1d7b14127eab
spec:
  backend:
    gcs:
      bucket: stash-testing
      prefix: mysql-backup/demo/mysql/sample-mysql-2
    storageSecretName: gcs-secret

Here, you can see that Stash has resolved the variables in prefix field and substituted them with the equivalent information from this new database.

Verify BackupConfiguration

If everything goes well, Stash should create a BackupConfiguration for our MySQL in demo-2 namespace and the phase of that BackupConfiguration should be Ready. Verify the BackupConfiguration crd by the following command,

❯ kubectl get backupconfiguration -n demo-2
NAMESPACE   NAME                 TASK   SCHEDULE      PAUSED   PHASE   AGE
demo-2      app-sample-mysql-2          */3 * * * *            Ready   113s

Now, let’s check the YAML of the BackupConfiguration.

❯ kubectl get backupconfiguration -n demo-2 app-sample-mysql-2 -o yaml

apiVersion: stash.appscode.com/v1beta1
kind: BackupConfiguration
metadata:
  creationTimestamp: "2022-02-03T09:30:35Z"
  finalizers:
  - stash.appscode.com
  generation: 1
  name: app-sample-mysql-2
  namespace: demo-2
  ownerReferences:
  - apiVersion: appcatalog.appscode.com/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: AppBinding
    name: sample-mysql-2
    uid: 478d802c-585b-408b-9fbe-b2f90d55b26e
  resourceVersion: "366551"
  uid: de8448a1-0e8c-41b5-a1c4-07239ae0fef2
spec:
  driver: Restic
  repository:
    name: app-sample-mysql-2
  retentionPolicy:
    keepLast: 5
    name: keep-last-5
    prune: true
  runtimeSettings: {}
  schedule: '*/3 * * * *'
  target:
    ref:
      apiVersion: appcatalog.appscode.com/v1alpha1
      kind: AppBinding
      name: sample-mysql-2
  task: {}
  tempDir: {}
status:
  conditions:
  - lastTransitionTime: "2022-02-03T09:30:35Z"
    message: Repository demo-2/app-sample-mysql-2 exist.
    reason: RepositoryAvailable
    status: "True"
    type: RepositoryFound
  - lastTransitionTime: "2022-02-03T09:30:35Z"
    message: Backend Secret demo-2/gcs-secret exist.
    reason: BackendSecretAvailable
    status: "True"
    type: BackendSecretFound
  - lastTransitionTime: "2022-02-03T09:30:35Z"
    message: Backup target appcatalog.appscode.com/v1alpha1 appbinding/sample-mysql-2
      found.
    reason: TargetAvailable
    status: "True"
    type: BackupTargetFound
  - lastTransitionTime: "2022-02-03T09:30:35Z"
    message: Successfully created backup triggering CronJob.
    reason: CronJobCreationSucceeded
    status: "True"
    type: CronJobCreated
  observedGeneration: 1

Notice the schedule section. This time the BackupConfiguration has been created with the schedule we have provided via annotation.

Also, notice the target section. Stash has automatically added the new MySQL as the target of this BackupConfiguration.

Verify Backup

Now, let’s wait for a backup run to complete. You can watch for BackupSession as below,

❯ kubectl get backupsession -n demo-2 -w
NAMESPACE   NAME                            INVOKER-TYPE          INVOKER-NAME         PHASE       DURATION   AGE
demo-2      app-sample-mysql-2-1643880964   BackupConfiguration   app-sample-mysql-2   Succeeded   35s        108s

Once the backup has been completed successfully, you should see that Stash has created a new directory as pointed by the prefix field of the new Repository and stored the backed up data there.

Auto-backup with custom parameters

In this section, we are going to backup an MySQL database of demo-3 namespace. This time, we are going to pass some parameters for the Task through the annotations.

Create Storage Secret

At first, let’s create the gcs-secret in demo-3 namespace with the access credentials to our GCS bucket.

❯ kubectl create secret generic -n demo-3 gcs-secret \
    --from-file=./RESTIC_PASSWORD \
    --from-file=./GOOGLE_PROJECT_ID \
    --from-file=./GOOGLE_SERVICE_ACCOUNT_JSON_KEY
secret/gcs-secret created

Create Database

Now, we are going to create an MySQL CRO in demo-3 namespace. Below is the YAML of the MySQL object that we are going to create,

apiVersion: kubedb.com/v1alpha2
kind: MySQL
metadata:
  name: sample-mysql-3
  namespace: demo-3
  annotations:
    stash.appscode.com/backup-blueprint: mysql-backup-template
    params.stash.appscode.com/args: --databases mysql
spec:
  version: "8.0.27"
  replicas: 1
  storageType: Durable
  storage:
    storageClassName: "standard"
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 50Mi
  terminationPolicy: WipeOut

Notice the annotations section. This time, we have passed an argument via params.stash.appscode.com/args annotation along with the stash.appscode.com/backup-blueprint annotation.

Let’s create the above MySQL CRO,

❯ kubectl apply -f https://github.com/kubedb/docs/raw/v2022.03.28/docs/guides/mysql/backup/auto-backup/examples/sample-mysql-3.yaml
mysql.kubedb.com/sample-mysql-3 created

Verify Auto-backup configured

Now, let’s verify whether the auto-backup resources has been created or not.

Verify Repository

At first, let’s verify whether Stash has created a Repository for our MySQL or not.

❯ kubectl get repository -n demo-3
NAME                 INTEGRITY   SIZE   SNAPSHOT-COUNT   LAST-SUCCESSFUL-BACKUP   AGE
app-sample-mysql-3                                                                5s                                                          8s

Now, let’s check the YAML of the Repository.

❯ kubectl get repository -n demo-3 app-sample-mysql-3 -o yaml
apiVersion: stash.appscode.com/v1alpha1
kind: Repository
metadata:
  creationTimestamp: "2022-02-03T10:10:13Z"
  finalizers:
  - stash
  generation: 1
  name: app-sample-mysql-3
  namespace: demo-3
  resourceVersion: "371009"
  uid: 244f30d0-cc1e-4d8a-8b76-fcca702783d6
spec:
  backend:
    gcs:
      bucket: stash-testing
      prefix: mysql-backup/demo-3/mysql/sample-mysql-3
    storageSecretName: gcs-secret

Here, you can see that Stash has resolved the variables in prefix field and substituted them with the equivalent information from this new database.

Verify BackupConfiguration

❯ kubectl get backupconfiguration -n demo-3
NAMESPACE   NAME                 TASK   SCHEDULE      PAUSED   PHASE   AGE
demo-3      app-sample-mysql-3          */5 * * * *            Ready   107s

Now, let’s check the YAML of the BackupConfiguration.

❯ kubectl get backupconfiguration -n demo-3 app-sample-mysql-3 -o yaml
apiVersion: stash.appscode.com/v1beta1
kind: BackupConfiguration
metadata:
  creationTimestamp: "2022-02-03T10:10:13Z"
  finalizers:
  - stash.appscode.com
  generation: 1
  name: app-sample-mysql-3
  namespace: demo-3
  ownerReferences:
  - apiVersion: appcatalog.appscode.com/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: AppBinding
    name: sample-mysql-3
    uid: 3a0682ef-62a5-4acf-adee-fc48f80a0ef7
  resourceVersion: "371026"
  uid: 444901df-64de-44e8-b592-d4b26dfe00de
spec:
  driver: Restic
  repository:
    name: app-sample-mysql-3
  retentionPolicy:
    keepLast: 5
    name: keep-last-5
    prune: true
  runtimeSettings: {}
  schedule: '*/5 * * * *'
  target:
    ref:
      apiVersion: appcatalog.appscode.com/v1alpha1
      kind: AppBinding
      name: sample-mysql-3
  task:
    params:
    - name: args
      value: --databases mysql
  tempDir: {}
status:
  conditions:
  - lastTransitionTime: "2022-02-03T10:10:13Z"
    message: Repository demo-3/app-sample-mysql-3 exist.
    reason: RepositoryAvailable
    status: "True"
    type: RepositoryFound
  - lastTransitionTime: "2022-02-03T10:10:13Z"
    message: Backend Secret demo-3/gcs-secret exist.
    reason: BackendSecretAvailable
    status: "True"
    type: BackendSecretFound
  - lastTransitionTime: "2022-02-03T10:10:13Z"
    message: Backup target appcatalog.appscode.com/v1alpha1 appbinding/sample-mysql-3
      found.
    reason: TargetAvailable
    status: "True"
    type: BackupTargetFound
  - lastTransitionTime: "2022-02-03T10:10:14Z"
    message: Successfully created backup triggering CronJob.
    reason: CronJobCreationSucceeded
    status: "True"
    type: CronJobCreated
  observedGeneration: 1

Notice the task section. The args parameter that we had passed via annotations has been added to the params section.

Also, notice the target section. Stash has automatically added the new MySQL as the target of this BackupConfiguration.

Verify Backup

Now, let’s wait for a backup run to complete. You can watch for BackupSession as below,

❯ kubectl get backupsession -n demo-3 -w
NAMESPACE   NAME                            INVOKER-TYPE          INVOKER-NAME         PHASE       DURATION   AGE
demo-3      app-sample-mysql-3-1643883304   BackupConfiguration   app-sample-mysql-3   Succeeded   41s        78s

Once the backup has been completed successfully, you should see that Stash has created a new directory as pointed by the prefix field of the new Repository and stored the backed up data there.

Cleanup

To cleanup the resources crated by this tutorial, run the following commands,

❯ kubectl delete -f https://github.com/kubedb/docs/raw/v2022.03.28/docs/guides/mysql/backup/auto-backup/examples/
backupblueprint.stash.appscode.com "mysql-backup-template" deleted
mysql.kubedb.com "sample-mysql-2" deleted
mysql.kubedb.com "sample-mysql-3" deleted
mysql.kubedb.com "sample-mysql" deleted

❯ kubectl delete repository -n demo --all
repository.stash.appscode.com "app-sample-mysql" deleted
❯ kubectl delete repository -n demo-2 --all
repository.stash.appscode.com "app-sample-mysql-2" deleted
❯ kubectl delete repository -n demo-3 --all
repository.stash.appscode.com "app-sample-mysql-3" deleted

Improve This Page

KubeDB

Stash

KubeVault

Voyager

ConfigSyncer

Guard

RESOURCES

RECENT NEWS/BLOG

Elasticsearch

Kafka

MariaDB

Memcached

MongoDB

MySQL

OpenSearch

Percona XtraDB

PgBouncer

PostgreSQL

ProxySQL

Redis

Elasticsearch

MariaDB

Memcached

MongoDB

MySQL

Percona XtraDB

PgBouncer

PostgreSQL

ProxySQL

Redis

KubeDB Operator

KubeDB Webhook Server

KubeDB CLI

Backup MySQL using Stash Auto-Backup

Before You Begin

Prepare Backup Blueprint

Auto-backup with default configurations

Create Storage Secret

Create Database

Verify Auto-backup configured

Verify Repository

Verify BackupConfiguration

Verify Backup

Auto-backup with a custom schedule

Create Storage Secret

Create Database

Verify Auto-backup configured

Verify Repository

Verify BackupConfiguration

Verify Backup

Auto-backup with custom parameters

Create Storage Secret

Create Database

Verify Auto-backup configured

Verify Repository

Verify BackupConfiguration

Verify Backup

Cleanup

What's on this Page

Search