From 28b7102ef599a5d54f98f83b49edeaa292d81573 Mon Sep 17 00:00:00 2001 From: SK Ali Arman Date: Wed, 18 Sep 2024 18:05:11 +0600 Subject: [PATCH] refactor Signed-off-by: SK Ali Arman --- docs/guides/mariadb/backup/_index.md | 2 +- .../kubestash/application-level/index.md | 12 ++++++------ .../backup/kubestash/auto-backup/index.md | 14 +++++++------- .../backup/kubestash/customization/index.md | 3 ++- .../mariadb/backup/kubestash/logical/index.md | 19 +++++++++---------- docs/guides/mariadb/backup/stash/_index.md | 10 ++++++++++ .../mariadb/backup/stash/auto-backup/index.md | 4 ++-- .../backup/stash/customization/index.md | 4 ++-- .../mariadb/backup/stash/logical/_index.md | 4 ++-- .../backup/stash/logical/cluster/index.md | 4 ++-- .../backup/stash/logical/standalone/index.md | 4 ++-- .../mariadb/backup/stash/overview/index.md | 4 ++-- 12 files changed, 47 insertions(+), 37 deletions(-) create mode 100644 docs/guides/mariadb/backup/stash/_index.md diff --git a/docs/guides/mariadb/backup/_index.md b/docs/guides/mariadb/backup/_index.md index ca40ea577..448fec76a 100644 --- a/docs/guides/mariadb/backup/_index.md +++ b/docs/guides/mariadb/backup/_index.md @@ -2,7 +2,7 @@ title: Backup & Restore MariaDB menu: docs_{{ .version }}: - identifier: guides-mariadb-backup-stash + identifier: guides-mariadb-backup name: Backup & Restore parent: guides-mariadb weight: 70 diff --git a/docs/guides/mariadb/backup/kubestash/application-level/index.md b/docs/guides/mariadb/backup/kubestash/application-level/index.md index 93353ad37..65df2863d 100644 --- a/docs/guides/mariadb/backup/kubestash/application-level/index.md +++ b/docs/guides/mariadb/backup/kubestash/application-level/index.md @@ -46,7 +46,7 @@ namespace/demo created ## Backup MariaDB -KubeStash supports backups for `MariaDB` instances across different configurations, including Standalone and HA Cluster setups. In this demonstration, we'll focus on a `MariaDB` database using HA cluster configuration. The backup and restore process is similar for Standalone configuration. +KubeStash supports backups for `MariaDB` instances across different configurations, including Standalone and Galera Cluster setups. In this demonstration, we'll focus on a `MariaDB` database using Galera cluster configuration. The backup and restore process is similar for Standalone configuration. This section will demonstrate how to take application-level backup of a `MariaDB` database. Here, we are going to deploy a `MariaDB` database using KubeDB. Then, we are going to back up the database at the application level to a `GCS` bucket. Finally, we will restore the entire `MariaDB` database. @@ -248,7 +248,7 @@ Now, we are ready to backup the database. ### Prepare Backend -We are going to store our backed up data into a `GCS` bucket. We have to create a `Secret` with necessary credentials and a `BackupStorage` CR to use this backend. If you want to use a different backend, please read the respective backend configuration doc from [here](https://kubestash.com/docs/latest/guides/backends/overview/). +We are going to store our backup data into a `GCS` bucket. We have to create a `Secret` with necessary credentials and a `BackupStorage` CR to use this backend. If you want to use a different backend, please read the respective backend configuration doc from [here](https://kubestash.com/docs/latest/guides/backends/overview/). **Create Secret:** @@ -441,7 +441,7 @@ NAME INVOKER-TYPE INVOKE sample-mariadb-backup-frequent-backup-1726651003 BackupConfiguration sample-mariadb-backup Succeeded 7m22s ``` -We can see from the above output that the backup session has succeeded. Now, we are going to verify whether the backed up data has been stored in the backend. +We can see from the above output that the backup session has succeeded. Now, we are going to verify whether the backup data has been stored in the backend. **Verify Backup:** @@ -469,7 +469,7 @@ gcs-mariadb-repo-sample-mariadb-ckup-frequent-backup-1726651003 gcs-mariad > > These labels can be used to watch only the `Snapshot`s related to our target Database or `Repository`. -If we check the YAML of the `Snapshot`, we can find the information about the backed up components of the Database. +If we check the YAML of the `Snapshot`, we can find the information about the backup components of the Database. ```bash $ kubectl get snapshots -n demo gcs-mariadb-repo-sample-mariadb-backup-frequent-backup-1725449400 -oyaml @@ -561,7 +561,7 @@ status: > KubeStash set component name as `manifest` for the `manifest backup` of MariaDB databases. -Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/mariadb/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/mariadb/snapshots` directory. +Now, if we navigate to the GCS bucket, we will see the backup data stored in the `demo/mariadb/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/mariadb/snapshots` directory. > Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. @@ -611,7 +611,7 @@ spec: Here, - `.spec.manifestOptions.mariadb.db` specifies whether to restore the DB manifest or not. -- `.spec.dataSource.repository` specifies the Repository object that holds the backed up data. +- `.spec.dataSource.repository` specifies the Repository object that holds the backup data. - `.spec.dataSource.snapshot` specifies to restore from latest `Snapshot`. - `.spec.addon.tasks[*]` specifies that both the `manifest-restore` and `logical-backup-restore` tasks. diff --git a/docs/guides/mariadb/backup/kubestash/auto-backup/index.md b/docs/guides/mariadb/backup/kubestash/auto-backup/index.md index 3848cf312..8ad8eb563 100644 --- a/docs/guides/mariadb/backup/kubestash/auto-backup/index.md +++ b/docs/guides/mariadb/backup/kubestash/auto-backup/index.md @@ -46,7 +46,7 @@ namespace/demo created ### Prepare Backend -We are going to store our backed up data into a `GCS` bucket. We have to create a `Secret` with necessary credentials and a `BackupStorage` CR to use this backend. If you want to use a different backend, please read the respective backend configuration doc from [here](https://kubestash.com/docs/latest/guides/backends/overview/). +We are going to store our backup data into a `GCS` bucket. We have to create a `Secret` with necessary credentials and a `BackupStorage` CR to use this backend. If you want to use a different backend, please read the respective backend configuration doc from [here](https://kubestash.com/docs/latest/guides/backends/overview/). **Create Secret:** @@ -366,7 +366,7 @@ $ kubectl get backupsession -n demo -w NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE appbinding-sample-mariadb-frequent-backup-1726637655 BackupConfiguration appbinding-sample-mariadb Succeeded 2m11s 3m15s ``` -We can see from the above output that the backup session has succeeded. Now, we are going to verify whether the backed up data has been stored in the backend. +We can see from the above output that the backup session has succeeded. Now, we are going to verify whether the backup data has been stored in the backend. **Verify Backup:** @@ -394,7 +394,7 @@ default-blueprint-appbinding-samiadb-frequent-backup-1726637655 default-bluepr > > These labels can be used to watch only the `Snapshot`s related to our target Database or `Repository`. -If we check the YAML of the `Snapshot`, we can find the information about the backed up components of the Database. +If we check the YAML of the `Snapshot`, we can find the information about the backup components of the Database. ```bash $ kubectl get snapshot.storage.kubestash.com -n demo default-blueprint-appbinding-samgres-frequent-backup-1725533628 -oyaml @@ -472,7 +472,7 @@ status: > KubeStash uses `mariadb-dump` to perform backups of target `MariaDB` databases. Therefore, the component name for logical backups is set as `dump`. -Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `blueprint/default-blueprint/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `blueprint/default-blueprint/snapshots` directory. +Now, if we navigate to the GCS bucket, we will see the backup data stored in the `blueprint/default-blueprint/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `blueprint/default-blueprint/snapshots` directory. > Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. @@ -717,7 +717,7 @@ NAME INVOKER-TYPE appbinding-sample-mariadb-2-frequent-backup-1726640601 BackupConfiguration appbinding-sample-mariadb-2 Succeeded 2m6s 10m ``` -We can see from the above output that the backup session has succeeded. Now, we are going to verify whether the backed up data has been stored in the backend. +We can see from the above output that the backup session has succeeded. Now, we are going to verify whether the backup data has been stored in the backend. **Verify Backup:** @@ -746,7 +746,7 @@ customize-blueprint-appbinding-sdb-2-frequent-backup-1726640601 customize-blue > > These labels can be used to watch only the `Snapshot`s related to our target Database or `Repository`. -If we check the YAML of the `Snapshot`, we can find the information about the backed up components of the Database. +If we check the YAML of the `Snapshot`, we can find the information about the backup components of the Database. ```bash $ kubectl get snapshot.storage.kubestash.com -n demo customize-blueprint-appbinding-sql-2-frequent-backup-1725597000 -oyaml @@ -824,7 +824,7 @@ status: > KubeStash uses `mariadb-dump` to perform backups of target `MariaDB` databases. Therefore, the component name for logical backups is set as `dump`. -Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `blueprint/demo/sample-mariadb-2/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `blueprint/demo/sample-mariadb-2/snapshots` directory. +Now, if we navigate to the GCS bucket, we will see the backup data stored in the `blueprint/demo/sample-mariadb-2/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `blueprint/demo/sample-mariadb-2/snapshots` directory. > Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. diff --git a/docs/guides/mariadb/backup/kubestash/customization/index.md b/docs/guides/mariadb/backup/kubestash/customization/index.md index 9e42ae418..bb0fca644 100644 --- a/docs/guides/mariadb/backup/kubestash/customization/index.md +++ b/docs/guides/mariadb/backup/kubestash/customization/index.md @@ -277,8 +277,9 @@ spec: ### Passing arguments to the restore process -You can pass any supported `psql` arguments to the restore process using the `args` field within the `addon.tasks[*].params` section. This example demonstrates how to specify a database `testdb` to connect to during the restore process. +Similar to the backup process, you can pass arguments to the restore process through the args params under addon.tasks[*].params section. +This example will restore data from database testdb only. ```yaml apiVersion: core.kubestash.com/v1alpha1 kind: RestoreSession diff --git a/docs/guides/mariadb/backup/kubestash/logical/index.md b/docs/guides/mariadb/backup/kubestash/logical/index.md index 325548c53..050f3873f 100644 --- a/docs/guides/mariadb/backup/kubestash/logical/index.md +++ b/docs/guides/mariadb/backup/kubestash/logical/index.md @@ -13,7 +13,7 @@ section_menu_id: guides # Backup and Restore MariaDB database using KubeStash -KubeStash allows you to backup and restore `MariaDB` databases. It supports backups for `MariaDB` instances running in Standalone, and HA cluster configurations. KubeStash makes managing your `MariaDB` backups and restorations more straightforward and efficient. +KubeStash allows you to backup and restore `MariaDB` databases. It supports backups for `MariaDB` instances running in Standalone, and Galera cluster configurations. KubeStash makes managing your `MariaDB` backups and restorations more straightforward and efficient. This guide will give you an overview how you can take backup and restore your `MariaDB` databases using `Kubestash`. @@ -106,8 +106,8 @@ sample-mariadb-auth kubernetes.io/basic-auth 2 5m49s $ kubectl get service -n demo -l=app.kubernetes.io/instance=sample-mariadb NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -sample-mariadb ClusterIP 10.128.7.155 3306/TCP 6m28s -sample-mariadb-pods ClusterIP None 3306/TCP 6m28s 5432/TCP 5m55s +sample-mariadb ClusterIP 10.128.7.155 3306/TCP 6m28s +sample-mariadb-pods ClusterIP None 3306/TCP 6m28s ``` Here, we have to use service `sample-mariadb` and secret `sample-mariadb-auth` to connect with the database. `KubeDB` creates an [AppBinding](/docs/guides/mariadb/concepts/appbinding/index.md) CR that holds the necessary information to connect with the database. @@ -248,7 +248,7 @@ Now, we are ready to backup the database. ### Prepare Backend -We are going to store our backed up data into a `GCS` bucket. We have to create a `Secret` with necessary credentials and a `BackupStorage` CR to use this backend. If you want to use a different backend, please read the respective backend configuration doc from [here](https://kubestash.com/docs/latest/guides/backends/overview/). +We are going to store our backup data into a `GCS` bucket. We have to create a `Secret` with necessary credentials and a `BackupStorage` CR to use this backend. If you want to use a different backend, please read the respective backend configuration doc from [here](https://kubestash.com/docs/latest/guides/backends/overview/). **Create Secret:** @@ -438,7 +438,7 @@ NAME INVOKER-TYPE INVOKE sample-mariadb-backup-frequent-backup-1725449400 BackupConfiguration sample-mariadb-backup Succeeded 7m22s ``` -We can see from the above output that the backup session has succeeded. Now, we are going to verify whether the backed up data has been stored in the backend. +We can see from the above output that the backup session has succeeded. Now, we are going to verify whether the backup data has been stored in the backend. **Verify Backup:** @@ -466,7 +466,7 @@ gcs-mariadb-repo-sample-mariadb-ckup-frequent-backup-1726569774 gcs-mariad > > These labels can be used to watch only the `Snapshot`s related to our target Database or `Repository`. -If we check the YAML of the `Snapshot`, we can find the information about the backed up components of the Database. +If we check the YAML of the `Snapshot`, we can find the information about the backup components of the Database. ```bash $ kubectl get snapshot.storage.kubestash.com -n demo gcs-mariadb-repo-sample-mariadb-ckup-frequent-backup-1726569774 -oyaml @@ -544,7 +544,7 @@ status: > KubeStash uses `mariadb-dump` to perform backups of target `MariaDB` databases. Therefore, the component name for logical backups is set as `dump`. -Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/popstgres/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/mariadb/snapshots` directory. +Now, if we navigate to the GCS bucket, we will see the backup data stored in the `demo/mariadb/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/mariadb/snapshots` directory. > Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. @@ -598,7 +598,7 @@ restored-mariadb 11.1.3 Provisioning 110s Now, we need to create a `RestoreSession` CR pointing to targeted `MariaDB` database. -Below, is the contents of YAML file of the `RestoreSession` object that we are going to create to restore backed up data into the newly created `MariaDB` database named `restored-mariadb`. +Below, is the contents of YAML file of the `RestoreSession` object that we are going to create to restore backup data into the newly created `MariaDB` database named `restored-mariadb`. ```yaml apiVersion: core.kubestash.com/v1alpha1 @@ -627,7 +627,7 @@ spec: Here, - `.spec.target` refers to the newly created `restored-mariadb` MariaDB object to where we want to restore backup data. -- `.spec.dataSource.repository` specifies the Repository object that holds the backed up data. +- `.spec.dataSource.repository` specifies the Repository object that holds the backup data. - `.spec.dataSource.snapshot` specifies to restore from latest `Snapshot`. Let's create the RestoreSession CRD object we have shown above, @@ -641,7 +641,6 @@ Once, you have created the `RestoreSession` object, KubeStash will create restor ```bash $ watch kubectl get restoresession -n demo -Every 2.0s: kubectl get restores... AppsCode-PC-03: Wed Aug 21 10:44:05 2024 NAME REPOSITORY FAILURE-POLICY PHASE DURATION AGE sample-mariadb-restore gcs-mariadb-repo Succeeded 7s 116s ``` diff --git a/docs/guides/mariadb/backup/stash/_index.md b/docs/guides/mariadb/backup/stash/_index.md new file mode 100644 index 000000000..5b70dae6c --- /dev/null +++ b/docs/guides/mariadb/backup/stash/_index.md @@ -0,0 +1,10 @@ +--- +title: Backup & Restore MariaDB | Stash +menu: + docs_{{ .version }}: + identifier: guides-mariadb-backup-stashv1 + name: Stash + parent: guides-mariadb-backup + weight: 50 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/mariadb/backup/stash/auto-backup/index.md b/docs/guides/mariadb/backup/stash/auto-backup/index.md index 7cd0ffc14..4c42babdf 100644 --- a/docs/guides/mariadb/backup/stash/auto-backup/index.md +++ b/docs/guides/mariadb/backup/stash/auto-backup/index.md @@ -3,9 +3,9 @@ title: MariaDB Auto-Backup | Stash description: Backup MariaDB using Stash Auto-Backup menu: docs_{{ .version }}: - identifier: guides-mariadb-backup-auto-backup-stash + identifier: guides-mariadb-backup-auto-backup-stashv1 name: Auto-Backup - parent: guides-mariadb-backup-stash + parent: guides-mariadb-backup-stashv1 weight: 30 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/mariadb/backup/stash/customization/index.md b/docs/guides/mariadb/backup/stash/customization/index.md index c67168f5a..19fd9cd88 100644 --- a/docs/guides/mariadb/backup/stash/customization/index.md +++ b/docs/guides/mariadb/backup/stash/customization/index.md @@ -3,9 +3,9 @@ title: MariaDB Backup Customization | Stash description: Customizing MariaDB Backup and Restore process with Stash menu: docs_{{ .version }}: - identifier: guides-mariadb-backup-customization-stash + identifier: guides-mariadb-backup-customization-stashv1 name: Customizing Backup & Restore Process - parent: guides-mariadb-backup-stash + parent: guides-mariadb-backup-stashv1 weight: 40 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/mariadb/backup/stash/logical/_index.md b/docs/guides/mariadb/backup/stash/logical/_index.md index fb5c387dd..ae81756a1 100644 --- a/docs/guides/mariadb/backup/stash/logical/_index.md +++ b/docs/guides/mariadb/backup/stash/logical/_index.md @@ -2,9 +2,9 @@ title: Logical Backup of MariaDB Using Stash menu: docs_{{ .version }}: - identifier: guides-mariadb-backup-logical-stash + identifier: guides-mariadb-backup-logical-stashv1 name: Logical Backup - parent: guides-mariadb-backup-stash + parent: guides-mariadb-backup-stashv1 weight: 20 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mariadb/backup/stash/logical/cluster/index.md b/docs/guides/mariadb/backup/stash/logical/cluster/index.md index 21b6ce5f5..992c6a321 100644 --- a/docs/guides/mariadb/backup/stash/logical/cluster/index.md +++ b/docs/guides/mariadb/backup/stash/logical/cluster/index.md @@ -3,9 +3,9 @@ title: Backup KubeDB managed MariaDB Cluster using Stash | Stash description: Backup KubeDB managed clustered MariaDB using Stash menu: docs_{{ .version }}: - identifier: guides-mariadb-backup-logical-clustered + identifier: guides-mariadb-backup-logical-clustered-stashv1 name: Clustered MariaDB - parent: guides-mariadb-backup-logical + parent: guides-mariadb-backup-logical-stashv1 weight: 20 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/mariadb/backup/stash/logical/standalone/index.md b/docs/guides/mariadb/backup/stash/logical/standalone/index.md index ab977dd69..20f32a595 100644 --- a/docs/guides/mariadb/backup/stash/logical/standalone/index.md +++ b/docs/guides/mariadb/backup/stash/logical/standalone/index.md @@ -3,9 +3,9 @@ title: Backup KubeDB managed stanadlone MariaDB using Stash | Stash description: Backup KubeDB managed stanadlone MariaDB using Stash menu: docs_{{ .version }}: - identifier: guides-mariadb-backup-logical-standalone + identifier: guides-mariadb-backup-logical-standalone-stashv1 name: Standalone MariaDB - parent: guides-mariadb-backup-logical + parent: guides-mariadb-backup-logical-stashv1 weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/mariadb/backup/stash/overview/index.md b/docs/guides/mariadb/backup/stash/overview/index.md index 5f0aabe03..cb53467d9 100644 --- a/docs/guides/mariadb/backup/stash/overview/index.md +++ b/docs/guides/mariadb/backup/stash/overview/index.md @@ -2,9 +2,9 @@ title: Backup & Restore MariaDB Using Stash menu: docs_{{ .version }}: - identifier: guides-mariadb-backup-overview-stash + identifier: guides-mariadb-backup-overview-stashv1 name: Overview - parent: guides-mariadb-backup-stash + parent: guides-mariadb-backup-stashv1 weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides