Cleanup and fix urls

Signed-off-by: Md. Ishtiaq Islam <[email protected]>
kubestash · Mar 20, 2024 · d4fbc84 · d4fbc84
1 parent 86ab7b7
commit d4fbc84
Show file tree

Hide file tree

Showing 20 changed files with 53 additions and 36 deletions.
diff --git a/docs/concepts/crds/backupblueprint/index.md b/docs/concepts/crds/backupblueprint/index.md
@@ -125,11 +125,8 @@ spec:
     - **hooks :** specifies the backup hooks that should be executed before and/or after the backup. Hooks has two fields:
       - **preBackup :** specifies a list of hooks that will be executed before backup. To learn about the fields under `preBackup`, see [HookInfo](/docs/concepts/crds/backupconfiguration/index.md#hookinfo).
       - **postBackup :** specifies a list of hooks that will be executed after backup. To learn about the fields under `postBackup`, see [HookInfo](/docs/concepts/crds/backupconfiguration/index.md#hookinfo).
-    - **failurePolicy :** specifies what to do if the backup fail. Valid values are:
-      - **Fail :** KubeStash should mark the backup as failed if any component fail to complete its backup. This is the default behavior.
-      - **Retry :** KubeStash will retry to backup the failed component according to the `retryConfig`.
     - **retryConfig :** specifies the behavior of retry in case of a backup failure. RetryConfig has the following fields:
-      - **maxRetry :** specifies the maximum number of times Stash should retry the backup/restore process. By default, KubeStash will retry only 1 time.
+      - **maxRetry :** specifies the maximum number of times KubeStash should retry the backup/restore process. By default, KubeStash will retry only 1 time.
       - **delay :** The amount of time to wait before next retry. If you don't specify this field, KubeStash will retry immediately. Format: 30s, 2m, 1h etc.
     - **timeout :** specifies the maximum duration of backup. BackupSession will be considered Failed if backup does not complete within this time limit. By default, KubeStash don't set any timeout for backup.
     - **sessionHistoryLimit :** specifies how many backup Jobs and associate resources KubeStash should keep for debugging purpose. The default value is 1.

diff --git a/docs/concepts/crds/restoresession/index.md b/docs/concepts/crds/restoresession/index.md
@@ -103,9 +103,9 @@ A `RestoreSession` object has the following fields in the `spec` section.
 #### spec.dataSource
 
 `spec.dataSource` specifies the information about the data that will be restored. It consists of the following fields:
-
+- **namespace:** specifies the namespace of the DataSource (i.e. Repository, Snapshot). If you keep this field empty, then KubeStash will consider the DataSource is in the same namespace of the `RestoreSession`.
 - **repository :** points to the `Repository` name from which the data will be restored. The `Repository` must be in the same namespace as the `RestoreSession` CR. This field can be empty if the snapshot name is specified.
-- **snapshot :**  specifies the `Snapshot` name that will be restored. If you want to use **Point-In-Time** recovery option, don't specify this field. Specify `pitr` field instead. If you want to use the latest `Snapshot`, use `latest` value in this field. KubeStash will automatically find the latest `Snapshot`.
+- **snapshot :**  specifies the `Snapshot` name that will be restored. If you want to use the latest `Snapshot`, use `latest` value in this field. KubeStash will automatically find the latest `Snapshot`.
 - **components :** specifies the list of components that will be restored. If you keep this field empty, then all the components that were backed up in the desired `Snapshot` will be restored.
 - **encryptionSecret :** refers to the Secret containing the encryption key which will be used to decrypt the backed up data. You can refer to a Secret of a different namespace. You have to specify `name` and `namespace` of the secret. This field is optional. No encryption secret is required for restoring from `VolumeSnapshot` backups.
 
@@ -154,7 +154,7 @@ HookInfo specifies the information about the restore hooks. It consists of the f
 | `name`            | specifies a name for the hook                                                                                                                                                                                                                                                                                                                                                                                 |
 | `hookTemplate`    | points to a HookTemplate CR that will be used to execute the hook. You can refer to a HookTemplate from other namespaces as long as your current namespace is allowed by the `usagePolicy` in the respective HookTemplate.                                                                                                                                                                                    |
 | `params`          | specifies parameters for the hook. These parameters must be defined in the respective HookTemplates.                                                                                                                                                                                                                                                                                                          |
-| `maxRetry`        | MaxRetry specifies how many times Stash should retry the hook execution in case of failure.   The default value of this field is 0 which means no retry.                                                                                                                                                                                                                                                      |
+| `maxRetry`        | MaxRetry specifies how many times KubeStash should retry the hook execution in case of failure.   The default value of this field is 0 which means no retry.                                                                                                                                                                                                                                                  |
 | `timeout`         | Timeout specifies a duration in seconds that KubeStash should wait for the hook execution to be completed. If the hook execution does not finish within this time period, KubeStash will consider this hook execution as failure. Then, it will be re-tried according to MaxRetry policy.                                                                                                                     |
 | `executionPolicy` | ExecutionPolicy specifies when to execute the hook. Valid values are: <ul><li>**Always** KubeStash will execute this hook no matter the backup/restore failed. This is the default execution policy.</li><li>**OnSuccess** KubeStash will execute this hook only if the backup/restore has succeeded.</li><li>**OnFailure** KubeStash will execute this hook only if the backup/restore has failed.</li></ul> |
 | `variables`       | specifies a list of variables and their sources that will be used to resolve the HookTemplate.                                                                                                                                                                                                                                                                                                                |

diff --git a/docs/concepts/what-is-kubestash/overview/index.md b/docs/concepts/what-is-kubestash/overview/index.md
@@ -26,7 +26,7 @@ section_menu_id: concepts
 | Backup & Restore databases                                                              | PostgreSQL, MySQL, MongoDB, Elasticsearch, Redis                                                                                       |
 | Pause Backup                                                                            | No new backup when paused.                                                                                                             |
 | Cleanup old `Snapshot`s automatically                                                   | Cleanup old `Snapshot`s according to `RetentionPolicy`.                                                                                |
-| Encryption, Deduplication (send only diff)                                              | Encrypt backed up data with AES-256. Stash only sends the changes since last backup.                                                   |
+| Encryption, Deduplication (send only diff)                                              | Encrypt backed up data with AES-256. KubeStash only sends the changes since last backup.                                               |
 | [CSI Driver Integration](https://kubernetes.io/docs/concepts/storage/volume-snapshots/) | VolumeSnapshot for Kubernetes workloads. Supported for Kubernetes v1.17.0+.                                                            |
 | Security                                                                                | Built-in support for RBAC and Network Policy                                                                                           |
 | CLI                                                                                     | `kubectl` plugin (for Kubernetes 1.12+)                                                                                                |

diff --git a/docs/guides/auto-backup/pvc/index.md b/docs/guides/auto-backup/pvc/index.md
@@ -20,7 +20,7 @@ This tutorial will show you how to configure automatic backup for PersistentVolu
 
 - At first, you need to have a Kubernetes cluster, and the `kubectl` command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/).
 - Install `KubeStash` in your cluster following the steps [here](/docs/setup/README.md).
-- You will need to have a PVC with `ReadWriteMany` access permission. Here, we are going to use an NFS server to provision a PVC with `ReadWriteMany` access. If you don't have an NFS server running, deploy one by following the guide [here](https://github.com/appscode/third-party-tools/blob/master/storage/nfs/README.md).
+- Here, we are going to use an NFS server to provision a PVC with `ReadWriteMany` access. If you don't have an NFS server running, deploy one by following the guide [here](https://github.com/appscode/third-party-tools/blob/master/storage/nfs/README.md).
 - You should be familiar with the following `KubeStash` concepts:
   - [BackupBlueprint](/docs/concepts/crds/backupblueprint/index.md)
   - [BackupConfiguration](/docs/concepts/crds/backupconfiguration/index.md)
@@ -147,6 +147,17 @@ $ kubectl apply -f https://github.com/kubestash/docs/raw/{{< param "info.version
 retentionpolicy.storage.kubestash.com/demo-retention created
 ```
 
+**Create Encryption Secret:**
+
+Let's create a secret called `encrypt-secret` with the Restic password,
+
+```bash
+$ echo -n 'changeit' > RESTIC_PASSWORD
+$ kubectl create secret generic -n demo encrypt-secret \
+    --from-file=./RESTIC_PASSWORD \
+secret "encrypt-secret" created
+```
+
 **Create BackupBlueprint:**
 
 Now, we have to create a `BackupBlueprint` CR with a blueprint for `BackupConfiguration` object.
@@ -211,33 +222,37 @@ Now, automatic backup is configured for PVC. We just have to add some annotation
 
 You have to add the auto-backup annotations to the pvc that you want to backup. The following auto-backup annotations are available:
 
-- **BackupBlueprint Name:** You have to specify the `BackupBlueprint` name that holds the template for `BackupConfiguration` in the following annotation:
+Required Annotations:
+
+- **BackupBlueprint Name:** Specifies the name of the `BackupBlueprint` to be used for this pvc's backup.
 
 ```yaml
 blueprint.kubestash.com/name: <BackupBlueprint name>
 ```
 
-- **BackupBlueprint Namespace:** You have to specify the `BackupBlueprint` namespace that holds the template for `BackupConfiguration` in the following annotation:
+- **BackupBlueprint Namespace:** Specifies the namespace where the `BackupBlueprint` resides.
 
 ```yaml
 blueprint.kubestash.com/namespace: <BackupBlueprint namespace>
 ```
 
-- **Sessions:** You can specify with which sessions you want to create the `BackupConfiguration`. If you don't specify this annotation, all sessions from the `BackupBlueprint` will be used. For multiple sessions, you can provide comma (,) seperated sessions name.
+Optional Annotations:
+
+- **Session Names:** Defines which sessions from the `BackupBlueprint` should be used for the `BackupConfiguration`. If you don’t specify this annotation, all sessions from the `BackupBlueprint` will be used. For multiple sessions, you can provide comma (,) seperated session names.
 
 ```yaml
- blueprint.kubestash.com/sessions: <Sessions name>
+ blueprint.kubestash.com/session-names: <Session names>
 ```
 
-- **Variables:** You can specify arbitrary number of annotations for variables. KubeStash will resolve the  variables and create `BackupConfiguration` accordingly.
+- **Variables:** Allows you to customize the `BackupConfiguration` by providing values for variables defined within the `BackupBlueprint`. You can define as many annotations as needed for variables.
 
 ```yaml
 variables.kubestash.com/<variable-name>: <Variable value>
 ```
 
 Example:
 
-Assume you are using a variable, named `schedule`, in `BackupBlueprint`. By this variable we can configure different backup schedule for different target. We will add this annotation in the target.
+Assuming you are using a variable named `schedule` for a session schedule in the `BackupBlueprint`, you can configure different backup schedules for each target application using annotations like this:
 ```yaml
 variables.kubestash.com/schedule: "*/5 * * * *"
 ```
@@ -407,7 +422,12 @@ Now, we are going to add auto backup specific annotation to the PVC. KubeStash w
 Let's add the auto backup specific annotation to the PVC,
 
 ```bash
-
+$ kubectl annotate pvc nfs-pvc -n demo --overwrite     \
+    blueprint.kubestash.com/name=pvc-backup-blueprint  \
+    blueprint.kubestash.com/namespace=demo             \
+    variables.kubestash.com/targetName=nfs-pvc         \
+    variables.kubestash.com/namespace=demo             \
+    variables.kubestash.com/repoName=pvc-repo
 ```
 
 Verify that the annotations has been added successfully,
@@ -579,7 +599,7 @@ status:
 
 Now, if we navigate to the GCS bucket, we will see the backed up data has been stored in the `demo/demo/nfs-pvc/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/demo/nfs-pvc/snapshots` directory.
 
-> KubeStash keeps all the dumped data encrypted in the backup directory meaning the dumped files won't contain any readable data until decryption.
+> Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted.
 
 ## Cleanup
 

diff --git a/docs/guides/auto-backup/workload/index.md b/docs/guides/auto-backup/workload/index.md
@@ -210,10 +210,10 @@ blueprint.kubestash.com/namespace: <BackupBlueprint namespace>
 
 Optional Annotations:
 
-- **Session Names:** Defines which sessions from the `BackupBlueprint` should be used for the `BackupConfiguration`. If you don’t specify this annotation, all sessions from the `BackupBlueprint` will be used. For multiple sessions, you can provide comma (,) seperated sessions name.
+- **Session Names:** Defines which sessions from the `BackupBlueprint` should be used for the `BackupConfiguration`. If you don’t specify this annotation, all sessions from the `BackupBlueprint` will be used. For multiple sessions, you can provide comma (,) seperated session names.
 
 ```yaml
- blueprint.kubestash.com/sessions: <Sessions name>
+ blueprint.kubestash.com/session-names: <Session names>
 ```
 
 - **Variables:** Allows you to customize the `BackupConfiguration` by providing values for variables defined within the `BackupBlueprint`. You can define as many annotations as needed for variables.
@@ -486,7 +486,7 @@ status:
 
 Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/demo/sample-sts/repository/v1/frequent-backup/dump-pod-<ordinal-value>` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/demo/sample-sts/snapshots` directory.
 
-> KubeStash keeps all the dumped data encrypted in the backup directory meaning the dumped files won't contain any readable data until decryption.
+> Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted.
 
 ## Backup Deployment
 

diff --git a/docs/guides/hooks/backup-and-restore-hooks/index.md b/docs/guides/hooks/backup-and-restore-hooks/index.md
@@ -24,7 +24,7 @@ Here, we are going to demonstrate how you can perform different actions before a
 - At first, you need to have a Kubernetes cluster, and the `kubectl` command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/).
 - Install KubeStash in your cluster following the steps [here](/docs/setup/install/kubestash/index.md).
 - Install [KubeDB](https://kubedb.com) in your cluster following the steps [here](https://kubedb.com/docs/latest/setup/). This step is optional. You can deploy your database using any method you want. We are using KubeDB because KubeDB simplifies many of the difficult or tedious management tasks of running production-grade databases on private and public clouds.
-- If you are not familiar with how KubeStash backup and restore MySQL databases, please check the following guide [here](/docs/addons/mysql/overview/index.md).
+- If you are not familiar with how KubeStash backup and restore MySQL databases, please check the [KubeDB](https://kubedb.com/) documentation for MySQL backup and restore using KubeStash.
 - Also, if you haven't read about how hooks work in KubeStash, please check it from [here](/docs/guides/hooks/overview/index.md).
 
 You should be familiar with the following `KubeStash` concepts:
@@ -471,7 +471,7 @@ status:
 
 Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/demo/hook/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/demo/sample-sts/snapshots` directory.
 
-> KubeStash keeps all the dumped data encrypted in the backup directory meaning the dumped files won't contain any readable data until decryption.
+> Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted.
 
 **Verify PreBackup Hook Executed:**
 

diff --git a/docs/guides/hooks/slack-notification/images/step_4.png b/docs/guides/hooks/slack-notification/images/step_4.png
diff --git a/docs/guides/hooks/slack-notification/images/step_5.png b/docs/guides/hooks/slack-notification/images/step_5.png
diff --git a/docs/guides/hooks/slack-notification/images/step_6.png b/docs/guides/hooks/slack-notification/images/step_6.png
diff --git a/docs/guides/kubedump/application/index.md b/docs/guides/kubedump/application/index.md
@@ -336,7 +336,7 @@ Now, if we navigate to the GCS bucket, we will see the backed up data stored in
   <figcaption align="center">Fig: Backup YAMLs data of an Application in GCS backend</figcaption>
 </figure>
 
-> Note: KubeStash keeps all the dumped data encrypted in the backup directory meaning the dumped files won't contain any readable data until decryption.
+> Note: KubeStash stores all dumped data encrypted in backup directory, meaning it remains unreadable until decrypted.
 
 ## Restore
 

diff --git a/docs/guides/kubedump/cluster/index.md b/docs/guides/kubedump/cluster/index.md
@@ -319,7 +319,7 @@ Now, if we navigate to the GCS bucket, we will see the backed up data stored in
   <figcaption align="center">Fig: Backup data in GCS Bucket</figcaption>
 </figure>
 
-> Note: KubeStash keeps all the dumped data encrypted in the backup directory meaning the dumped files won't contain any readable data until decryption.
+> Note: KubeStash stores all dumped data encrypted in backup directory, meaning it remains unreadable until decrypted.
 
 ## Restore
 
@@ -329,7 +329,7 @@ Therefore, it is the user's responsibility to download the backed-up YAMLs and t
 
 ### Download the YAMLs
 
-KubeStash provides a [kubectl plugin](/docs/guides/cli/cli/#download-snapshots) for making it easy to download a snapshot locally.
+KubeStash provides a [kubectl plugin](/docs/guides/cli/kubectl-plugin/index.md#download-snapshot) for making it easy to download a snapshot locally.
 
 Now, let's download the latest Snapshot from our backed-up data into the `$HOME/Downloads/kubestash` folder of our local machine.