refactor

Signed-off-by: SK Ali Arman <[email protected]>

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

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.
 

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.
 

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

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   <none>        3306/TCP   6m28s
-sample-mariadb-pods       ClusterIP   None           <none>        3306/TCP   6m28s     5432/TCP                     5m55s
+sample-mariadb            ClusterIP   10.128.7.155   <none>        3306/TCP                     6m28s
+sample-mariadb-pods       ClusterIP   None           <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
 ```

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 }}
+---

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

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

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 }}
 ---

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

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

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