diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index a7f2d64..9679016 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -34,7 +34,7 @@ jobs: - name: Check links run: | - liche -r docs -d $(pwd) -c 10 -p -h -l -x '^(.*/docs/{{<.*>}}/.*|.*github.com.*|.*api.slack.com.*|.*askapache.com.*|.*twitter.com.*)$' + liche -r docs -d $(pwd) -c 10 -p -h -l -x '^(.*/docs/{{<.*>}}/.*|.*github.com.*|.*api.slack.com.*|.*askapache.com.*|.*twitter.com.*|.*dev.mysql.com.*|.*linux.die.net.*)$' - name: Create Kubernetes cluster id: kind diff --git a/docs/concepts/crds/backupblueprint/index.md b/docs/concepts/crds/backupblueprint/index.md index 220c863..c6c7952 100644 --- 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 index bc56c02..f874aa2 100644 --- 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: | | `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 index 44374c8..745dac1 100644 --- 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 index 1e3dd1c..3b25e68 100644 --- 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,25 +222,29 @@ 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 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: ``` -- **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: + blueprint.kubestash.com/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/: @@ -237,7 +252,7 @@ variables.kubestash.com/: 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 index a9b669b..54e922f 100644 --- a/docs/guides/auto-backup/workload/index.md +++ b/docs/guides/auto-backup/workload/index.md @@ -210,10 +210,10 @@ blueprint.kubestash.com/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: + blueprint.kubestash.com/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-` 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 index 9ecc2d2..0ef0f02 100644 --- 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 new file mode 100644 index 0000000..079c877 Binary files /dev/null and b/docs/guides/hooks/slack-notification/images/step_4.png differ diff --git a/docs/guides/hooks/slack-notification/images/step_5.png b/docs/guides/hooks/slack-notification/images/step_5.png new file mode 100644 index 0000000..4609e57 Binary files /dev/null and b/docs/guides/hooks/slack-notification/images/step_5.png differ diff --git a/docs/guides/hooks/slack-notification/images/step_6.png b/docs/guides/hooks/slack-notification/images/step_6.png new file mode 100644 index 0000000..ef981ff Binary files /dev/null and b/docs/guides/hooks/slack-notification/images/step_6.png differ diff --git a/docs/guides/kubedump/application/index.md b/docs/guides/kubedump/application/index.md index e168caa..0a6c97b 100644 --- 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
Fig: Backup YAMLs data of an Application in GCS backend
-> 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 index 2b2b3f1..910978e 100644 --- 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
Fig: Backup data in GCS Bucket
-> 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. diff --git a/docs/guides/kubedump/namespace/index.md b/docs/guides/kubedump/namespace/index.md index 3d7c2d8..4fd7cfb 100644 --- a/docs/guides/kubedump/namespace/index.md +++ b/docs/guides/kubedump/namespace/index.md @@ -327,7 +327,7 @@ Now, if we navigate to the GCS bucket, we will see the backed up data stored in
Fig: Backup data in GCS Bucket
-> 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 @@ -337,7 +337,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/namespace/kube-system` folder of our local machine. diff --git a/docs/guides/platforms/aks/index.md b/docs/guides/platforms/aks/index.md index 0e6c134..ab130e0 100644 --- a/docs/guides/platforms/aks/index.md +++ b/docs/guides/platforms/aks/index.md @@ -474,7 +474,7 @@ status: Now, if we navigate to the [Azure Blob Container](https://azure.microsoft.com/en-us/services/storage/blobs/), we will see the backed up data stored in the `demo/dep/repository/v1/demo-session/dump` directory. KubeStash also keeps backup for `Snapshot` YAMLs, which can be found in the `demo/dep/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. ## Restore diff --git a/docs/guides/platforms/eks-irsa/index.md b/docs/guides/platforms/eks-irsa/index.md index 1dc1101..8e1894d 100644 --- a/docs/guides/platforms/eks-irsa/index.md +++ b/docs/guides/platforms/eks-irsa/index.md @@ -444,7 +444,7 @@ status: Now, if we navigate to the S3 bucket, we will see the backed up data stored in the `demo/data/ks-demo/repository/v1/demo-session/dump-` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/data/ks-demo/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. ## Restore diff --git a/docs/guides/platforms/gke/index.md b/docs/guides/platforms/gke/index.md index e17d55a..d005982 100644 --- a/docs/guides/platforms/gke/index.md +++ b/docs/guides/platforms/gke/index.md @@ -482,7 +482,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/demo-session/dump-pod-` 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. ## Restore diff --git a/docs/guides/platforms/minio/index.md b/docs/guides/platforms/minio/index.md index e835ffc..ddbbd98 100644 --- a/docs/guides/platforms/minio/index.md +++ b/docs/guides/platforms/minio/index.md @@ -439,7 +439,7 @@ Now, if we navigate to the Minio Bucket, we are going to see backed up data has
Fig: Backup data in Minio Bucket
-> KubeStash keeps all backup data encrypted. So, the files in the bucket will not contain any meaningful data until they are decrypted. +> Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. ## Restore the Backed up Data diff --git a/docs/guides/volumes/pvc/index.md b/docs/guides/volumes/pvc/index.md index f7ea71b..f5a952d 100644 --- a/docs/guides/volumes/pvc/index.md +++ b/docs/guides/volumes/pvc/index.md @@ -473,7 +473,7 @@ Now, if we navigate to the GCS bucket, we will see the backed up data stored in
Fig: Backed up data of a stand-alone PVC in GCS backend
-> KubeStash keeps all backup data encrypted. So, snapshot files in the bucket will not contain any meaningful data until they are decrypted. +> Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. ## Restore diff --git a/docs/guides/workloads/daemonset/index.md b/docs/guides/workloads/daemonset/index.md index 43d7368..5b5d89b 100644 --- a/docs/guides/workloads/daemonset/index.md +++ b/docs/guides/workloads/daemonset/index.md @@ -366,7 +366,7 @@ status: Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/data/ks-demo/repository/v1/demo-session/dump-` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/data/ks-demo/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. ## Restore diff --git a/docs/guides/workloads/deployment/index.md b/docs/guides/workloads/deployment/index.md index d8d99e7..6b3d4d6 100644 --- a/docs/guides/workloads/deployment/index.md +++ b/docs/guides/workloads/deployment/index.md @@ -401,9 +401,9 @@ status: ``` > For Deployment, KubeStash takes backup from only one pod of the Deployment. So, only one component has been backed up. For logical backup, KubeStash uses `dump` as the component name for Deployment. -Now, if we navigate to the GCS bucket, we will see the backed up data has been stored in the `demo/dep/repository/v1/demo-session/dump` directory and the Snapshot metadata has been stored in the `demo/dep/snapshots` directory. +Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/dep/repository/v1/demo-session/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/dep/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. ## Restore diff --git a/docs/guides/workloads/statefulset/index.md b/docs/guides/workloads/statefulset/index.md index 4159abf..39c60c2 100644 --- a/docs/guides/workloads/statefulset/index.md +++ b/docs/guides/workloads/statefulset/index.md @@ -424,7 +424,7 @@ status: Now, if we navigate to GCS bucket, we will see the backed up data stored in the `demo/demo/sample-sts/repository/v1/demo-session/dump-pod-` 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. ## Restore