From 6e4b5d9f1f6fb43d5debedcd07e206e6975e6661 Mon Sep 17 00:00:00 2001 From: Anisur Rahman Date: Mon, 16 Sep 2024 16:26:04 +0600 Subject: [PATCH] delete mongo for build pass Signed-off-by: Anisur Rahman --- .../guides/mongodb/backup/kubestash/_index.md | 10 - .../backup/kubestash/auto-backup/_index.md | 369 ----------- .../auto-backup/examples/backupblueprint.yaml | 36 -- .../auto-backup/examples/backupstorage.yaml | 18 - .../auto-backup/examples/retentionpolicy.yaml | 12 - .../auto-backup/examples/sample-mongodb.yaml | 24 - .../auto-backup/images/sample-mongodb.png | Bin 32387 -> 0 bytes .../backup/kubestash/customization/_index.md | 314 --------- .../examples/backup/passing-args.yaml | 38 -- .../examples/backup/resource-limit.yaml | 44 -- .../examples/backup/specific-user.yaml | 41 -- .../examples/restore/restore.yaml | 26 - .../examples/retentionpolicy.yaml | 12 - .../backup/kubestash/logical/_index.md | 10 - .../kubestash/logical/replicaset/_index.md | 593 ----------------- .../backupconfiguration-replicaset.yaml | 36 -- .../examples/backupstorage-replicaset.yaml | 18 - .../examples/mongodb-replicaset-restore.yaml | 18 - .../examples/mongodb-replicaset.yaml | 18 - .../examples/restoresession-replicaset.yaml | 21 - .../replicaset/examples/retentionpolicy.yaml | 12 - .../kubestash/logical/sharding/_index.md | 607 ------------------ .../backupconfiguration-sharding.yaml | 36 -- .../examples/backupstorage-sharding.yaml | 18 - .../examples/mongodb-sharding-restore.yaml | 26 - .../sharding/examples/mongodb-sharding.yaml | 26 - .../examples/restoresession-sharding.yaml | 21 - .../sharding/examples/retentionpolicy.yaml | 12 - .../kubestash/logical/standalone/_index.md | 586 ----------------- .../examples/backupconfiguration.yaml | 36 -- .../standalone/examples/backupstorage.yaml | 18 - .../standalone/examples/mongodb-restore.yaml | 16 - .../logical/standalone/examples/mongodb.yaml | 16 - .../standalone/examples/restoresession.yaml | 21 - .../standalone/examples/retentionpolicy.yaml | 12 - .../backup/kubestash/overview/_index.md | 164 ----- .../overview/images/backup_overview.svg | 1 - .../overview/images/replicaset_backup.svg | 4 - .../overview/images/replicaset_restore.svg | 4 - .../overview/images/restore_overview.svg | 1 - .../overview/images/sharded_backup.svg | 4 - .../overview/images/sharded_restore.svg | 4 - .../overview/images/standalone_backup.svg | 4 - .../overview/images/standalone_restore.svg | 4 - 44 files changed, 3311 deletions(-) delete mode 100644 docs/guides/mongodb/backup/kubestash/_index.md delete mode 100644 docs/guides/mongodb/backup/kubestash/auto-backup/_index.md delete mode 100644 docs/guides/mongodb/backup/kubestash/auto-backup/examples/backupblueprint.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/auto-backup/examples/backupstorage.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/auto-backup/examples/retentionpolicy.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/auto-backup/examples/sample-mongodb.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/auto-backup/images/sample-mongodb.png delete mode 100644 docs/guides/mongodb/backup/kubestash/customization/_index.md delete mode 100644 docs/guides/mongodb/backup/kubestash/customization/examples/backup/passing-args.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/customization/examples/backup/resource-limit.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/customization/examples/backup/specific-user.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/customization/examples/restore/restore.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/customization/examples/retentionpolicy.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/_index.md delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/replicaset/_index.md delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupconfiguration-replicaset.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupstorage-replicaset.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset-restore.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/restoresession-replicaset.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/retentionpolicy.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/sharding/_index.md delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/sharding/examples/backupconfiguration-sharding.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/sharding/examples/backupstorage-sharding.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/sharding/examples/mongodb-sharding-restore.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/sharding/examples/mongodb-sharding.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/sharding/examples/restoresession-sharding.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/sharding/examples/retentionpolicy.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/standalone/_index.md delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/standalone/examples/backupconfiguration.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/standalone/examples/backupstorage.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/standalone/examples/mongodb-restore.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/standalone/examples/mongodb.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/standalone/examples/restoresession.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/logical/standalone/examples/retentionpolicy.yaml delete mode 100644 docs/guides/mongodb/backup/kubestash/overview/_index.md delete mode 100644 docs/guides/mongodb/backup/kubestash/overview/images/backup_overview.svg delete mode 100644 docs/guides/mongodb/backup/kubestash/overview/images/replicaset_backup.svg delete mode 100644 docs/guides/mongodb/backup/kubestash/overview/images/replicaset_restore.svg delete mode 100644 docs/guides/mongodb/backup/kubestash/overview/images/restore_overview.svg delete mode 100644 docs/guides/mongodb/backup/kubestash/overview/images/sharded_backup.svg delete mode 100644 docs/guides/mongodb/backup/kubestash/overview/images/sharded_restore.svg delete mode 100644 docs/guides/mongodb/backup/kubestash/overview/images/standalone_backup.svg delete mode 100644 docs/guides/mongodb/backup/kubestash/overview/images/standalone_restore.svg diff --git a/docs/guides/mongodb/backup/kubestash/_index.md b/docs/guides/mongodb/backup/kubestash/_index.md deleted file mode 100644 index 1c38ebf73..000000000 --- a/docs/guides/mongodb/backup/kubestash/_index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Backup & Restore MongoDB | KubeStash -menu: - docs_{{ .version }}: - identifier: guides-mongodb-backup-stashv2 - name: KubeStash (aka Stash 2.0) - parent: guides-mongodb-backup - weight: 50 -menu_name: docs_{{ .version }} ---- \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/auto-backup/_index.md b/docs/guides/mongodb/backup/kubestash/auto-backup/_index.md deleted file mode 100644 index abde5fc78..000000000 --- a/docs/guides/mongodb/backup/kubestash/auto-backup/_index.md +++ /dev/null @@ -1,369 +0,0 @@ ---- -title: MongoDB Auto-Backup | KubeStash -description: Backup MongoDB using KubeStash Auto-Backup -menu: - docs_{{ .version }}: - identifier: guides-mongodb-backup-kubestash-auto-backup - name: Auto-Backup - parent: guides-mongodb-backup-stashv2 - weight: 30 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -# Backup MongoDB using KubeStash Auto-Backup - -KubeStash can be configured to automatically backup any MongoDB database in your cluster. KubeStash 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 MongoDB 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 KubeStash Enterprise in your cluster following the steps [here](https://stash.run/docs/latest/setup/install/stash/). -- Install KubeDB in your cluster following the steps [here](/docs/setup/README.md). -- If you are not familiar with how Stash backup and restore MongoDB databases, please check the following guide [here](/docs/guides/mongodb/backup/stash/overview/index.md). -- If you are not familiar with how auto-backup works in Stash, please check the following guide [here](https://stash.run/docs/latest/guides/auto-backup/overview/). -- If you are not familiar with the available auto-backup options for databases in Stash, please check the following guide [here](https://stash.run/docs/latest/guides/auto-backup/database/). - -You should be familiar with the following `KubeStash` concepts: - -- [BackupBlueprint](https://stash.run/docs/latest/concepts/crds/backupblueprint/) -- [BackupConfiguration](https://stash.run/docs/latest/concepts/crds/backupconfiguration/) -- [BackupSession](https://stash.run/docs/latest/concepts/crds/backupsession/) -- [Repository](https://stash.run/docs/latest/concepts/crds/repository/) -- [Function](https://stash.run/docs/latest/concepts/crds/function/) -- [Task](https://stash.run/docs/latest/concepts/crds/task/) - -To keep things isolated, we are going to use a separate namespace called `demo` throughout this tutorial. Create `demo` namespace if you haven't created yet. - -```console -$ kubectl create ns demo -namespace/demo created -``` - -## Prepare Backup Blueprint - -`BackupBlueprint` is a non-namespaced Custom Resource that lets you define a common template for taking backup for all the similar applications. Then, you can just apply some annotations in the targeted application to enable backup. KubeStash will automatically resolve the template and create a BackupConfiguration for the targeted application. - -So we can also take backup any MongoDB database of any namespace just by adding few annotations to our MongoDB CRD. Then, KubeStash will automatically create a `BackupConfiguration` according to the template to backup the database. - -We are going to store our backed up data into a S3 bucket. At first, we need to create a secret with S3 credentials then we need to create a `BackupStorage` crd. If you want to use a different backend, please read the respective backend configuration doc from [here](https://stash.run/docs/latest/guides/backends/overview/). - -### Create Storage Secret: - -Let's create a secret called `s3-secret` with access credentials to our desired S3 bucket, - -```console -$ echo -n '' > AWS_ACCESS_KEY_ID -$ echo -n '' > AWS_SECRET_ACCESS_KEY -$ kubectl create secret generic -n demo s3-secret \ - --from-file=./AWS_ACCESS_KEY_ID \ - --from-file=./AWS_SECRET_ACCESS_KEY -secret/s3-secret created -``` - -### Create BackupStorage: - -Now, crete a `BackupStorage` using this secret. Below is the YAML of BackupStorage CRO we are going to create, - -```yaml -apiVersion: storage.kubestash.com/v1alpha1 -kind: BackupStorage -metadata: - name: s3-storage - namespace: demo -spec: - storage: - provider: s3 - s3: - endpoint: us-east-1.linodeobjects.com - bucket: kubestash-testing - region: us-east-1 - prefix: demo - secret: s3-secret - usagePolicy: - allowedNamespaces: - from: All - deletionPolicy: WipeOut -``` - -Let's create the `BackupStorage` we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/auto-backup/examples/backupstorage.yaml -backupstorage.storage.kubestash.com/s3-storage created -``` -We also need to create an secret for encrypt data and retention policy for `BackupBlueprint` to create `BackupConfiguration` - -### Create Encryption Secret: - -EncryptionSecret refers to the Secret containing the encryption key which will be used to encode/decode the backed up data. Let's create a secret called `encry-secret` - -```console -$ kubectl create secret generic encry-secret -n demo \ - --from-literal=RESTIC_PASSWORD='123' -n demo -secret/encry-secret created -``` - -### Create Retention Policy: - -`RetentionPolicy` specifies how the old Snapshots should be cleaned up. This is a namespaced CRD. However, we can refer it from other namespaces as long as it is permitted via `.spec.usagePolicy`. Below is the YAML of the `RetentionPolicy` called `backup-rp` - -```console -apiVersion: storage.kubestash.com/v1alpha1 -kind: RetentionPolicy -metadata: - name: backup-rp - namespace: demo -spec: - maxRetentionPeriod: 2mo - successfulSnapshots: - last: 10 - usagePolicy: - allowedNamespaces: - from: All -``` - -Let's create the RetentionPolicy we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/auto-backup/examples/retentionpolicy.yaml -retentionpolicy.storage.kubestash.com/backup-rp created -``` - -Now we can create `BackupBlueprint`. Below is the YAML of `BackupBlueprint` object that we are going to use in this tutorial, - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupBlueprint -metadata: - name: sample-blueprint - namespace: demo -spec: - usagePolicy: - allowedNamespaces: - from: All - backupConfigurationTemplate: - deletionPolicy: OnDelete - backends: - - name: s3-backend - storageRef: - namespace: ${storageNamespace} - name: ${storageName} - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - schedule: ${scheduleTime} - repositories: - - name: ${repoName} - backend: s3-backend - directory: ${backupPath} - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup -``` - -Here, we define a template for `BackupConfiguration`. Notice the `backends` and `sessions` fields of `backupConfigurationTemplate` section. We have used some variables in form of `${VARIABLE_NAME}`. KubeStash will automatically resolve those variables from the database annotations information to make `BackupConfiguration` according to that databases need. - -Let's create the `BackupBlueprint` we have shown above, - -```bash -❯ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/auto-backup/examples/backupblueprint.yaml -backupblueprint.core.kubestash.com/sample-blueprint created -``` - -Now, we are ready to backup our MongoDB databases using few annotations. You can check available auto-backup annotations for a databases from [here](https://stash.run/docs/latest/guides/auto-backup/database/#available-auto-backup-annotations-for-database). - -### Create Database - -Now, we are going to create an MongoDB CRO in `demo` namespace. Below is the YAML of the MongoDB object that we are going to create, - -```yaml -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: mgo - namespace: demo - annotations: - blueprint.kubestash.com/name: sample-blueprint - blueprint.kubestash.com/namespace: demo - variables.kubestash.com/storageNamespace: demo - variables.kubestash.com/storageName: s3-storage - variables.kubestash.com/scheduleTime: "*/3 * * * *" - variables.kubestash.com/backupPath: /demo/mgo - variables.kubestash.com/repoName: s3-repo -spec: - version: "4.4.26" - storageType: Durable - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - terminationPolicy: WipeOut -``` - -Notice the `annotations` section. We are pointing to the `BackupBlueprint` that we have created earlier through `blueprint.kubestash.com` annotation. Also we pass the value of the variable of different template through some `variables.kubestash.com` annotations .KubeStash will watch this annotation and a `BackupConfiguration` according to the `BackupBlueprint`. - -Let's create the above MongoDB CRO, - -```bash -❯ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongob/backup/kubestash/auto-backup/examples/sample-mongodb.yaml -mongodb.kubedb.com/sample-mongodb created -``` - -### Verify Auto-backup configured - -In this section, we are going to verify whether KubeStash has created the respective `BackupConfiguration` for our MongoDB database we have just deployed or not. - -#### Verify BackupConfiguration - -If everything goes well, KubeStash should create a `BackupConfiguration` for our MongoDB in `demo` namespace and the phase of that `BackupConfiguration` should be `Ready`. Verify the `BackupConfiguration` crd by the following command, - -```bash -❯ kubectl get backupconfiguration -n demo -NAME PHASE PAUSED AGE -appbinding-mgo Ready 102s -``` - -Now, let's check the YAML of the `BackupConfiguration`. - -```yaml -❯ kubectl get backupconfiguration -n demo appbinding-mgo -oyaml -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - creationTimestamp: "2023-12-08T11:48:27Z" - finalizers: - - kubestash.com/cleanup - generation: 1 - labels: - app.kubernetes.io/managed-by: kubestash.com - kubestash.com/invoker-name: sample-blueprint - kubestash.com/invoker-namespace: demo - name: appbinding-mgo - namespace: demo - resourceVersion: "323212" - uid: 903a354a-7bdb-4a90-a96a-ccdf465b33fd -spec: - backends: - - name: s3-backend - retentionPolicy: - name: backup-rp - namespace: demo - storageRef: - name: s3-storage - namespace: demo - sessions: - - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup - failurePolicy: Fail - name: frequent - repositories: - - backend: s3-backend - directory: /demo/mgo - encryptionSecret: - name: encry-secret - namespace: demo - name: s3-repo - scheduler: - jobTemplate: - template: - controller: {} - metadata: {} - spec: - resources: {} - schedule: '*/3 * * * *' - sessionHistoryLimit: 1 - target: - apiGroup: kubedb.com - kind: MongoDB - name: mgo - namespace: demo -status: - backends: - - name: s3-backend - ready: true - retentionPolicy: - found: true - ref: - name: backup-rp - namespace: demo - storage: - phase: Ready - ref: - name: s3-storage - namespace: demo - conditions: - - lastTransitionTime: "2023-12-08T11:48:57Z" - message: Validation has been passed successfully. - reason: ResourceValidationPassed - status: "True" - type: ValidationPassed - dependencies: - - found: true - kind: Addon - name: mongodb-addon - phase: Ready - repositories: - - name: s3-repo - phase: Ready - sessions: - - conditions: - - lastTransitionTime: "2023-12-08T11:49:07Z" - message: Scheduler has been ensured successfully. - reason: SchedulerEnsured - status: "True" - type: SchedulerEnsured - name: frequent - targetFound: true -``` - -Here we can see that, - -- `spec.storageRef` template variables are overwrite by the `storageNamespace` and `storageName` variable annotations of the `mgo` MongoDB -- `spec.sessions.scheduler.schedule` template variable is overwrite by the `scheduleTime` variable annotation of the `mgo` MongoDB -- `spec.sessions.repositories.name` template variable is overwrite by the `repoName` variable annotation of the `mgo` MongoDB -- `spec.sessions.repositories.directory` template variable is overwrite by the `backupPath` variable annotation of the `mgo` MongoDB - -#### Verify Backup - -Now, let's wait for a backup run to complete. You can watch for `BackupSession` as below, - -```bash -❯ kubectl get backupsession -n demo -NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE -appbinding-mgo-frequent-1702036262 BackupConfiguration appbinding-mgo Succeeded 3m5s -appbinding-mgo-frequent-1702036442 BackupConfiguration appbinding-mgo Running 5s -``` - -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 `spec.sessions.repositories.directory` field of the `BackupConfiguration`. - -
- Backup data in S3 Bucket -
Fig: Backup data in S3 Bucket
-
- -## Cleanup - -To cleanup the resources crated by this tutorial, run the following commands, - -```bash -❯ kubectl delete -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/auto-backup/examples/ -backupblueprint.core.kubestash.com "sample-blueprint" deleted -backupstorage.storage.kubestash.com "s3-storage" deleted -retentionpolicy.storage.kubestash.com "backup-rp" deleted -mongodb.kubedb.com "mgo" deleted -``` diff --git a/docs/guides/mongodb/backup/kubestash/auto-backup/examples/backupblueprint.yaml b/docs/guides/mongodb/backup/kubestash/auto-backup/examples/backupblueprint.yaml deleted file mode 100644 index dc02d1841..000000000 --- a/docs/guides/mongodb/backup/kubestash/auto-backup/examples/backupblueprint.yaml +++ /dev/null @@ -1,36 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupBlueprint -metadata: - name: sample-blueprint - namespace: demo -spec: - usagePolicy: - allowedNamespaces: - from: All - backupConfigurationTemplate: - deletionPolicy: OnDelete - backends: - - name: s3-backend - storageRef: - namespace: ${storageNamespace} - name: ${storageName} - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - jobTemplate: - backoffLimit: 1 - schedule: ${scheduleTime} - repositories: - - name: ${repoName} - backend: s3-backend - directory: ${backupPath} - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/auto-backup/examples/backupstorage.yaml b/docs/guides/mongodb/backup/kubestash/auto-backup/examples/backupstorage.yaml deleted file mode 100644 index 4bed4eee3..000000000 --- a/docs/guides/mongodb/backup/kubestash/auto-backup/examples/backupstorage.yaml +++ /dev/null @@ -1,18 +0,0 @@ -apiVersion: storage.kubestash.com/v1alpha1 -kind: BackupStorage -metadata: - name: s3-storage - namespace: demo -spec: - storage: - provider: s3 - s3: - endpoint: us-east-1.linodeobjects.com - bucket: kubestash-testing - region: us-east-1 - prefix: demo - secretName: s3-secret - usagePolicy: - allowedNamespaces: - from: All - deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/auto-backup/examples/retentionpolicy.yaml b/docs/guides/mongodb/backup/kubestash/auto-backup/examples/retentionpolicy.yaml deleted file mode 100644 index 3d327f9a7..000000000 --- a/docs/guides/mongodb/backup/kubestash/auto-backup/examples/retentionpolicy.yaml +++ /dev/null @@ -1,12 +0,0 @@ -apiVersion: storage.kubestash.com/v1alpha1 -kind: RetentionPolicy -metadata: - name: backup-rp - namespace: demo -spec: - maxRetentionPeriod: 2mo - successfulSnapshots: - last: 10 - usagePolicy: - allowedNamespaces: - from: All \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/auto-backup/examples/sample-mongodb.yaml b/docs/guides/mongodb/backup/kubestash/auto-backup/examples/sample-mongodb.yaml deleted file mode 100644 index 91241db3a..000000000 --- a/docs/guides/mongodb/backup/kubestash/auto-backup/examples/sample-mongodb.yaml +++ /dev/null @@ -1,24 +0,0 @@ -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: mgo - namespace: demo - annotations: - blueprint.kubestash.com/name: sample-blueprint - blueprint.kubestash.com/namespace: demo - variables.kubestash.com/storageNamespace: demo - variables.kubestash.com/storageName: s3-storage - variables.kubestash.com/scheduleTime: "*/3 * * * *" - variables.kubestash.com/backupPath: /demo/mgo - variables.kubestash.com/repoName: s3-repo -spec: - version: "4.4.26" - storageType: Durable - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - terminationPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/auto-backup/images/sample-mongodb.png b/docs/guides/mongodb/backup/kubestash/auto-backup/images/sample-mongodb.png deleted file mode 100644 index c6adefe03742f8d6d068aee14a686e9041de8532..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 32387 zcmdSBXH=72*Di`8Hbe{vNPi3+1Vnm&!~_JS_pTJFq4%mH5W4hUr1uV?2Sj?8P9XG7 z5_%8p=<~kck9T}$oHNeY;~RV5e{#>Y*1h_g*IIL4E5XW&GDHul9^&EQ5y`#&?h$W>(JiNc~WI?ah-BWkxJ>1pIX1n*BAkoaZ z4|3TQ1R)%yPhV)06Wk%I0N%bWNAQ$F*;)Nb7sT{#x6cP@Ls}L4&wyC7hvYMW@3)P0 z)CInG7>Cvn#+=m936+86w_mo;u~`h3PdzHaW%oi zyBZ=e+`aYZ)&7?9!tYw*UEMnV6WK=pKO69Q*_arwO~?0&2Q#81$$w-sJ3*VBo$c4Z z|GQRjia`-SJ?uK%m!_iXLd#dy-v%6)vDP%SlRHQwJyALAs)ZP`mS?Ho8M=QGDcPfx zVJ3Vfueq7)IXox0zAN6%rJ)h#!-EONcM0b{=CJI$Z|xY`*m8Dgt^ptYCdRk*?0P*U zB-BO3z)>}N_@?IjcM7jhxN_T=w%wes>uiSw#%yZ0hZxt&TbT4dn{5lY4A(qCowu|W zInKdtU}8Qq?~nIso|N3LACZ|ofVh5GhA_P0+STP|ly*mM>(z}jG1WFqcl>UOueq#?&r-DFLr(A)#t3a3qEchylI6LznDw@`~{8hg_V_bl|geztT@c>f6? zD&sM|g!^81Ai12JRZME^QA+p&Tz2(GX?{M|ecaRu8fnv#wsN{72OdF&_A<6qw60fQ z^C71Nxp$8y7u~j5KyGp&gQT>gJ#CNTd>oaPrHBAaxnzjZPE0yG&rIvClD*j~Zs@PmZAgcd4F#ZBdIXUI-<(k#fsoCc{5gPLdw(4RPBekgJJ30!v5 zKW)*|wE}UTUjBchd$BM>8#-=qYjx9cwm*1lk&3Qc;8@eR@0(4`3s9{Q}Nuv zk63ymA(NJ(@d7(uXI0AvjJO^qES^AkojcSDT)H{Se~^1LavuO-6IQRIm9a%j zwc>S`|J9FK|E9?1hDs|tvlapNRdfNb>q+#p5A*9K8HP`=t0P60O|(o|n`4rmjG1UhcsD{$_u}m zj=!qAR1B-|71h@Z@$vDA^mVK7#V1gZk*WPz!sa5w7n89@C(4tRb^cr_(M2SM5bvd5 z`c9e{Xo8GP5qohSCx3XqDi`HEyR?-cH}<^u_VH@e0~m-PnQ$PcD#S>c<(=$<>FT`I z+ArS{q`QwE6^nXj7X1zSp{tPb^lBX*BEZ;LO7|29TrTrva@uXr+$2O-O{17SvQ?nF z{&~p+;*E<$SyUYw`HgoatzKd!JOA8VySqZ!{06+ zSa&~u7R7NR$fd<&rMw#}6fmeR46*F>iBn0UY=o|djl}ASxLPW79~BIYFD@2s&v5jE z6`LO<^xOykOtscQO0JK|w)5W$J2fMVys!50QR53yuJ?AX`}MhIT3rUd=81`}2@+9i zlI!U|0~|i*T`{b@Ds4B&Hrg&CfnisKJLyAQ55!fb0w&2;Q;hU<)fel%J+{H`HVQVtU%~CiWvPirn)=FQ{$_U^6Ua}q2iE7wVBU1C+nw2gfiTS~j zZ=KWD_+2&UU^A%U81^WHjwb(+=ABMPutXYF#fPRr=3|057ZR#D9=Y!t#UgnD#1VuC zm8#$#-j#A~p&E@TRt@9m>!{ejoL*~uhN_Fm&)wpAu>H(M8Kl0MHt)id9|SnoY%DYR z%Fe@P{7&w@WqV~bGsHA37?oPQ;AWV0EGMv0rlsPy?NI_hEURn(vDQS?MQt1 zoHhAKkx)SEE|H>LQo-X#5hLMp4_|PKXaa#6lfd?!jJR=io495Gc!;w9&eTH0 zY;p}xPo=6b%QjQOPx+1D_TTv~uOM3|%byWUe4TriVJ(Fx&r(A|(GBs0)~ zvzt*vA%`AHT-PK5i_huV`C*->$E!4)xW%?&<{ zFs#;EugrE@$fsvAX^i~!rCkIWhA-Zh$5XkrK<{)1)VOGs^tiYxsLAH?bHKU27td<> z7cUc~%+GgS>{hLbXloXS{Bk~`lhznamt*VYq_tlhe{-CrjA*vy(<}rt-6|rrzORmJ z98JNi?$>T3X%6{<#o>gqPsbv%X72&TuJK0q?$7gkDMTmc?N=J%7MM7J1sRFA)jI2K z4ONWuROlTh#zGAaNPmA#cGedgf;gk(FOAHspjG>*YPr%a_lsDE_lP@jR&Ikxxvgie zXw>iBl91hCnO$~Mmrt^>j|DPn!!4*eZSo2!hW5sC@a6rn_0ET3(IZYNji zn=m+MJo_G*&lLp_&;b=KCCvxe4RIu*$`VEvaq5rxXIl5f6I`3|xDpS~!^MDXj&j^< z@o`Lt{SkhZR-ZHhf1xjunVai!3c5<}qe-5Vkp0qJno}KVJDn+-5O0!h6%)BGRi8=G zL-{;+Pj{?v30I%TeHl>fRbY`=R29~T7Xl>TVR-#ofB<0z7N(Z`jp6)7kpRm=YT zom^jPetyWMsZ*Z3=~o5K7`tT6ob;==DZ8?=Gb`LF-c|nU#;NS%OVdslS(}ai1d8Ss z_IirQ-^&eNbtt;>bXq{%)A5V7?qn3|G2p@Ox2GlS)m*Ihq2qC@^hvQ0NvEw}`0J5} zw0Z1P?fNS@smYr)nm*&e?~O9QzMOnaXim~IP+enZs~Q@ie}By%*RA<9b=Sd6LS(+O(%~r%M}tCW;6QhuQWvJFai=h-SzXM zi*@STZORTPPA9~>iJ%luvwsVJiNqHZ#OoNJ-p9 zHmsuX3j-g7Y{D5$}m@59cCS(pU1wDj>;`xn{?Zv zMIKYw65|G_ts(XF6uHJI8WxXdJV32Ld&YmWK$)6!{HjB3Xkr~gVlizy6 zlqsKFXQkJRBCySun&IcPlDk^bHq&)a;D}xGww%w@lySJWjek%@)4ugZFr&g@SWPm)17Ro4B7h%kF5E9oZH6v$+!nzB{97e zk(!5Vf$r5p5vO%uaG=Z>r^lt5oUNM!QMpO(oS+ghv`(v5fA)2Czrkym~(P)5$Z-4eql;wK`qe45np2$*w((@v>I?G{y~+|(?c32m=8qI2 zH1ko;#}h~;>?!<)Kc0RIk$)O6OODHb@!lrXDfqq>b^gl@T?r2R**O>f#~bT3E4y;X z^9F3T+_Dcf5}+5H!s~;~ZsFrI?8TCLmNTTIul&i?eow53khPQRc~HZNf1FF! zV>u`x?U-a1e1ih97_Fiq?ibF+0nckwDSxQps_-D?8?p#RfOYyQC@c)THL9Y5RHE$f zPg69{Knfc6{DBs@(>Sb+$?E1aJ^?`hk+|3ST7tnuE7ne!?st7jWPAv5zj%B1=D6d z<~0-J#7Tziz}dx5X2?+$NmJ=UsKvysemYT^8jisH{cGJZ;r>PV+q$v$1A`CJ3!)bz7y!M zvQbp>1u4KMv~9RKtFXxSOvVgI0-&nj{4ngEQ)K%SC;k%Qv;Xc^GZB$!`7~;BHZy>j zQp~ua)OGb;HWXy#|EeWxRM%_jMK<)A^XnT*#QU&c1f0*TS*s_J^KZp;y-wlbK$3}9 z7VZ9np}BFj*%AUFZ=L%y&kZYA3og_B5<=g;lkaT4#~^O(kb8-Y><2RnyyH3jZ1gmg zeeQISiz2FC^L0i9kNeLXjd7$Tf)$uh`|#o?$F)r%t#~(13c5E)iJ~OrtTkDG24<8H zv#5*Qq~p!k2Q7DyRm;eD{=8j%`B|wC%=o(e?CjdkSaMH^X9pRC6Pgy?d7MD9=?;>2{EC|gQK@6p-pIF+$Z z3y4~MyB2g>V=H#8jrKG}0ssxKRL?(aiCH*{i`+n=HT>5KAChA}r?;G%Xh{8^+*OZm!m{O4LM^A7g*D2vcPR%txfIva!Vxv6(io3MnNfdPqKlj{Z zAA{}H==DM0L%^0#?)v%bbcc?}6D>_m=-Uhqem_YqeZP_G?IK((Li2F$@8PqF*O%7C z?4Z@Wy6s;44)K*+-PXmNKu5I@&jY;SM4z_(3#(9QPJY47I@uHo2Hyt zJbu<*qSRV(CHtcIVumPBXYxx5e+&FE7hYZ5r!zN|c~T%-%W{uN(d((}NNx_$YJ4%@ zFmjo4>T2qG7$@i4Xe7hkJGmWEc4ehcqV&}GhmQ^;CUC-2obV=ni(=AUzXj&G-6#j3 z9C^OFl_I`U)G~1cD^msCb-nM=$5A$?hShYDj2owF4a|DjbaiC| zqemM$Oo+IXs)Zz+e$dqeU1>;E2Xd%`xB8G z`H>8^T-}Owww@rMdh{o3V{4dDVNf^S?$)1%=!cv<6-}uX!{+{pz5aBKGx_7;eUb588Z+fBw0LLYUe@lQ>iB$I=fbn!Q3;4CIK0JN8)fU3_Jf4VtKwEQUd%aSr^|~u|ioRt%@|*&_eWefz zAKHM?NmZKJNN^R|&L$GIZ6|qwNZ#|Zi%BJGI(YFIe6}`k2X`}-S=ji7>eO2w(uL>O z|Hy4~b^I z`A%~J>n@uLh1Nf;GW38|Oc|wbQy5+iW|g>j`PJ2rFI5)$pr6gMyk-DSfc40^b>R7# zKe%S6U8jgCebp{`hu4w>6?}Z+4kFB1(nW3=w(Mjl@SJ+}!rW1`V0pv{< z3D5(gGJpKF=!RVTXHF~x!*MwIxOhu*ywm$C6F_;|P{dTA(`R9*+3aqSsDC*h$V zERmn z!*T@%weS)e6oh zs-T}{=O4h62bjl{1`pr-;_q!;Pq7}J+qh{#FatB*QQhN_i;;*xzN#i(a%=LLhOe=qjoNPuqfg? zLMJ~hZZ~+Vx~}_Y?;BF;WZ&P3#bN!^t&`!!ZmS81*wScGqGodt3swjJh2hDtv zu-GWAUYGIX-a`5|6A*avMSxYE|u^H&z)qv5MM&(M^iJuoGvb#e9CzHEjN4{kn) z;$F*c&BbW|zsw!JgAE42__XC1^WwT@&P>$}`AId7=Lm<*xg@zxvWh>#kL5q3Yi zA<2QoiW6pLy-s22kMZ55OB2O}HXKUyhKcJqrI*@wP?QGFos8h6WxqF>oFm|kTN;jd zrx^l8RC%F+VEsN9{6{>!OGIcXsSWkP_&Hke8`2ff&#ILs62Q4@`Pv0?38;F6x)u6e zM#i7RZfQ5*eBY!i(vku#fSz|*zAL|yM~U%ao0`8I_lF#z4DbTjuKE=m@}=|P zc}l+$ss(L1w}to4{MRu8sF+xuv>%-s&ATm>)Qpf-hK}f3W8n%{^p&Obr5fq53)|Vu zrOTw+WZEH8NBNl>q9sP8lNAy)$=UZbSa^RNR()d^RoY(=gho9ntXSnrk2{Z$KRg9k zwnS^1*)e(OAtB8M3n`qoJoTr88T%@} zS3NjiZLo&!Av_h^JJ679PQU3c-H;2nU5=er>pU-ft%%KeiLQ$xr4JjQ4i$XSmwN5m zSr0d36wI%y!1SeBV+42GAKZ2G7}`h*mF#)wca1E5Go+idB)fC*VN|A=Gc9mV^2KYl zR)_Xxk7{R!n0sBpJ_}ityr))P3*t+acfwoVTd&^^vJe+6-F3%Mm)9g+oOUK(=7;T+ zJO%XjU+j3@Ywn(I+gDljL0faB^){PzdG!y-;?tkWTh&h=R8_xPNc-StECpX-N^SD) zU+8s;w?F*S-w&-hF=s?2wxdU7AAX zRzEus4IMJ>Uw^hA!Yva&#-oJWi!kT;S9e)-oFtMOc0c7!?R^fG1MHMdEX+jPQOAr5 z8zJau;C5)P2>h8sHDqsuoU7BJw_BW5xq>=H)3$^^ixjVl^HPq_) zH$dSU%^#eC(X-UE8MV4vh9?)dJNZwMes8?|74su8(dnb*Y0?7=>iL%AiBM#X2IkWGEi_6*4qlN^3wJYQ>T4wky{;uY!I zc3Ew@*v zJG^eVytm^rrRRo$NxSa8e-ahZQa#1v$p)OJcX3FZ>Sl&6Jp&wZ=%y3$~b`TXdXIx}Nuk6S1B}EfN zZ;kO@?@}NhQy`u`fRGGHoRlrU0o%eHMkUiFvEK|V?PtK=j}~LMqq7`&j>05c!XzYK zZ(IwMgFFQ`7L;>Oj*jlb#WYvAxT@Z6@S@3WcWI}f2S?3nR<%@YutsnnVdz|GBa?oj zrWFxAeRz3;Gc#hzI0bkxfKQh~Q*5Z^Uhr0gF$Bs=B6{YTK%IowO{t1VOSS8AQjpAD z9=|pDjO2%zU%)7nMEO&Rl;OzITDA<_1~EXD?P0jI1AEByuEb4Qu6oAoH`VVdbVemh z9$Y|kU;81aliO_=8K+D6^8!1`d0ns%VVjbLiwFS5bv1RPF|1MNx6?J)5EM>cJddgi zt+@nSJ2ebn5HwlFKA5VT@cq`*JtylL&vIl_%sbumY!W?Ztx!k*GAQ4b2MYaK(|@+Z zF@-_Y`XGi%ofh=rOD7MMPI2&@*HHnFM2~EiV*}BGbvi8;W3ctuy}_mu**8rY`!b&i zJ>VJroVNS(2io7&p^V6r@t?NH1f#CgZOWLK7Rv=%O7vjE$=B+@sb{%TY*B)e2kLNU zt{ZE|rW}t_o{|8BfbC4wP4%d;TLVf!*l?^796OjUL1ejlc9tklvHX|7t6Nl5CQh0+ zgpc2mO0vPVI}Ya#f9~e;dEHu^+S>@o^9#4=V#6&I7W_{OAz^~7F9-tixk*d7#7tv* z>hBEhFR;!}5_46fL@+C=w89$}9+Q%gQm}PhjTt4gum8AR4CE5-GI^aV{oGixWhI>E z%kR1GQqtYh6W+Ws;U#&!5#~~N=9^82y)5Q#-CyKqL01w*KA;G#ymD5`yZg~8CUxb^ zeJGdLlGLOYeZWiX?qFE?h7_?*Q>)ED+9q!@HXKv?SGoS91h2Gah-c~SxKbbY#HN_! zn8y%KGhzQ|rejXrS^ta^%a1Q&eW*F0SC>C+QyY(3;JZB32M783JOYv+Bwj=2YParH z%j-{eP;YP|clH_rQ$#HfGzW%68UhEEMwVmKTu@eovt_>U)$wH3nIi2Q9GO5Qhw`Do+S4F6F^Aq_ zac)s-RJw7oy#D%|%h36yN*)|BwC zv-wFe16{Z)OVO8akA1wr@#U9{)-s#?RnTX%%odQ#*6Y>*rn2p2 z$YHgscCsVuvX=|A26g2);~Uyvja$i4a0e>u>(XKZ+-*sEZ zi0mU;xJupbfsx6_K`v<*HHQua?w3b9q$LZ(X>g`ti`ryDH*bl{>~QH(7b^Qw0lUuK zfwTZK&Ekglm|0<7iP>E&d65fMCHclW*&1eAZ8v&a0+!c@G&>ZaW3AR51bZcLo>l#w z;OfLOT%}8qVQNpY?rosYsS24(;rH{|Pg0_=Gic?34_NV2cuTrnYg*&+7~mx4nkM+&`~cQ1{%h^3qQ&BU99on~$s#WVy{iAl6>{7Skf zCfs881$#MguJ<^lRMTlGA|Q$S1y9RGe(H{Ah&1!3{I0wVC{&c&Yl0X|UOZ9H?S-tu zPmb7{a@T653YUHnbVBhIgYd{K8J(>y%!oBA8ujqa3p6i3N6ZYvkA`OR<{^*pd^@_q zBKoP1+WahMBRzL3*ZSi*lPZUnl`Tx7MI+PQ5&P@C$y^;6@hjQM<^-0(Nf5IU!fv&6 zGSc-zyJI4oIZP+2*0a4P+;tSx0Y2FzJL zgjk(^#ZR&`Cqv*)m?FDTkBr3QsTT+UD$H)S#phgtWqRAeBtO2*c2;;c6hji~V-OFt zR!b8bE*1nvYeIIu?eEdb$^k}=PN&`1mYH_U;VlDP+xBl%yN_=5wibP>r}p~k+al+& zLXp)rj%+$r^TY3{0W((oZ@+pN%v$vYDz0QP}2Voc{~h%fKv_XVh%dDI-iCBt@Du z{k{9sV`Tm_qWR0y>B{$GN2jfVIgi3n&!{JG#h6Yk?+&oZ+t?};Pv^8oiaV%zVf@Lb z>;~-n=eYB*W&uDkiQM7RH==%3M@Q95`%9h0A4|?=fH?C8wu=bfyR&QDfpMQZ_Al=@ zy6O$}o7i+-N^pZ$%3KzQcLC zyg6+(H63-iPOB+4Y>EN_rlm`HwYncBp-_Kb8}(qZFlvhhm<0{h@V)H48RT-~=vWa& zVmEt+Bz${i-@$X8u77o6hVDnA_+GH(RvP&yU&)>aP$h2|<~qN@L_iU?Fp(15sel$Q z99`7}cd#Z?b{RO7Vft;=Bq~G-Uj~3*9h~zRSQs73^B>Um*FPCBYS}-~#rl^^%thTM z#=B70{>N&nu-13U-2H5ZWq#+C zI?i%x^cn~H4nD7bn^6~4$4^V6kCi-q1z$7Z?6<$e@bsOVLQ`@6lRR$B%EhX%-Z?q{ z@8CA@WXZDTCO5%vp`P!zwGQ_z5+@^!`eb~(j3P$}`JVj_!t-Uooq&G7=!g6(`QE*M zg`DAE$p0}9U)}nb{niikKalvJI*OVXyEqfi6VQ_3;SC=C1RfHD`6;}f`dMgo6Trpw z{VHW{;r-1!f@_#PTULF`raR6POhNk}cIHo#K>A}&!G9UQ8*xr1K5Gy9V^nJCAkQ9|U+;=>*}=()LW}w)9u*6R3(M7ff}uwY~PG z*Yq4S`qz(-F1iuw=WX}MH(W+BbD8Yey4_JC{$9aupE(7MigP~(0X~c(BW@tz*UckG z<$ytAoUZvNafxGj-1`cuL$utHRfIG;BFk{6$8QRUMVm6mm$;Jnl|T zSJ6>O=7><7p%vHi2yVEw|LH+_oQeIDAM3pN#U*(H6v|3Z?RAb-X&0>18njr4$HD>C z$7?s*oaU06^^M~mZ!IOXHP~-0QJ8DvNbl)q1$GTWlz5A7R)mog!FNRF9kV8hsugq$ zy__TstO}ei29^Wj`cf{X=cWXNBwoCwDQkW+nPklYqm4O}a0vCho3P7Dw;#~KM&fC< znzb}LA~gnWkdX)fd?Mf$b}gsYDPGNngJoPf(OCHw(S0NQFwj;+-Rjb^(%rotE&%@|t zk*H6m88}Y);%V@2UqWi872s*PR@aVylUqbRw?swWuam8z7#6z;&h&bQ68S_S+FA{b zK15J=>ntY-Q(#!t;Hcr?bD(kI7ZJQk_afl3$nR;eC22AhBk;3$+2hgBJKcfE5mgXl ztHNg7LpC9Gjc3%?+l%oA<7FB<3e~>$Z{-!5bwRPP1=>UJg!gQ9t+jQ=aXb}XN*!?9 z$F_#qkBp?sq3(Y5twxDn^UPy<3v|V=Hks$ige!6jyovE~nt|i@{Ii#mf=z?x74HTy zIF+vLjIr?I7e9;?tM5tH;wU!~%!PPlYuq+ed){PB>@4#O)v zdUZ96i$inV0GS3E(1lZbX!N6Z`UO4Q8ba)_old1ncQ0cF<>UF>`%8@%iDvHv>>M)X z-msQXM7ezI{MF8hu9w@d?dZl`=s3e>{r2dv#9mGDt-LRN`?rPm-r!Unjj$M(3#8Y7 zVImX?_1YoVGc1L^b+)k&gO=8doPuU_nyN>bAYWEiCWy%TEVPN?iOIdbCi_Rji$&DR_!SJ0phG)VF+4gh?j8d zk{qxNFnqpju#i4u)Muc!ZR=kCMZFO48Ti?4&a0EwT#N>(x^z_@`Qhrz$~~OIl>Y6J zQY?6-S&ndPhQ~q-;vA0`zl{&g7PpG}QY-q9-n0)Ovxpi>NrL7@D8tMME1VbmEl$1KJQ>J-Hn;V*yHWZyC)Zsj~ zGnOT!D$FwD8QP_zW@SbEQ)hHt+;dbo1*`J=3@YS@Q_gWD6ga|A7DDEVx6Tlx&Z(ZZ z5(`9^!;9Ht@gh4@1L8919;S`wtreTxhI5r@fWOYoF<0arY!1*z7%}NrpL}yNg)MUA zy6&`Zvjc>+<8~fz0mvBh`f59Yz$L9ZU$~L|(rbjK)8AIq0Z>uc$kvOJRF{g*Lx@Xx zgo?MprZc;G8X^!x9T}Er4e=y2GqTcxR3ZWNleu;S@Ri6lO*v74+FZ1-Sj=|FNgYr zYwPreI!8pWTJ_C5ZtNA}7VS$!v{`_vYAt0IbuuZL(LajB000L%mtDSl3)4)?(%`hx zUk#46TPXS+@LaJ3x5G(zJ*H?erRgiQ!$4dAJo32CNOLX(DnvL)db2_|mA@7a(amGu zwuu`mpVIqCJ}F8h5p)aZ(bd3pHGw*9@rio@MvrMHBdj4a`!-&t$3?4#V`UKD(kU)c z=fvFdcsCaIFI2ul|HebyW6x&w+e-8wK=*I^!8Uf{_e~j`n$N>Q&Une1&wp(uyh2h= z!EXPF|6Jhz4Ee7e!9PA;KYJJby-vCx^t5)jaG1f8xvhQNN%zNhjhF69A)Mku$n|fC z1^y?*{+F9r^50SaujS!(M*rs}rpSbk|3GzbZ*$K<|8%cKE8&QdmHBsUK@0kJ_`Tm@ zpFWDJY6!X*m{l7tXSdRNyI4#r>azanD6V8-y@->y>Vi8=4>3VF9*O8r0;A05e>Pwv zViQB2`Ax0ns)yT%yO;7PPFJq8A%T;N_yK~iTAw1E4t53gDWlV~t}h+?*S&+F&98)-&7;k|ZIjIUpW{Rk#;Znwbccgihm&vk zfd{isd?E$f>Gtj92NAwSfT*dU?Ixoo%A3aVE0hv0zDwCh5L5s23bjN9@W8tIoc_$~ z611IiI}C}D5cJbhW&o<;W@5@BWd?Tc%I9@B^lIfXmLKU*xpgU(54|$c{>i`39(k6~ znTHBc1e|YFK+6pGlU|HPWTXKPK1zcU`iB7-L$6R*Gi*RLUZ99qXTAh4>LNo8bd4E; zDkkuA<7h)QO+9QtJEF+9p@(5gFJ9d!t1|%Yh$HJ~Ij%jvZ=Fr4Vy!`-ZtY>7rw@F!f}Uhk zN#7qOka;XXvOzCw;T+s^nXL=s=i`=mh3Sc0;{u#7rcY`~dv-|Ym z``}^u*&@qY&>-&1Q*2bQ=kQq@%NoH)7}VR_&-6#ba-#5B068ux9W5n2nl?NjUKfxg zKKq28ZWSOi%!4Dakwpn-6D4?cUYb+iXsK`jGs1ZEC;NDjf(UK(-(o~?n04+R^wd}1 zP=AX&s(~2P6^PApABOkKM>K*>k^WIUoZ>45e$?`jlOa7<_a2RYculvD_M`5Pz{y|k z5vg#dP?}Trm(&8Q-j_U=+n~fGoAK#dgI6U@hytBDqjU06U-aStWkHZ)~QbkT% zflZg*1WqFNv#S_1T!2-3O9hkPKhrtjc!7CEA^@Eud-bnc&4(SY4l6|f=etTO7v$+Y zI7VSVPVBu|J}H&C7~ z+_vz+9`ucQtS;>_ui9m9Quj4jAWGmTv1!60ir*g$c7VA#W}0+YTJkM>W+XO+9h6Pk;P)4;dNkH_BXKmd3poUb{4- z+XeI@+3FzY?N7Oe`voo6C#Uk@oLuJjz1iuNzYN{FFL5-^ya!iTqpXqIDh7hP{;vR* zWF+-xQS0FT%EmC_eh_0b`2A$Y5MZ!-8+}#r4s^tMTk^QO%NzeJ20B zWa5rrxaSOiTkn5gfU^ESSBu+nttSO#D7^i4jU$(dx6#(RVJ)p@V+r|x3jK7K^Xz*1 zg2jaEg!MWThxNZoF5-7${-D71r;Fb-ZQL=w00*B*UDpgv739~-dA_&C-|Z^D6h*q1~40@a+Ul~^%lPrRY^#8*Z)xGCdrIc?qb~@ zWbO`0t-@VR)e5&IbGRj-3=`kzX}ZS;Y1%PPHu@DHZQ&`M+8V8u^2GU;w6oK%ni$I!b2n0Vg-efde??pVxTk>tLMxA!Mpo`{rNNZ;E#c zzMZ>So+{Sql$M(w+l>YRMdqiIIC4;`WbykV*-Pm_H0YVMoC_3N^h zOgZ%rMd=0%>F5cd6o_V`znW9$JOamN$6e^l_uA=gk*YD1L8quSOg#s7cfl{Rp$Gf> z!NeeFY0trWavzZyn*G7Mw)Z zKIk{nGeH;^X#`kafEtFq`%dv_WV#i2Y?Z9U#S1TL!zY+Nd`OC{Q51tSAnyFLMYC_G z5mSbct8{MJTCV1)%S;d^9V@#1ZDEnAxulzZen@!kXl6A%Ci@WaxsSM7{;}vXd7kxS zJIRA}TQ_4>3+a&9RYdCmSK$K%chTCludi#zs!F`b+TDmB?quSK|LpwWuFG{A&Ic2w zIYBV8?t|29zqFOdzBmWvm~EJNbLnO)|6}vSkM`UyH62m4mz#vuGmA7poL;$0K z0){;k)-jJVKGuY(K%d4D^^~hIffa}EhdznoQ-CLVXaAcEfb(GtBYm8`8uP5n&+I(Y zyuneA63ynLy-Ju%&8A|Xv}l8$PUY6^7Cr%-9@toa)^l)^-sN@p4E)71o|f)nbA3xI zqf8D1!3=V3#`?Va2`-^3O>P-gVQN>3Y_(BOgucCjX4o06oV_>E=z2R(S?*-lQ%U~z z?}Y1wmU#^}ph?!XTZi1`etxTs1zury2JzNqGZ$mQTS^t(WEOUDT~}2OQJKR8i5ZjQ)ZNhmCeh>>6J4Dg za&#aeGc)^_zY0F>BHG#>4ZL(3ehHUsBf6E)9Z1-llXpMjfk2E;6mjR9rTB0EXe2z(Z+=Ff4WymM$Xu-aowKkg*oK2P zX!Y6hLB{Bhol+WVqsP^!m(c+prPw#S8zA8Z7$4V}tlEqR{R@d8=$YM+eK7f4#mg$6 zjnKC)`bI@^UY9D!PYbfpT~9n|d;nlZEOFCggM#Ltvqc+Z51)p)H#n?O30|%Usjus+ z0qn43YHGPBEMwapzwjX^HuUa&Xl!Fx;7MQz2PYZGHT{Q#Af$W8L<#iH zHLeilpvUA&{3vtd{q-NUjF)-u!AA3<{*l7qQc)L7tB7_@%uTVl>T{vZ^K=d`<4-j! z>t&Cfr1%G<+)fZnj`nikz-G&b+u-FS=gYstD;fkjg$prlZ;9=VoAlsgTSKC@+kEkqIX9N7egUV557YMx9v z5T8PF{2)p5n)yMp&biIcKe+pyFHbau1g0AV`Fs+-!!MpT_1`)gA&NpjS^xLQ#m@P5 zN;XSGRQbHK&9)mc*PXFj_L5eYrQ z(ZWh{cc-`D2-WM8_K)4H8--;h#ZAzU;%t=f&4-4phpb+z^8p$}N|TnZQu7Dnn!6M% zw%P>Me|0f2L9Pv6VbBZto)?2@-b-}%=^9{E$Ib0ZzSo}b=_k*WNU;N;XJ zp2VtmrW}5;X{${znZfgXSX_9H4k`Tugm~8?>1PWe3k$A()7fXCjfj}Y^FPpyhgWg8 z=O0Ts-g}~dPtrE3zy2`^<9*`)`yZ^w!?XV6{pT_f9^NG0`9A}SS90s%pMM6y)5c%@ zZ!#1j#(4z(JdtIE{*Vk@9fHI|;03sMjFp$BTJ?zp(VwjZ4zxeN{>O}u_y3UBe^ zN16&lAJfYYbK8xOC;^=?l0uG&QhD$i^ZxHv`2|0JKI!eC%ivedm^tucu{H>VU+5Rq zuw0f(oIxDxq@NwF#yUt`r9>uHV}r8I?slvArO^1wWT>vJ%^Th5t_p424F{%F)!oFF zokaM4(3jK$T5(CbFp3v9D?UKBIy-&I^XgF?~{xk@xTI= zb#?vTEb2Q;&MzIC+t8F6YnAct~IQLTf$Oe;N15a*!alT7~rMb1O z6_25?OVNORc@QtvF>?&^{VNhcp&~XuTGQB(mIOOc9ZVWD=TJ|8S78`GoXW1WD{1)g z$wjzA>NI9M<=b|%fn+{;4z19VgxOa$EtwOj#}+0#*a^l^P_DeKU`%)yN88_fTQt-^ z^^Ng=)%KQAacteXFnhD31ZfB!LTD^_fZ)vrANE6)M zwQ+~WUB2Es`#tBr-@W6Ed+#{6NByW#Rb6AQTC3)K=JU+8N|4{N3J);!FlVT9kw~?3 zgcmnFz3w*f5#g7L>~V1BoXuc#f*ajy?zf}2Zxa#{3+m2VgaTF40MoZ)UpX5}UWfc1 z)Di4C>m7`JVcLcviS0`zv-gebWFj}+B?BWE-uEt~v&mRFId{v1GXa5dOn3YJ5H5{E zxgAR4o6%QE#;R^F0D&UR;iO@x<$J)lqzUc%&oBlyuBWj^XTa6cyj3s>K-^yHNPB+2q+7c~4NDH0>%h}1M$g3{bH%i#0STx^0PGB=j&w>e`y1}jIT>*i-8 z>h1lPSHm_pwJybmf+fMz*Hx9(HfOibi^3Rp(mscO8e{i5PB+_?<2sa$rq`zO2!7$ECmI3%a*QR$+Y1+(*f6^U*x!$p6u@JV#Sq@^KC32ew0VQP9nUi_uNH* z3es!T(Tl>gIvZb@m$N*1Zc|{m`cvRj)SKt(&Pxc$a9F4Niu0r82VvX8eqzyid-dKm zcw4cR>l!}jCX;r8Gn0wc=a)C(sj?Z3n73u}&qV3y{A`lLpaX6M&@;;7E z*Y7V%X@m%#k89;Nq`N6gf!hz&EE(_XIGFBNOT6|SLeV@JV3m54(+=We)gF$n^X~|_ zHV66+?V%$f>S2;HQc;gcsH+j`1tL-n(L@aNOWsjFMu)lN%pHWaZpUj1b?(o4HACn- zlzq%yXnhU0xMaE`z?!N%}4zHFoF!BOxjl!7hsg`==yg$&K;870e(m~ z>tKbLOk3o`r+^Eu*u!FUc{;M>bkWRUDArnib_2Tx6IUI>-9&bz7#`S|01(n@r|bl@ zCB;}}N$K3vg%6Ox79Wep^c2SSfJoO8BNp{h>K4QoQIynsZFI4ghhfS~8ALcg#1q%_ z^t@A`R-+o-=CziO5y)CyC5G4;_v8si6d0V#zY*cWfwoGkX3DOmzeDVGjxoVIP2X8p zgMld&6VzB59CE+o4M12IyFq-<3sx$}Jnt0^z7eo}Ujjl{KmZq_0FlWMNom{4%+C0m zo75d^y-vFftSo3=!qqFBpru|s`g+?HY{LWSlIQ?yV6J%m?;?HRokAbfZNit7=VhY* zz{e9la(0`}#BH~7ilCZLQpwZGvevXzYE6XBD0JT==FXBW9WK1kB{^U?J$q+0U&2F_ z66$~F)rQeZo0K*Q(=BF1a!WO*ZWPxij@5I;aRf6Y}gEXiBF`9YYvClxE*hXJcj^&N5tkEqJ z0nqbu&H4BFv)qrERy*7?3Ssz>Swt`CfJ?FrK;Z3Q?s^N&^Y-XcjT>Z!-Z0gygiIvW zj(A5p6-VnTXCpH&EJ27 zvoK`r=@d^$EmCjQaq#H|Z7;gM%0eEa>6w=+ZB6VY-9}KSS)9Wn589<*o z`kp*H$l7FsWR0sX-Pd>k@c4*~l20pCz7XA+?DuAIPbWAu5+nSL(A7d~ZKX(5TKNgd zk*5vNtm#4&73>btV*iGP6Pnq#v-4TQ)L>4OAE)tfygobkLBr=8JJ!hBDsTU?Pz>p+ zl13XN*e4}e!6Vt(ZhC4iSn#uNTP{bVe(q6dD1L%imDZ4+WvFt-AY4i=U{XPM>^%@> z{SiR|Nzu!;Lgyn_w7o*A>_J*6=m67Fm~F_pC_&njYEPjHCUV+9{XtKR&t2i7R@KGM zev_fV-KyCP*C=LmKCFP?nMrW1qq@#!9#f{42PCAlX(Gfx&1daH;!D}wE+sZ(n2=|H zakRgeyxp{6$T(Wb^c|@I=W3ub#o``@v$r8V%dMGlIHN4RtEeG(;|b1w=XOAfYNXmm z?)OLw<%~X#qRw)DB9)B=z-x9NhYkE~feHhCFe9^jfwk<8_shpIltS4lyUHky^GcR%9uS|C1!h4dJ2du2!H5( zNGY7^wl}&bimPXeSrh3b6&R{}Fde$XOS(%tGg9>^#;^Oh66BY`;fA3dpQsj1f_8#) zO9f%fdJ3W;v;I5DZyx~PfuD2>Ih-CIw8*1hdfGT>9U)^sIu6`(8SX!$Ng`?irN{W1 z+TTB5;Jh`-k-nTEo(fW?82Nz#4=su@5=SlUzh7_Balh6*pEn^kKDVSqT0Y=~GRGo= zWxDURZt@EAcRL*SB1a*I&u$(BU-G51*A=V%fip<`16!X%lUg%-MN1hmof=yrc{QNf z_4Xb1A!tI4!jIqkRFerDt48fzHd!mHUBG(*rV(F zEA`OkQ*0D{`X5lfF14{5>A(CdmB8_M|Gx{k|F;vB|BD+If7iMC(eaN-?^$~PBV$^a zoi=477C(3V=bX!6$=KXQdvfDHna=-BBK2R}_Y>xDr^%bQ#y265B3y-c!S1i+2eQZv zy!pif;LJW!INFWuWpcJI{y5|Ke9|T#gr}D)L2Uuc!=lr_e>EHm+i}}z6lM4+eWf&a z)o}Sgj-7+@%ep4%asRPZ{hc*}&f1-QnCnz?7m zsaAJL$1We;@JlZc8~^?9AAaR_FBR(wEw8kHnw>ZU6sfiZJ)tINYOzgtmE#RNBEyjD z7eO8(Vh)b%Q6mO1yye^UP>*^Lm#e_p)vHH;NM3^(Oh^E#Jp#q$FG+CM>Od=RekH@R zAjfZ~wBp-xU|q@WA)mfRHP%STXi4gLu-Tij-CQnCj6YoULb0$A#atx6OxMcQe*)^YWFplD30ZkuSl2noh!n@3eme z%lK(HJ<1_}NX&f6PV@2wut7f)(7`8gLIFKCYa)cGyUXZm-aqeB%uF7N}J@CET+wO?eoL&xv4f57O5SBfv( zuCh+H2{g7NN^cDADP$h((66IwVDldgVF;&nO46v7&@C=M3`^7{({is;Aod9tQ$H5u zFR7NpBHiXa5!hgku&)<&E!XL57HRKN-yxwN*-n?{34(AmZPpDhz?{3uC(1` zf*)GrR{(lEMcE^MZn6pY0_IyzT@L3EaDx1Zyl#CPb)JnK<0sq$tG~U_6z;p0+270y zpkCS`6-bN}5iIrXbA1sEGLzn?#k;XUs@X~p9ji0>Sq)x9NvIV}lkTxzPk83{D6*M@&$32!~hjXNmhAr>w zn}ve=LiOmBp9E>R>{|IIbHAfUPk6BZ)aDnO-7wq-?0twJl(xaU+z$7rzqbn&2qFb&Ee z&Uy4;xT&fg{*3LB8-)AK^KJX}F0+ovM4{CQrU{Z5I>u5t@n+ALOTRqtF{^nca(8K_ zlsR54sOzfsA@n7;M0;{Ca<$evt@_m(M0sL>W}S(&LWuu3ieduIqfv?gPhh)KpQ}WL z325BYW@`ki)->T6o#->18@vsVWF$bH;N!r9lX>*Qz3_9$@kGC9rL~C?M#A(*2KA`nmt zvAND~b{h|CRu=x{**v}&6xmsZ)UxG%HAtTIu2n{>f# zM7XPHEp5sAEJM2tG0qGjq1Y^ZS!n2nl2QSO)A6c#R-tw&ojr{t^CO|jy|`l!#!z5&J^7#vUB%9fN%+2ju>=WeYOsFggffDYh6r;izVS zMm-%fS7(~Q()b4Yb)s>`*}1X(?d@mo%CUTRu>*2cwi9vWO1~cL>;vgIol@TKuK8Qi zOhP$+(@9AtpYjHz1&M~LI##J8N2?M@Cio~DRmyoO%C-8PY&I^wMcy6hc}7gjg75KN z8dzw68CIr^)Mx`zR6o{@mDA zIlsHrop?ayFp`uwW-eRDuqTc!%TT|B3En(l)b<4NC(t)+aUr0B5tNLbJw;TmB3$Cc z9?vB85{Wjy^W zI1zScmIR6E;DZ?!DlU-^=OdldL|b9ImotvIxmc%ljZx^{#y^Gc6ttMp*oD?D$en3C zC}Ju{X`^k99akEKyOE_?S~9{7h=$glfW|#D^o*M^9hT9AOU9LMaF#v2aVb9x`Rz;` z>GM+IVxZ=VTfi3U-R;w|(PfVaPl~iMtmZoslt;?v82>I#!NJ*+s66E)`?_^=goyg_ z={VJ7Pgw+D_bbfofvo!w^(=P}GY)?|SR~)|7rrzi{JSa{XQ8}l_`B2tkubZht@k~s z8|h!o!$FvAUYDlD`=YAkSnHGg)cfvp$z%rp0|;(@#e{|BV=e~p#?lg0jMvUpo+E*x8~VHHj@9q2>-H)<;TchtmXF^U}_ zZs`yB(>4brGSojTvzzOA{L^J0XDX`1b;fL#rlY53rw<_3#o#|d7KPiXiefx(|7n(; zHg+Luv`vZq9%oaTQYm72=7)AGu=WxZhJ{XH`g!SJ-VjqK21@?Z=pTaU=^xrHxHPp> zKR@tP+G4NeiA(9U;U|fiQfxKm+YT=#81D;nt#WvBrr>w5oTdjl|0zI54*0ugKPH&O zHuf64^*8}^w6}EeGYwz#8M(#oxml&389lmdTev&$XGr9PzeW=SqDJP}7F~V+07SVT zR*-6NZO2z?@iTKAQ(pdf@M~x}5PCEj`YR?911Ryy54Ta12It38XLky*-t*WQGw2dj zw&Igy%)FY(PQN67G5r;m z6b-+XP#VC;xOu(5Jq_VeUP_YhD`dtL@KMASz?VGdBX-N#zr!nb9LhIWW732 ziGARffVO^vTU|CDa(&J@el0r!SMLiXODvGM?FzHQ4FuP&*@6=NRDW(@K~v)qbBGfN z2pmC%FO?Gr7!Ljry)n>IbbY)+9K&*?Jyr4g%hZj(Kw;LIR# zz>M)CEK%jWgUC|z`g2@u`Glp~tcV}x#Tne+va+x*5uP6IMn}i>t}-xQ3^+9!Feh#XUckQ| zmb#>ZxCDm+x4!HB+KKyy9B>9 zZGo?Z;?0MS`cKNa)W-4IeEFsLY}if)%!|s~vM^+mNR6o3k~NSeZz!6jwE55IuW_TV zf~!)U>UsO!9kh|79O>dD_BTB z8oR(Jhsw(44&CY)50VHB4#34Cop#LI|H4nkmf5t$Kfo%cvT_r`QXcg?Em-g#)pH%- z@~TvI&M}@{Jf=b-PR9iJ&7qJG)09sAcQ=2$`pWn>xJulxku+Tv8WhURk>j*!xUJ7W zxbg{&a(?ub7~pPNqNw^+c>Lh9Z^qRaW+>>ty$qv+9afGuZmJZe?TDDd-J|g$bxOHj*IHLe*vcw7BNwlt`E9D z_=3y4+`wkwN!Q61?gfVz5EZ`8@FFC7uFb6-k5L-gY?RBJmYfK}v)4ZCDHKT_$z~p& znBY&BJ8zKjoeubJ;x&^6e{l%3Wr;*hbD(fr&&qx# zq|FO`U5aXR*#C1XmbMqnE(M)n2Iy~Hhwm?$(5S_RF_9gnx7JexW~^7c6A0S)Dj%Gi z`f@l1Nqdw=kP%lG@%5$omuP>bUviRe^;B_Wdgm&RQ}7TSQCnd~?VM!U>jQgbo^7o9 zFbOKV_`0p(!$Aj9dH%3^WVM>HXth!ECFN3>6mLQ8$xfBX--GARDBhKLX?7My;L@ar z;8c4ntL78yMyC;$W_NluxQFweG1g@+;L~gzDo;k#Rmdo7vR_vFG!=}QNym1Axrgky z!3_V7&OFkT+1sqF#@#+tkh%)Fdls*HCk)}PocWwfPIdc7HlEF4r2aFekre&oVd3Vb zdss;n+uOem;2<`9Pr4Eh&n}j8g2jFTZJZ6u#C~-54m<0S>yMl5dp5r=ts!KONZLD1 z--%`N9%?uq88qE@YSsAh>*OFVy8)zIFJhD&Al2G zpZ71ZdqKSE@*fNKlRp2Si{bw(T!Q6_T(r&x{$W@=p1Q=^+e$S*01^DM@FT&V)h+42 z+Wr4RpeNfyPfvU8OdbSDyJ`)LkB)}Zl5a0B+b#zD^Q>!)EKy1dB6~YK*OMlT8RFLb zX)3u{q6v<=FP_#2is*T;|6^*IcB;Jw{?`7!gNVpX8Gkgi&G+W%)RfTck3^2YQ0#)Z z=bsbk_VAGY{{HV}-#uRi|AM0*8>tl5?J@ej$s3=8-+4E&mq`nGOI7-! zUds0Q3wQWoK>DJzr?S}f-X6Tlv()pG7lNqgtqEV=Z&UGRnNFKA5V0K5$)U*F9As zEWJWXEap00gR^;Zdb8eBRHZM|W}*g3dCF;z{VA0XJ|VQ6`n&B2k@=gpeuMe8s!y$$R(KE z2vcB>$V|p}`75iFwdSwx;%QV4%)2!1T+^2ap}4Uu)@%4A001{*2g3H|L|=|x^4-91 zj%u;ep046H9}O8jjL1xQ5WehWKOS5_^P`-ek5BB~(%8-Qpy+Sf&SoWH!$emYJQ?zP zNcpH-N~pb=1F=_vhrx_pNrS zb88I`th}xnV@CMgOs&_Rku!NXQ>)nNA{)35PcAC!ktY^@+Kqe8Lszs+9waPLC3iOD zZ38~;k>pw_NZ+~q6A}F+#Vs38CEGO~e$sTnFKXz6$F=y3SrLjq`1f6m@nsRG#WZ z`Z)VWXj@Q}dV^!iMcJy{y^}$M&={`EUG;Y zQn`kp$S9W)O%1C$J7!>hS;Y|dpNlV(M7mcaoqFagnTIts$GFAz<-JJqUm?JU;Nhx= z_TSaFXt-J0)zbXSzCh(q3sywh2NWN=$H}kWboBdh{^`lSDk?e6W>F+cVwm#!rxI(z zl{AQyMQhEREu;|k0wS<*p|vcjpZ89tQFZyg>^7^2SVlslKiml3pb~z{@o!p>0&!0aPy<;o8j)+`gVeH_=oMo6N?or z@|#a`X5K}lm&S^1BUrPN0qahs-(giHLu|llh&)&y(fJ{eALFCr?u&E${P(g5aA)Gf zDU|Z{g`-^abP|kd;IF|P=^YHvWSnwjz{BCLV* zB0<4z!oo^7ge}~^+gTO*vGa$m>n-d(Vbpce3b8a75rguvj_}(*!RqC@nfe*}AKp4o zJ_ZF#h1f~9fm_pO4Qd&3kmDbgS2%qwDlAGQmmA5FHkcojyOgIjz_vapu=z_W^CZQ^ zuYh{y;yp`jbW$%rwfBm3eY>ET{!5{dBXYzS&e-6j1p)*+o^}<=Sc% znIV*5lA?)`hvtS8!;#T5PwB)A1irH%i$u5RiJ&90R8cz)Ci&gH?iFdEDT`3TwB*Yv z1uL2ZDJf18*4CK8-0TIbqASfEhV zns6yCc88FoYw)f}+6Gx}dQZ?=B?uGCfx+EjQu3aIAFYpGXZtN0_C_8_y?(iKLfBGf zJFrouODr!1W}p#1YWSvA$0Bs={X9_Voy%$QG{@mdTZ|L(rT2)^=7h*zmV!M66dnW4 z7`t#2dxic+H`^x@nebBD!+E=ZN30m)h}A@<-q|gpJJ}r_ z<;)1&y|CSml+EY#X%;z}tyWsOX_P6*h_@hJ@VVjQ|hz)#&t**)7U zqtekv*KDVnd!ji@j@qg>Z5XjtRkUe3^7~us55BIFzjXvv^LGh!N>2JRlhtA_#{0$+ zpxyF45lkc1(lLXl!+AaK8TKJi7s$>xmYjyz^uPepgc1JY-wRH!=)V+{f6usCO*kR= zt#US`@MHlNL>POSaSCG*R6Rz}D&RI;DFFmH^dMft=9Ylb3S;nHl#eQnhP%FEK6^I?L$7@vPnV^U8n13TiUKfRe-HyURmN-Wd?seT=X*_WHB-*_Q?GemQI3Ua8S2E+&GGE0 zHi}}G3D^rbTxcY}bqIV$o5l^2n70*C(*LjX*Zsg`Txg zJ+Ad2=!h#p0jXP^N>@u)Ii9yGtn}INapS@3r*@EYODj^(NWbNX{r<{ES--kNX(o`F z|99(SHdID9tS2C(IV;P_{Gy%F836#uT`HxBuq-6{aKwrb50#E|XCRzuewX+ZZzur- zuEJc?Lhtwb*cZlE3D_;)w1$TuvwTqd*cHG!P7XFP;ahX|o;WUnwvxUEeBnGx7(CoWIt(;#q2^daKTMiJw(?NKt=33pJj7L?(c`Y=bLNFcaei8PGG?6?>gPL?)q}eI zJ&_@abPT@ZEATUMz%W+7)<)|>CaxYU=h$yNSZ~Z+oY2hjnNemxelf1%=Ilx%dJZ#+ zku1BRe#YJDQ{E5}zFqkt*(NvZ>#GLT;GCu3!zk!^e-C*bY6SlYKGrZG#(@45Un0jvO{_8*tSNd~|F5GwZ zQhk+U&XHk}q~o3}veot3<>*61`z$YG_BY3v?4!m4mXJd3-S=g$&38WP`Q4B{lPf=_ z5^#;CPl9gq1I59 z0xEm8p5(k-voL$<}$g%IW`FQ|@t~zZ&&=!oYm@twhra3ocLsG<9!19Vi zrhnF4 z4}L~1@6-FOtV=rwbsI6QF#vvTQL?>(^9ZY`;wL&ymDG2Wsj)Fyj1Ew4Z`loyI_OMX zHga*z+St{dyKO&OjW;?(VXH#r!=t&Gob8Z%)8-uE7fB;0&K*d(K$}SX8~XMWgrdea z$M^CpW%jc_Cz7@v*&u6nEv&6e+f56xSfuvb4JD1jGaqX!b8je1Wn1CID=*kjNsnrs z-lGMI9=_72OaBv{#p$m@{Y$nB|99E0>VF~IQ424&%P2HXYNurb4o0Xha7kej!0c(` z)ioDabB-K~a5HH?X4ji%Kx2a|ZTtH5GpzW$5YyrM>=n1)&zN$RHQvR~H3sl7eO!s@ z%;;`Na(ohU$yC|IMWE6G7z1_DrHQ$l^k}@;NyEc`cZl9hm_rC;-x6|NymDdqGkcVy(O4!-|P&t zg|w&f++l{|EHx(F>Mj?0zoBZhad!YxCMzFdfX{xXojUBi)%?&N01zVZ;Gf52oQU*C zCiCVpi@(WZ?pL>>_P^c0fDmH*R1s3n>$#B`AO)|L?2Q8i(}f5zV8VNHRJCL6E}Dua zc5tdz7pFn5IOVbR@#o;_u|mpr(^H2UL;20cpKRp~?0<{S2!PwB)1EOP~tkPHCW_ z1xu~xZ6(45b#u&5%>>d}t*orqf9NQ2OenZm^My|-vYly`Emn1qA!!gg=;?2WzjWd9 z9>m0?N4KD{(^M=&9nx^dVT3-2Wi&c2xr5yKf=W_I5_iV0-}=d_v>TSmgI-Gve9B^iHC!E+y?A)vv#6eCLTx-X85rtUv#-d59?@vp!A@5a$-)itjsf zR(5JUA1iz87~rs02M6bhLylc4EZ4&3sc$^4Lk|y%y$|uRBGLxUV+7ZHZd%oO-syLB z=>oHwcK}4sDFFpXOSJ5yZIgpZLhQ3)A^JaQ@RLPqEdO_st4HI_*rCMr*lTy*f<~@6Tu7^oyX9>6IX{Cz$cGkmd znJlZ9ZB?XC5WzE)M-VE9-BE5K>UlIv#?AcLy*O804#x&TFhlITWdo<0r?G}!O~gU1 z-!xLdb@1fpusv%AR$8wT=1^5p$79Rqgb18W)9=QRIuA(uiQ6Ybw@%TuFwNqIYQWdC zE4l{dF&jk>#WnUtC!4}|W^Vd>iKL+@%Jeu^;A zn1@iEmf--e$p+QTtvXwEJJGHSG=B2HZNkvON%okoNQ<`9eu(72OqBUIxi33ukxl=# zhMi&9-SCqCYf zi}RDdhYk3#YqEY*`%RAKjCOpjrA+2E?1R+AZf>7Qjqg>KlzgdXF}wWC@raxq*rl^H z&UN||$eD@~XuEm4GNRk|1MZ#eB-tLBu>Kr`dBtCLH|7fla`I_nR~sv4rS7uF#=qOf@V`VGGZt)Qr3FPj4ukJdU^T^fw zItxvq$?f%7?&(8bK@arE>{5zGm8cQ!TJ}2>;;oejQ8X-p5l>>^hpppcX2a1BL1B@P z_X|H5>5d7<=~}RAQfclLUpiP!d8>FH#~caqzqTw~F2dEQrpm#F#LU8CRqEvj(vqo<=<}cW8asWH$d-!NpV?9uzCwX%zS2;K*Ub1WR& z>T;OyP=~KY$awGMb4kY`cLTKqc(D1*2&(=W3A- zqNuUlb%)HR*NDJH{05*jM=WAY4$qc zF$^Op2%f*xJN%pi&3kxoncH$TDq;EV%VB9LdA6BbSnSgf0E*hxtcQP%b0qn~*r*rW zmQ7^WLAi`Y>Eimx&(7JBGm^`J*ZC$?pM@n}(#4)bafL4FhKAwp=GQ<2;v=>@cy^Oy zuj(H&1f;Lg2sLbK9>rRQ$-Us>PQzve@2Oi{9gd=sc?FuH6u<`6&Z}kmt7Q>kcWUJ% z^7YsB>%A%zgI)SX#fXh#3p`ZWXzZ+iYkCTO8OmsnYGM0@%QN>D>WxUrjz9A3E?n&L z*9X_p$=s&1=>i{)2($Wc9|tY3XSV?d*Jt8iPRVwJmc{#zE@zuHBHMv}PWV*ppfk;L8n zt;TPIYmM%ScW3=hKw`W}TwgG?#X0`A^~C8Yc8L3+8m$hu6#Bf>KBhVJSo=k~?S5zF z9KCJyW1*(CQo-UlDq2>hhOY#>HbTeBuG5tbP!ek6yWVy3hG!lDd(BNK_%6Lq|26~^ z|K#pfM@P(^Tl!47g@)K+^O-5%PM6gS;BQG|15*3g!z*-=wiD<`>K9{Fy6gUscZT*q z5N046&TR*^*?TIr<-%|IJWtv#&2ysY@5WU7ZExy@hc_E`84U@pUAeC2;Usvl)Kn48 zn8{FK&0u$v^|E+wm2h}vWkYcezkmR(X#C}ID>KHbT*Tx*ic{PVSiLfp`7q1!1)CFl z#4d54<~-xrRn4D14rXP$^ZZW diff --git a/docs/guides/mongodb/backup/kubestash/customization/_index.md b/docs/guides/mongodb/backup/kubestash/customization/_index.md deleted file mode 100644 index 59549ce24..000000000 --- a/docs/guides/mongodb/backup/kubestash/customization/_index.md +++ /dev/null @@ -1,314 +0,0 @@ ---- -title: MongoDB Backup Customization | KubeStash -description: Customizing MongoDB Backup and Restore process with KubeStash -menu: - docs_{{ .version }}: - identifier: guides-mongodb-backup-kubestash-customization - name: Customizing Backup & Restore Process - parent: guides-mongodb-backup-stashv2 - weight: 40 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -# Customizing Backup and Restore Process - -KubeStash provides rich customization supports for the backup and restore process to meet the requirements of various cluster configurations. This guide will show you some examples of these customizations. - -## Customizing Backup Process - -In this section, we are going to show you how to customize the backup process. Here, we are going to show some examples of providing arguments to the backup process, running the backup process as a specific user, ignoring some indexes during the backup process, etc. - -### Passing arguments to the backup process - -KubeStash MongoDB addon uses [mongoump](https://docs.mongodb.com/database-tools/mongodump/) for backup. You can pass arguments to the `mongodump` through `args` param under `spec.sessions.addon.task.params` section. - -The below example shows how you can pass the `--db testdb` to take backup for a specific mongodb databases named `testdb`. - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mongodb - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - schedule: "*/5 * * * *" - repositories: - - name: s3-repo - backend: s3-backend - directory: /mongodb - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup - params: - args: "--db=testdb" -``` - -> **WARNING**: Make sure that you have the specific database created before taking backup. In this case, Database `testdb` should exist before the backup job starts. - -### Running backup job as a specific user - -If your cluster requires running the backup job as a specific user, you can provide `securityContext` under `spec.sessions.addon.tasks.jobTemplate.spec` section. The below example shows how you can run the backup job as the root user. - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mongodb - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - schedule: "*/5 * * * *" - repositories: - - name: s3-repo - backend: s3-backend - directory: /mongodb - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup - jobTemplate: - spec: - securityContext: - runAsUser: 0 - runAsGroup: 0 -``` - -### Specifying Memory/CPU limit/request for the backup job - -If you want to specify the Memory/CPU limit/request for your backup job, you can specify `resources` field under `spec.sessions.addon.tasks.containerRuntimeSettings` section. - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mongodb - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - schedule: "*/3 * * * *" - repositories: - - name: s3-repo - backend: s3-backend - directory: /mongodb - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup - containerRuntimeSettings: - resources: - requests: - cpu: "200m" - memory: "1Gi" - limits: - cpu: "200m" - memory: "1Gi" -``` - -## Customizing Restore Process - -KubeStash also uses `mongorestore` during the restore process. In this section, we are going to show how you can pass arguments to the restore process, restore a specific snapshot, run restore job as a specific user, etc. - -### Passing arguments to the restore process - -Similar to the backup process, you can pass arguments to the restore process through the `args` params under `spec.addon.task.params` section. This example will restore data from database `testdb`. - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: RestoreSession -metadata: - name: mg-restore - namespace: demo -spec: - target: - name: restore-mongodb - namespace: demo - apiGroup: kubedb.com - kind: MongoDB - dataSource: - snapshot: latest - repository: s3-repo - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackupRestoress - params: - args: "--db=testdb" -``` - -### Restore specific snapshot - -You can also restore a specific snapshot. At first, list the available snapshot as bellow, - -```bash -❯ kubectl get snapshots -n demo -NAMESPACE NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE VERIFICATION-STATUS AGE -demo s3-repo-mg-frequent-1702291682 s3-repo frequent 2023-12-11T10:48:10Z Delete Succeeded 82m -demo s3-repo-mg-frequent-1702291685 s3-repo frequent 2023-12-11T10:49:10Z Delete Succeeded 82m -``` - ->You can also filter the snapshots as shown in the guide [here](https://stash.run/docs/latest/concepts/crds/snapshot/#working-with-snapshot). - -The below example shows how you can pass a specific snapshot id through the `snapshots` filed of `rules` section. - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: RestoreSession -metadata: - name: mg-restore - namespace: demo -spec: - target: - name: restore-mongodb - namespace: demo - apiGroup: kubedb.com - kind: MongoDB - dataSource: - snapshot: s3-repo-mg-frequent-1702291682 - repository: s3-repo - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackupRestoress -``` - ->Please, do not specify multiple snapshots here. Each snapshot represents a complete backup of your database. Multiple snapshots are only usable during file/directory restore. - -### Running restore job as a specific user - -You can provide `securityContext` under `spec.addon.tasks.jobTemplate.spec` section to run the restore job as a specific user. - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: RestoreSession -metadata: - name: mg-restore - namespace: demo -spec: - target: - name: restore-mongodb - namespace: demo - apiGroup: kubedb.com - kind: MongoDB - dataSource: - snapshot: latest - repository: s3-repo - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackupRestoress - jobTemplate: - spec: - securityContext: - runAsUser: 0 - runAsGroup: 0 -``` - -### Specifying Memory/CPU limit/request for the restore job - -Similar to the backup process, you can also provide `resources` field under the `spec.addon.tasks.containerRuntimeSettings` section to limit the Memory/CPU for your restore job. - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: RestoreSession -metadata: - name: mg-restore - namespace: demo -spec: - target: - name: restore-mongodb - namespace: demo - apiGroup: kubedb.com - kind: MongoDB - dataSource: - snapshot: latest - repository: s3-repo - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackupRestoress - containerRuntimeSettings: - resources: - requests: - cpu: "200m" - memory: "1Gi" - limits: - cpu: "200m" - memory: "1Gi" -``` - -## Cleanup -To cleanup the resources crated by this tutorial, run the following commands, - -```bash -❯ kubectl delete backupconfiguration -n demo -❯ kubectl delete restoresession -n demo -``` \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/customization/examples/backup/passing-args.yaml b/docs/guides/mongodb/backup/kubestash/customization/examples/backup/passing-args.yaml deleted file mode 100644 index c947f7428..000000000 --- a/docs/guides/mongodb/backup/kubestash/customization/examples/backup/passing-args.yaml +++ /dev/null @@ -1,38 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mongodb - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - schedule: "*/5 * * * *" - jobTemplate: - backoffLimit: 1 - repositories: - - name: s3-repo - backend: s3-backend - directory: /mongodb - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup - params: - args: "--db=testdb" \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/customization/examples/backup/resource-limit.yaml b/docs/guides/mongodb/backup/kubestash/customization/examples/backup/resource-limit.yaml deleted file mode 100644 index 8cdeee995..000000000 --- a/docs/guides/mongodb/backup/kubestash/customization/examples/backup/resource-limit.yaml +++ /dev/null @@ -1,44 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mongodb - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - jobTemplate: - backoffLimit: 1 - schedule: "*/3 * * * *" - repositories: - - name: s3-repo - backend: s3-backend - directory: /mongodb - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup - containerRuntimeSettings: - resources: - requests: - cpu: "200m" - memory: "1Gi" - limits: - cpu: "200m" - memory: "1Gi" \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/customization/examples/backup/specific-user.yaml b/docs/guides/mongodb/backup/kubestash/customization/examples/backup/specific-user.yaml deleted file mode 100644 index b2698d459..000000000 --- a/docs/guides/mongodb/backup/kubestash/customization/examples/backup/specific-user.yaml +++ /dev/null @@ -1,41 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mongodb - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - jobTemplate: - backoffLimit: 1 - schedule: "*/5 * * * *" - repositories: - - name: s3-repo - backend: s3-backend - directory: /mongodb - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup - jobTemplate: - spec: - securityContext: - runAsUser: 0 - runAsGroup: 0 \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/customization/examples/restore/restore.yaml b/docs/guides/mongodb/backup/kubestash/customization/examples/restore/restore.yaml deleted file mode 100644 index 9fa004803..000000000 --- a/docs/guides/mongodb/backup/kubestash/customization/examples/restore/restore.yaml +++ /dev/null @@ -1,26 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: RestoreSession -metadata: - name: mg-restore - namespace: demo -spec: - target: - name: restore-mongodb - namespace: demo - apiGroup: kubedb.com - kind: MongoDB - dataSource: - snapshot: latest - repository: s3-repo - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackupRestoress - jobTemplate: - spec: - securityContext: - runAsUser: 0 - runAsGroup: 0 \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/customization/examples/retentionpolicy.yaml b/docs/guides/mongodb/backup/kubestash/customization/examples/retentionpolicy.yaml deleted file mode 100644 index 3d327f9a7..000000000 --- a/docs/guides/mongodb/backup/kubestash/customization/examples/retentionpolicy.yaml +++ /dev/null @@ -1,12 +0,0 @@ -apiVersion: storage.kubestash.com/v1alpha1 -kind: RetentionPolicy -metadata: - name: backup-rp - namespace: demo -spec: - maxRetentionPeriod: 2mo - successfulSnapshots: - last: 10 - usagePolicy: - allowedNamespaces: - from: All \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/_index.md b/docs/guides/mongodb/backup/kubestash/logical/_index.md deleted file mode 100644 index fb5bfba79..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/_index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Logical Backup & Restore of MongoDB | KubeStash -menu: - docs_{{ .version }}: - identifier: guides-mongodb-backup-kubestash-logical - name: Logical Backup - parent: guides-mongodb-backup-stashv2 - weight: 20 -menu_name: docs_{{ .version }} ---- \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/replicaset/_index.md b/docs/guides/mongodb/backup/kubestash/logical/replicaset/_index.md deleted file mode 100644 index 970743731..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/replicaset/_index.md +++ /dev/null @@ -1,593 +0,0 @@ ---- -title: Backup & Restore Replicaset MongoDB | KubeStash -description: Backup and restore replicaset MongoDB database using KubeStash -menu: - docs_{{ .version }}: - identifier: guides-mongodb-backup-kubestash-logical-replicaset - name: MongoDB Replicaset Cluster - parent: guides-mongodb-backup-kubestash-logical - weight: 21 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -# Backup and Restore MongoDB database using KubeStash - -KubeStash v0.1.0+ supports backup and restoration of MongoDB databases. This guide will show you how you can backup and restore your MongoDB database with KubeStash. - -## 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. If you do not already have a cluster, you can create one by using Minikube. -- Install KubeDB in your cluster following the steps [here](/docs/setup/README.md). -- Install KubeStash Enterprise in your cluster following the steps [here(link needed)](). -- Install KubeStash `kubectl` plugin following the steps [here(link needed)](). -- If you are not familiar with how KubeStash backup and restore MongoDB databases, please check the following guide [here](/docs/guides/mongodb/backup/kubestash/overview/_index.md). - -You have to be familiar with following custom resources: - -- [AppBinding](/docs/guides/mongodb/concepts/appbinding.md) -- [Function](https://stash.run/docs/latest/concepts/crds/function/) -- [Task](https://stash.run/docs/latest/concepts/crds/task/) -- [BackupConfiguration](https://stash.run/docs/latest/concepts/crds/backupconfiguration/) -- [RestoreSession](https://stash.run/docs/latest/concepts/crds/restoresession/) - -To keep things isolated, we are going to use a separate namespace called `demo` throughout this tutorial. Create `demo` namespace if you haven't created yet. - -```console -$ kubectl create ns demo -namespace/demo created -``` - -## Backup MongoDB - -This section will demonstrate how to backup MongoDB database. Here, we are going to deploy a MongoDB database using KubeDB. Then, we are going to backup this database into a S3 bucket. Finally, we are going to restore the backed up data into another MongoDB database. - -### Deploy Sample MongoDB Database - -Let's deploy a sample MongoDB database and insert some data into it. - -**Create MongoDB CRD:** - -Below is the YAML of a sample MongoDB crd that we are going to create for this tutorial: - -```yaml -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: sample-mg-rs - namespace: demo -spec: - version: "4.2.24" - replicas: 3 - replicaSet: - name: rs0 - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - terminationPolicy: WipeOut -``` - -Create the above `MongoDB` crd, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset.yaml -mongodb.kubedb.com/sample-mg-rs created -``` - -KubeDB will deploy a MongoDB database according to the above specification. It will also create the necessary secrets and services to access the database. - -Let's check if the database is ready to use, - -```console -$ kubectl get mongodb -n demo sample-mg-rs -NAME VERSION STATUS AGE -sample-mg-rs 4.2.24 Ready 2m27s -``` - -The database is `Ready`. Verify that KubeDB has created a Secret and a Service for this database using the following commands, - -```console -$ kubectl get secret -n demo -l=app.kubernetes.io/instance=sample-mg-rs -NAME TYPE DATA AGE -sample-mg-rs-auth kubernetes.io/basic-auth 2 3m53s -sample-mg-rs-key Opaque 1 3m53s - -$ kubectl get service -n demo -l=app.kubernetes.io/instance=sample-mg-rs -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -sample-mg-rs ClusterIP 10.96.211.27 27017/TCP 4m38s -sample-mg-rs-pods ClusterIP None 27017/TCP 4m38s -``` - -Here, we have to use service `sample-mg-rs` and secret `sample-mg-rs-auth` to connect with the database. - -**Insert Sample Data:** - -> Note: You can insert data into this `MongoDB` database using our [KubeDB CLI](https://kubedb.com/docs/latest/setup/install/kubectl_plugin/). - -For simplicity, we are going to exec into the database pod and create some sample data. At first, find out the database pod using the following command, - -```console -$ kubectl get pods -n demo --selector="app.kubernetes.io/instance=sample-mg-rs" -NAME READY STATUS RESTARTS AGE -sample-mg-rs-0 2/2 Running 0 6m15s -sample-mg-rs-1 2/2 Running 0 5m36s -sample-mg-rs-2 2/2 Running 0 5m14s -``` - -Now, let's exec into the pod and create a table, - -```console -$ export USER=$(kubectl get secrets -n demo sample-mg-rs-auth -o jsonpath='{.data.\username}' | base64 -d) - -$ export PASSWORD=$(kubectl get secrets -n demo sample-mg-rs-auth -o jsonpath='{.data.\password}' | base64 -d) - -$ kubectl exec -it -n demo sample-mg-rs-0 -- mongo admin -u $USER -p $PASSWORD - -rs0:PRIMARY> show dbs -admin 0.000GB -config 0.000GB -kubedb-system 0.000GB -local 0.000GB - -rs0:PRIMARY> show users -{ - "_id" : "admin.root", - "userId" : UUID("12716b1d-9186-4710-a669-4a2050a548bc"), - "user" : "root", - "db" : "admin", - "roles" : [ - { - "role" : "root", - "db" : "admin" - } - ], - "mechanisms" : [ - "SCRAM-SHA-1", - "SCRAM-SHA-256" - ] -} - -rs0:PRIMARY> use newdb -switched to db newdb - -rs0:PRIMARY> db.movie.insert({"name":"batman"}); -WriteResult({ "nInserted" : 1 }) - -rs0:PRIMARY> db.movie.find().pretty() -{ "_id" : ObjectId("657182194f1f295758f449a5"), "name" : "batman" } - -rs0:PRIMARY> exit -bye - -``` - -Now, we are ready to backup this sample database. - -### Prepare Backend - -We are going to store our backed up data into a S3 bucket. At first, we need to create a secret with S3 credentials then we need to create a `BackupStorage` crd. If you want to use a different backend, please read the respective backend configuration doc from [here](https://stash.run/docs/latest/guides/backends/overview/). - -**Create Storage Secret:** - -Let's create a secret called `s3-secret` with access credentials to our desired S3 bucket, - -```console -$ echo -n '' > AWS_ACCESS_KEY_ID -$ echo -n '' > AWS_SECRET_ACCESS_KEY -$ kubectl create secret generic -n demo s3-secret \ - --from-file=./AWS_ACCESS_KEY_ID \ - --from-file=./AWS_SECRET_ACCESS_KEY -secret/s3-secret created -``` - -**Create BackupStorage:** - -Now, crete a `BackupStorage` using this secret. Below is the YAML of BackupStorage crd we are going to create, - -```yaml -apiVersion: storage.kubestash.com/v1alpha1 -kind: BackupStorage -metadata: - name: s3-storage-replicaset - namespace: demo -spec: - storage: - provider: s3 - s3: - endpoint: us-east-1.linodeobjects.com - bucket: kubestash-testing - region: us-east-1 - prefix: demo-replicaset - secret: s3-secret - usagePolicy: - allowedNamespaces: - from: All - deletionPolicy: WipeOut -``` - -Let's create the `BackupStorage` we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupstorage-replicaset.yaml -backupstorage.storage.kubestash.com/s3-storage-replicaset created -``` - -Now, we are ready to backup our database to our desired backend. - -### Backup - -We have to create a `BackupConfiguration` targeting respective MongoDB crd of our desired database. Then KubeStash will create a CronJob to periodically backup the database. Before that we need to create an secret for encrypt data and retention policy. - -**Create Encryption Secret:** - -EncryptionSecret refers to the Secret containing the encryption key which will be used to encode/decode the backed up data. Let's create a secret called `encry-secret` - -```console -$ kubectl create secret generic encry-secret -n demo \ - --from-literal=RESTIC_PASSWORD='123' -n demo -secret/encry-secret created -``` - -**Create Retention Policy:** - -`RetentionPolicy` specifies how the old Snapshots should be cleaned up. This is a namespaced CRD.However, we can refer it from other namespaces as long as it is permitted via `.spec.usagePolicy`. Below is the YAML of the `RetentionPolicy` called `backup-rp` - -```console -apiVersion: storage.kubestash.com/v1alpha1 -kind: RetentionPolicy -metadata: - name: backup-rp - namespace: demo -spec: - maxRetentionPeriod: 2mo - successfulSnapshots: - last: 10 - usagePolicy: - allowedNamespaces: - from: All -``` - -Let's create the RetentionPolicy we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/retentionpolicy.yaml -retentionpolicy.storage.kubestash.com/backup-rp created -``` - -**Create BackupConfiguration:** - -As we just create our encryption secret and retention policy, we are now ready to apply `BackupConfiguration` crd to take backup out database. - -Below is the YAML for `BackupConfiguration` crd to backup the `sample-mg-rs` database we have deployed earlier., - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mg-rs - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage-replicaset - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - schedule: "*/3 * * * *" - repositories: - - name: s3-repo - backend: s3-backend - directory: /replicaset - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup -``` - -Here, - -- `spec.target` specifies our targeted `MongoDB` database. -- `spec.backends` specifies `BackupStorage` information for storing data. -- `spec.sessions` specifies common session configurations for this backup -- `spec.sessions.schedule` specifies that we want to backup the database at 5 minutes interval. -- `spec.sessions.addon` refers to the `Addon` crd for backup task - -Let's create the `BackupConfiguration` crd we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupconfiguration-replicaset.yaml -backupconfiguration.core.kubestash.com/mg created -``` - -**Verify Backup Setup Successful:** - -If everything goes well, the phase of the `BackupConfiguration` should be `Ready`. The `Ready` phase indicates that the backup setup is successful. Let's verify the `Phase` of the BackupConfiguration, - -```console -$ kubectl get backupconfiguration -n demo -NAME PHASE PAUSED AGE -mg Ready 85s -``` - -**Verify CronJob:** - -KubeStash will create a CronJob with the schedule specified in `spec.sessions.schedule` field of `BackupConfiguration` crd. - -Verify that the CronJob has been created using the following command, - -```console -$ kubectl get cronjob -n demo -NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE -trigger-mg-frequent */3 * * * * False 0 101s -``` - -**Wait for BackupSession:** - -The `trigger-mg-frequent` CronJob will trigger a backup on each schedule by creating a `BackpSession` crd. - -Wait for the next schedule. Run the following command to watch `BackupSession` crd, - -```console -$ kubectl get backupsession -n demo -NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE -mg-frequent-1701940862 BackupConfiguration mg Succeeded 3m16s -mg-frequent-1701941042 BackupConfiguration mg Running 16s -``` - -We can see above that the backup session has succeeded. Now, we are going to verify that the backed up data has been stored in the backend. - -**Verify Backup:** - -Once a backup is complete, KubeStash will update the respective `Snapshot` crd to reflect the backup. It will be created when a backup is triggered. Check that the `Snapshot` Phase to verify backup. - -```console -$ kubectl get snapshot -n demo -NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE VERIFICATION-STATUS AGE -s3-repo-mg-frequent-1701940862 s3-repo frequent 2023-12-07T09:21:07Z Delete Succeeded 3m53s -s3-repo-mg-frequent-1701941042 s3-repo frequent 2023-12-07T09:24:08Z Delete Succeeded 53s -``` - -KubeStash will also update the respective `Repository` crd to reflect the backup. Check that the repository `s3-repo` has been updated by the following command, - -```console -$ kubectl get repository -n demo s3-repo -NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE -s3-repo true 2 2.883 KiB Ready 55s 8m5s -``` - -Now, if we navigate to the S3 bucket, we are going to see backed up data has been stored in `demo/replicaset/` directory as specified by `spec.sessions.repositories.directory` field of `BackupConfiguration` crd. - -> Note: KubeStash keeps all the backed up data encrypted. So, data in the backend will not make any sense until they are decrypted. - -## Restore MongoDB -You can restore your data into the same database you have backed up from or into a different database in the same cluster or a different cluster. In this section, we are going to show you how to restore in the same database which may be necessary when you have accidentally deleted any data from the running database. - -#### Stop Taking Backup of the Old Database: - -It's important to stop taking any further backup of the old database so that no backup is stored in our repository during restore process. KubeStash operator will automatically pause the `BackupConfiguration` when a `RestoreSession` is running. However if we want to pause the `BackupConfiguration` manually, we can do that by patching or using KubeStash CLI. - -Let's pause the `mg` BackupConfiguration by patching, -```bash -$ kubectl patch backupconfiguration -n demo mg --type="merge" --patch='{"spec": {"paused": true}}' -backupconfiguration.core.kubestash.com/mg patched -``` - -Now, wait for a moment. KubeStash will pause the BackupConfiguration. Verify that the BackupConfiguration has been paused, - -```console -$ kubectl get backupconfiguration -n demo mg -NAME PHASE PAUSED AGE -mg Ready true 11m -``` - -Notice the `PAUSED` column. Value `true` for this field means that the BackupConfiguration has been paused. - -#### Deploy New MongoDB Database For Restoring: - -We are going to deploy a new mongodb replicaset database for restoring backed up data. - -Below is the YAML of a sample `MongoDB` crd that we are going to create - -```yaml -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: sample-mg-rs-restore - namespace: demo -spec: - version: "4.2.24" - replicas: 3 - replicaSet: - name: rs0 - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - terminationPolicy: WipeOut -``` - -Create the above `MongoDB` crd, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset-restore.yaml -mongodb.kubedb.com/sample-mg-rs-restore created -``` - -Let's check if the database is ready to use, - -```console -$ kubectl get mg -n demo sample-mg-rs-restore -NAME VERSION STATUS AGE -sample-mg-rs-restore 4.2.24 Ready 2m45s -``` - -Let's verify all the databases of this `sample-mg-rs-restore` by exec into its pod - -```console -$ export USER=$(kubectl get secrets -n demo sample-mg-rs-restore-auth -o jsonpath='{.data.\username}' | base64 -d) - -$ export PASSWORD=$(kubectl get secrets -n demo sample-mg-rs-restore-auth -o jsonpath='{.data.\password}' | base64 -d) - -$ kubectl exec -it -n demo sample-mg-rs-restore-0 -- mongo admin -u $USER -p $PASSWORD - -rs0:PRIMARY> show dbs -admin 0.000GB -config 0.000GB -kubedb-system 0.000GB -local 0.000GB - -rs0:PRIMARY> show users -{ - "_id" : "admin.root", - "userId" : UUID("b8a10e3f-05a1-421c-87ca-7bdf16f99563"), - "user" : "root", - "db" : "admin", - "roles" : [ - { - "role" : "root", - "db" : "admin" - } - ], - "mechanisms" : [ - "SCRAM-SHA-1", - "SCRAM-SHA-256" - ] -} - -rs0:PRIMARY> exit -bye -``` - -As we can see no database named `newdb` exist in this new `sample-mg-rs-restore` database. - -#### Create RestoreSession: - -Now, we need to create a `RestoreSession` crd pointing to the `sample-mg-rs-restore` database. -Below is the YAML for the `RestoreSession` crd that we are going to create to restore the backed up data. - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: RestoreSession -metadata: - name: mg-rs-restore - namespace: demo -spec: - target: - name: sample-mg-rs-restore - namespace: demo - apiGroup: kubedb.com - kind: MongoDB - dataSource: - snapshot: latest - repository: s3-repo - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackupRestore -``` - -Here, - -- `spec.dataSource.repository` specifies the `Repository` crd that holds the backend information where our backed up data has been stored. -- `spec.target` refers to the `MongoDB` crd for the `sample-mg-rs-restore` database. -- `spec.dataSource.snapshot` specifies that we are restoring from the latest backup snapshot of the `spec.dataSource.repository`. - -Let's create the `RestoreSession` crd we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/restoresession-replicaset.yaml -restoresession.core.kubestash.com/mg-rs-restore created -``` - -Once, you have created the `RestoreSession` crd, KubeStash will create a job to restore. We can watch the `RestoreSession` phase to check if the restore process is succeeded or not. - -Run the following command to watch `RestoreSession` phase, - -```console -$ kubectl get restoresession -n demo mg-rs-restore -w -NAME REPOSITORY FAILURE-POLICY PHASE DURATION AGE -mg-rs-restore s3-repo Succeeded 9s 34s -``` - -So, we can see from the output of the above command that the restore process succeeded. - -#### Verify Restored Data: - -In this section, we are going to verify that the desired data has been restored successfully. We are going to connect to the `sample-mg-rs-restore` database and check whether the table we had created earlier is restored or not. - -Lets, exec into the database pod and list available tables, - -```console -$ kubectl exec -it -n demo sample-mg-rs-restore-0 -- mongo admin -u $USER -p $PASSWORD - -rs0:PRIMARY> show dbs -admin 0.000GB -config 0.000GB -kubedb-system 0.000GB -local 0.000GB -newdb 0.000GB - -rs0:PRIMARY> show users -{ - "_id" : "admin.root", - "userId" : UUID("b8a10e3f-05a1-421c-87ca-7bdf16f99563"), - "user" : "root", - "db" : "admin", - "roles" : [ - { - "role" : "root", - "db" : "admin" - } - ], - "mechanisms" : [ - "SCRAM-SHA-1", - "SCRAM-SHA-256" - ] -} - -rs0:PRIMARY> use newdb -switched to db newdb - -rs0:PRIMARY> db.movie.find().pretty() -{ "_id" : ObjectId("657182194f1f295758f449a5"), "name" : "batman" } - -rs0:PRIMARY> exit -bye -``` - -So, from the above output, we can see the database `newdb` that we had created earlier is restored into another new `MongoDB` database. - -## Cleanup - -To cleanup the Kubernetes resources created by this tutorial, run: - -```console -kubectl delete -n demo restoresession mg-rs-restore -kubectl delete -n demo backupconfiguration mg -kubectl delete -n demo mg sample-mg-rs -kubectl delete -n demo mg sample-mg-rs-restore -kubectl delete -n demo backupstorage s3-storage-replicaset -``` diff --git a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupconfiguration-replicaset.yaml b/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupconfiguration-replicaset.yaml deleted file mode 100644 index aa9ada7a1..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupconfiguration-replicaset.yaml +++ /dev/null @@ -1,36 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mg-rs - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage-replicaset - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - jobTemplate: - backoffLimit: 1 - schedule: "*/3 * * * *" - repositories: - - name: s3-repo - backend: s3-backend - directory: /replicaset - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupstorage-replicaset.yaml b/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupstorage-replicaset.yaml deleted file mode 100644 index 81614714b..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupstorage-replicaset.yaml +++ /dev/null @@ -1,18 +0,0 @@ -apiVersion: storage.kubestash.com/v1alpha1 -kind: BackupStorage -metadata: - name: s3-storage-replicaset - namespace: demo -spec: - storage: - provider: s3 - s3: - endpoint: us-east-1.linodeobjects.com - bucket: kubestash-testing - region: us-east-1 - prefix: demo-replicaset - secret: s3-secret - usagePolicy: - allowedNamespaces: - from: All - deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset-restore.yaml b/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset-restore.yaml deleted file mode 100644 index 68555ef7c..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset-restore.yaml +++ /dev/null @@ -1,18 +0,0 @@ -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: sample-mg-rs-restore - namespace: demo -spec: - version: "4.2.24" - replicas: 3 - replicaSet: - name: rs0 - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - terminationPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset.yaml b/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset.yaml deleted file mode 100644 index aaf24a6cb..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/mongodb-replicaset.yaml +++ /dev/null @@ -1,18 +0,0 @@ -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: sample-mg-rs - namespace: demo -spec: - version: "4.2.24" - replicas: 3 - replicaSet: - name: rs0 - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - terminationPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/restoresession-replicaset.yaml b/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/restoresession-replicaset.yaml deleted file mode 100644 index 56920b806..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/restoresession-replicaset.yaml +++ /dev/null @@ -1,21 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: RestoreSession -metadata: - name: mg-rs-restore - namespace: demo -spec: - target: - name: sample-mg-rs-restore - namespace: demo - apiGroup: kubedb.com - kind: MongoDB - dataSource: - snapshot: latest - repository: s3-repo - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackupRestore \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/retentionpolicy.yaml b/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/retentionpolicy.yaml deleted file mode 100644 index 3d327f9a7..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/replicaset/examples/retentionpolicy.yaml +++ /dev/null @@ -1,12 +0,0 @@ -apiVersion: storage.kubestash.com/v1alpha1 -kind: RetentionPolicy -metadata: - name: backup-rp - namespace: demo -spec: - maxRetentionPeriod: 2mo - successfulSnapshots: - last: 10 - usagePolicy: - allowedNamespaces: - from: All \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/sharding/_index.md b/docs/guides/mongodb/backup/kubestash/logical/sharding/_index.md deleted file mode 100644 index 69435b449..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/sharding/_index.md +++ /dev/null @@ -1,607 +0,0 @@ ---- -title: Backup & Restore Sharded MongoDB | KubeStash -description: Backup and restore sharded MongoDB database using KubeStash -menu: - docs_{{ .version }}: - identifier: guides-mongodb-backup-kubestash-logical-sharded - name: MongoDB Sharded Cluster - parent: guides-mongodb-backup-kubestash-logical - weight: 22 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -# Backup and Restore MongoDB database using KubeStash - -KubeStash v0.1.0+ supports backup and restoration of MongoDB databases. This guide will show you how you can backup and restore your MongoDB database with KubeStash. - -## 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. If you do not already have a cluster, you can create one by using Minikube. -- Install KubeDB in your cluster following the steps [here](/docs/setup/README.md). -- Install KubeStash Enterprise in your cluster following the steps [here(link needed)](). -- Install KubeStash `kubectl` plugin following the steps [here(link needed)](). -- If you are not familiar with how KubeStash backup and restore MongoDB databases, please check the following guide [here](/docs/guides/mongodb/backup/kubestash/overview/_index.md). - -You have to be familiar with following custom resources: - -- [AppBinding](/docs/guides/mongodb/concepts/appbinding.md) -- [Function](https://stash.run/docs/latest/concepts/crds/function/) -- [Task](https://stash.run/docs/latest/concepts/crds/task/) -- [BackupConfiguration](https://stash.run/docs/latest/concepts/crds/backupconfiguration/) -- [RestoreSession](https://stash.run/docs/latest/concepts/crds/restoresession/) - -To keep things isolated, we are going to use a separate namespace called `demo` throughout this tutorial. Create `demo` namespace if you haven't created yet. - -```console -$ kubectl create ns demo -namespace/demo created -``` - -## Backup MongoDB - -This section will demonstrate how to backup MongoDB database. Here, we are going to deploy a MongoDB database using KubeDB. Then, we are going to backup this database into a S3 bucket. Finally, we are going to restore the backed up data into another MongoDB database. - -### Deploy Sample MongoDB Database - -Let's deploy a sample MongoDB database and insert some data into it. - -**Create MongoDB CRD:** - -Below is the YAML of a sample MongoDB crd that we are going to create for this tutorial: - -```yaml -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: sample-mg-sh - namespace: demo -spec: - version: 4.2.24 - shardTopology: - configServer: - replicas: 3 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard - mongos: - replicas: 2 - shard: - replicas: 3 - shards: 3 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard - terminationPolicy: WipeOut - -``` - -Create the above `MongoDB` crd, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/mongodb-sharding.yaml -mongodb.kubedb.com/sample-mg-sh created -``` - -KubeDB will deploy a MongoDB database according to the above specification. It will also create the necessary secrets and services to access the database. - -Let's check if the database is ready to use, - -```console -$ kubectl get mongodb -n demo sample-mg-sh -NAME VERSION STATUS AGE -sample-mg-sh 4.2.24 Ready 5m39s -``` - -The database is `Ready`. Verify that KubeDB has created a Secret and a Service for this database using the following commands, - -```console -$ kubectl get secret -n demo -l=app.kubernetes.io/instance=sample-mg-sh -NAME TYPE DATA AGE -sample-mg-sh-auth kubernetes.io/basic-auth 2 21m -sample-mg-sh-key Opaque 1 21m - -$ kubectl get service -n demo -l=app.kubernetes.io/instance=sample-mg-sh -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -sample-mg-sh ClusterIP 10.96.80.43 27017/TCP 21m -sample-mg-sh-configsvr-pods ClusterIP None 27017/TCP 21m -sample-mg-sh-mongos-pods ClusterIP None 27017/TCP 21m -sample-mg-sh-shard0-pods ClusterIP None 27017/TCP 21m -sample-mg-sh-shard1-pods ClusterIP None 27017/TCP 21m -sample-mg-sh-shard2-pods ClusterIP None 27017/TCP 21m -``` - -Here, we have to use service `sample-mg-sh` and secret `sample-mg-sh-auth` to connect with the database. - -**Insert Sample Data:** - -> Note: You can insert data into this `MongoDB` database using our [KubeDB CLI](https://kubedb.com/docs/latest/setup/install/kubectl_plugin/). - -For simplicity, we are going to exec into the database pod and create some sample data. At first, find out the database mongos pod using the following command, - -```console -$ kubectl get pods -n demo --selector="mongodb.kubedb.com/node.mongos=sample-mg-sh-mongos" -NAME READY STATUS RESTARTS AGE -sample-mg-sh-mongos-0 1/1 Running 0 21m -sample-mg-sh-mongos-1 1/1 Running 0 21m -``` - -Now, let's exec into the pod and create a table, - -```console -$ export USER=$(kubectl get secrets -n demo sample-mg-sh-auth -o jsonpath='{.data.\username}' | base64 -d) - -$ export PASSWORD=$(kubectl get secrets -n demo sample-mg-sh-auth -o jsonpath='{.data.\password}' | base64 -d) - -$ kubectl exec -it -n demo sample-mg-sh-mongos-0 -- mongo admin -u $USER -p $PASSWORD - -mongos> show dbs -admin 0.000GB -config 0.002GB -kubedb-system 0.000GB - -mongos> show users -{ - "_id" : "admin.root", - "userId" : UUID("61a02236-1e25-4f58-9b92-9a41a80726bc"), - "user" : "root", - "db" : "admin", - "roles" : [ - { - "role" : "root", - "db" : "admin" - } - ], - "mechanisms" : [ - "SCRAM-SHA-1", - "SCRAM-SHA-256" - ] -} - -mongos> use newdb -switched to db newdb - -mongos> db.movie.insert({"name":"batman"}); -WriteResult({ "nInserted" : 1 }) - -mongos> exit -bye - -``` - -Now, we are ready to backup this sample database. - -### Prepare Backend - -We are going to store our backed up data into a S3 bucket. At first, we need to create a secret with S3 credentials then we need to create a `BackupStorage` crd. If you want to use a different backend, please read the respective backend configuration doc from [here](https://stash.run/docs/latest/guides/backends/overview/). - -**Create Storage Secret:** - -Let's create a secret called `s3-secret` with access credentials to our desired S3 bucket, - -```console -$ echo -n '' > AWS_ACCESS_KEY_ID -$ echo -n '' > AWS_SECRET_ACCESS_KEY -$ kubectl create secret generic -n demo s3-secret \ - --from-file=./AWS_ACCESS_KEY_ID \ - --from-file=./AWS_SECRET_ACCESS_KEY -secret/s3-secret created -``` - -**Create BackupStorage:** - -Now, crete a `BackupStorage` using this secret. Below is the YAML of BackupStorage crd we are going to create, - -```yaml -apiVersion: storage.kubestash.com/v1alpha1 -kind: BackupStorage -metadata: - name: s3-storage-sharding - namespace: demo -spec: - storage: - provider: s3 - s3: - endpoint: us-east-1.linodeobjects.com - bucket: kubestash-testing - region: us-east-1 - prefix: demo-sharding - secret: s3-secret - usagePolicy: - allowedNamespaces: - from: All - deletionPolicy: WipeOut -``` - -Let's create the `BackupStorage` we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/backupstorage-sharding.yaml -backupstorage.storage.kubestash.com/s3-storage-sharding created -``` - -Now, we are ready to backup our database to our desired backend. - -### Backup - -We have to create a `BackupConfiguration` targeting respective MongoDB crd of our desired database. Then KubeStash will create a CronJob to periodically backup the database. Before that we need to create an secret for encrypt data and retention policy. - -**Create Encryption Secret:** - -EncryptionSecret refers to the Secret containing the encryption key which will be used to encode/decode the backed up data. Let's create a secret called `encry-secret` - -```console -$ kubectl create secret generic encry-secret -n demo \ - --from-literal=RESTIC_PASSWORD='123' -n demo -secret/encry-secret created -``` - -**Create Retention Policy:** - -`RetentionPolicy` specifies how the old Snapshots should be cleaned up. This is a namespaced CRD.However, we can refer it from other namespaces as long as it is permitted via `.spec.usagePolicy`. Below is the YAML of the `RetentionPolicy` called `backup-rp` - -```console -apiVersion: storage.kubestash.com/v1alpha1 -kind: RetentionPolicy -metadata: - name: backup-rp - namespace: demo -spec: - maxRetentionPeriod: 2mo - successfulSnapshots: - last: 10 - usagePolicy: - allowedNamespaces: - from: All -``` - -Let's create the RetentionPolicy we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/retentionpolicy.yaml -retentionpolicy.storage.kubestash.com/backup-rp created -``` - -**Create BackupConfiguration:** - -As we just create our encryption secret and retention policy, we are now ready to apply `BackupConfiguration` crd to take backup out database. - -Below is the YAML for `BackupConfiguration` crd to backup the `sample-mg-sh` database we have deployed earlier., - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mg-sh - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage-sharding - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - schedule: "*/3 * * * *" - repositories: - - name: s3-repo - backend: s3-backend - directory: /sharding - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup -``` - -Here, - -- `spec.target` specifies our targeted `MongoDB` database. -- `spec.backends` specifies `BackupStorage` information for storing data. -- `spec.sessions` specifies common session configurations for this backup -- `spec.sessions.schedule` specifies that we want to backup the database at 5 minutes interval. -- `spec.sessions.addon` refers to the `Addon` crd for backup task - -Let's create the `BackupConfiguration` crd we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/backupconfiguration-sharding.yaml -backupconfiguration.core.kubestash.com/mg created -``` - -**Verify Backup Setup Successful:** - -If everything goes well, the phase of the `BackupConfiguration` should be `Ready`. The `Ready` phase indicates that the backup setup is successful. Let's verify the `Phase` of the BackupConfiguration, - -```console -$ kubectl get backupconfiguration -n demo -NAME PHASE PAUSED AGE -mg Ready 85s -``` - -**Verify CronJob:** - -KubeStash will create a CronJob with the schedule specified in `spec.sessions.schedule` field of `BackupConfiguration` crd. - -Verify that the CronJob has been created using the following command, - -```console -$ kubectl get cronjob -n demo -NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE -trigger-mg-frequent */3 * * * * False 0 101s -``` - -**Wait for BackupSession:** - -The `trigger-mg-frequent` CronJob will trigger a backup on each schedule by creating a `BackpSession` crd. - -Wait for the next schedule. Run the following command to watch `BackupSession` crd, - -```console -$ kubectl get backupsession -n demo -NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE -mg-frequent-1701950402 BackupConfiguration mg Succeeded 3m5s -mg-frequent-1701950582 BackupConfiguration mg Running 5s -``` - -We can see above that the backup session has succeeded. Now, we are going to verify that the backed up data has been stored in the backend. - -**Verify Backup:** - -Once a backup is complete, KubeStash will update the respective `Snapshot` crd to reflect the backup. It will be created when a backup is triggered. Check that the `Snapshot` Phase to verify backup. - -```console -$ kubectl get snapshot -n demo -NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE VERIFICATION-STATUS AGE -s3-repo-mg-frequent-1701950402 s3-repo frequent 2023-12-07T12:00:11Z Delete Succeeded 3m37s -s3-repo-mg-frequent-1701950582 s3-repo frequent 2023-12-07T12:03:08Z Delete Succeeded 37s -``` - -KubeStash will also update the respective `Repository` crd to reflect the backup. Check that the repository `s3-repo` has been updated by the following command, - -```console -$ kubectl get repository -n demo s3-repo -NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE -s3-repo true 2 95.660 KiB Ready 41s 4m3s -``` - -Now, if we navigate to the S3 bucket, we are going to see backed up data has been stored in `demo/sharding/` directory as specified by `spec.sessions.repositories.directory` field of `BackupConfiguration` crd. - -> Note: KubeStash keeps all the backed up data encrypted. So, data in the backend will not make any sense until they are decrypted. - -## Restore MongoDB -You can restore your data into the same database you have backed up from or into a different database in the same cluster or a different cluster. In this section, we are going to show you how to restore in the same database which may be necessary when you have accidentally deleted any data from the running database. - -#### Stop Taking Backup of the Old Database: - -It's important to stop taking any further backup of the old database so that no backup is stored in our repository during restore process. KubeStash operator will automatically pause the `BackupConfiguration` when a `RestoreSession` is running. However if we want to pause the `BackupConfiguration` manually, we can do that by patching or using KubeStash CLI. - -Let's pause the `mg` BackupConfiguration by patching, -```bash -$ kubectl patch backupconfiguration -n demo mg --type="merge" --patch='{"spec": {"paused": true}}' -backupconfiguration.core.kubestash.com/mg patched -``` - -Now, wait for a moment. KubeStash will pause the BackupConfiguration. Verify that the BackupConfiguration has been paused, - -```console -$ kubectl get backupconfiguration -n demo mg -NAME PHASE PAUSED AGE -mg Ready true 11m -``` - -Notice the `PAUSED` column. Value `true` for this field means that the BackupConfiguration has been paused. - -#### Deploy New MongoDB Database For Restoring: - -We are going to deploy a new mongodb replicaset database for restoring backed up data. - -Below is the YAML of a sample `MongoDB` crd that we are going to create - -```yaml -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: sample-mg-sh-restore - namespace: demo -spec: - version: 4.2.24 - shardTopology: - configServer: - replicas: 3 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard - mongos: - replicas: 2 - shard: - replicas: 3 - shards: 3 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard - terminationPolicy: WipeOut -``` - -Create the above `MongoDB` crd, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/mongodb-sharding-restore.yaml -mongodb.kubedb.com/sample-mg-sh-restore created -``` - -Let's check if the database is ready to use, - -```console -$ kubectl get mg -n demo sample-mg-sh-restore -NAME VERSION STATUS AGE -sample-mg-sh-restore 4.2.24 Ready 7m47s -``` - -Let's verify all the databases of this `sample-mg-sh-restore` by exec into its mongos pod - -```console -$ export USER=$(kubectl get secrets -n demo sample-mg-sh-restore-auth -o jsonpath='{.data.\username}' | base64 -d) - -$ export PASSWORD=$(kubectl get secrets -n demo sample-mg-sh-restore-auth -o jsonpath='{.data.\password}' | base64 -d) - -$ kubectl exec -it -n demo sample-mg-sh-restore-mongos-0 -- mongo admin -u $USER -p $PASSWORD - -mongos> show dbs -admin 0.000GB -config 0.002GB -kubedb-system 0.000GB - -mongos> show users -{ - "_id" : "admin.root", - "userId" : UUID("4400d0cc-bba7-4626-bf5b-7521fca30ff9"), - "user" : "root", - "db" : "admin", - "roles" : [ - { - "role" : "root", - "db" : "admin" - } - ], - "mechanisms" : [ - "SCRAM-SHA-1", - "SCRAM-SHA-256" - ] -} - -mongos> exit -bye -``` - -As we can see no database named `newdb` exist in this new `sample-mg-sh-restore` database. - -#### Create RestoreSession: - -Now, we need to create a `RestoreSession` crd pointing to the `sample-mg-sh-restore` database. -Below is the YAML for the `RestoreSession` crd that we are going to create to restore the backed up data. - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: RestoreSession -metadata: - name: mg-sh-restore - namespace: demo -spec: - target: - name: sample-mg-sh-restore - namespace: demo - apiGroup: kubedb.com - kind: MongoDB - dataSource: - snapshot: latest - repository: s3-repo - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackupRestore -``` - -Here, - -- `spec.dataSource.repository` specifies the `Repository` crd that holds the backend information where our backed up data has been stored. -- `spec.target` refers to the `MongoDB` crd for the `sample-mg-sh-restore` database. -- `spec.dataSource.snapshot` specifies that we are restoring from the latest backup snapshot of the `spec.dataSource.repository`. - -Let's create the `RestoreSession` crd we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/restoresession-sharding.yaml -restoresession.core.kubestash.com/mg-sh-restore created -``` - -Once, you have created the `RestoreSession` crd, KubeStash will create a job to restore. We can watch the `RestoreSession` phase to check if the restore process is succeeded or not. - -Run the following command to watch `RestoreSession` phase, - -```console -$ kubectl get restoresession -n demo mg-sh-restore -w -NAME REPOSITORY FAILURE-POLICY PHASE DURATION AGE -mg-sh-restore s3-repo Succeeded 15s 48s -``` - -So, we can see from the output of the above command that the restore process succeeded. - -#### Verify Restored Data: - -In this section, we are going to verify that the desired data has been restored successfully. We are going to connect to the `sample-mg-sh-restore` database and check whether the table we had created earlier is restored or not. - -Lets, exec into the database's mongos pod and list available tables, - -```console -$ kubectl exec -it -n demo sample-mg-sh-restore-mongos-0 -- mongo admin -u $USER -p $PASSWORD - -mongos> show dbs -admin 0.000GB -config 0.002GB -kubedb-system 0.000GB -newdb 0.000GB - -mongos> show users -{ - "_id" : "admin.root", - "userId" : UUID("4400d0cc-bba7-4626-bf5b-7521fca30ff9"), - "user" : "root", - "db" : "admin", - "roles" : [ - { - "role" : "root", - "db" : "admin" - } - ], - "mechanisms" : [ - "SCRAM-SHA-1", - "SCRAM-SHA-256" - ] -} - -mongos> use newdb -switched to db newdb - -mongos> db.movie.find().pretty() -{ "_id" : ObjectId("6571b0465bde128e0c4d7caa"), "name" : "batman" } - -mongos> exit -bye -``` - -So, from the above output, we can see the database `newdb` that we had created earlier is restored into another new `MongoDB` database. - -## Cleanup - -To cleanup the Kubernetes resources created by this tutorial, run: - -```console -kubectl delete -n demo restoresession mg-sh-restore -kubectl delete -n demo backupconfiguration mg -kubectl delete -n demo mg sample-mg-sh -kubectl delete -n demo mg sample-mg-sh-restore -kubectl delete -n demo backupstorage s3-storage-sharding -``` diff --git a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/backupconfiguration-sharding.yaml b/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/backupconfiguration-sharding.yaml deleted file mode 100644 index 27389a4bc..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/backupconfiguration-sharding.yaml +++ /dev/null @@ -1,36 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mg-sh - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage-sharding - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - jobTemplate: - backoffLimit: 1 - schedule: "*/3 * * * *" - repositories: - - name: s3-repo - backend: s3-backend - directory: /sharding - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/backupstorage-sharding.yaml b/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/backupstorage-sharding.yaml deleted file mode 100644 index b88ea760a..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/backupstorage-sharding.yaml +++ /dev/null @@ -1,18 +0,0 @@ -apiVersion: storage.kubestash.com/v1alpha1 -kind: BackupStorage -metadata: - name: s3-storage-sharding - namespace: demo -spec: - storage: - provider: s3 - s3: - endpoint: us-east-1.linodeobjects.com - bucket: kubestash-testing - region: us-east-1 - prefix: demo-sharding - secretName: s3-secret - usagePolicy: - allowedNamespaces: - from: All - deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/mongodb-sharding-restore.yaml b/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/mongodb-sharding-restore.yaml deleted file mode 100644 index e38e173c4..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/mongodb-sharding-restore.yaml +++ /dev/null @@ -1,26 +0,0 @@ -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: sample-mg-sh-restore - namespace: demo -spec: - version: 4.2.24 - shardTopology: - configServer: - replicas: 3 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard - mongos: - replicas: 2 - shard: - replicas: 3 - shards: 3 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard - terminationPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/mongodb-sharding.yaml b/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/mongodb-sharding.yaml deleted file mode 100644 index f28723435..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/mongodb-sharding.yaml +++ /dev/null @@ -1,26 +0,0 @@ -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: sample-mg-sh - namespace: demo -spec: - version: 4.2.24 - shardTopology: - configServer: - replicas: 3 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard - mongos: - replicas: 2 - shard: - replicas: 3 - shards: 3 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard - terminationPolicy: WipeOut diff --git a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/restoresession-sharding.yaml b/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/restoresession-sharding.yaml deleted file mode 100644 index d0d8614d7..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/restoresession-sharding.yaml +++ /dev/null @@ -1,21 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: RestoreSession -metadata: - name: mg-sh-restore - namespace: demo -spec: - target: - name: sample-mg-sh-restore - namespace: demo - apiGroup: kubedb.com - kind: MongoDB - dataSource: - snapshot: latest - repository: s3-repo - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackupRestore \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/retentionpolicy.yaml b/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/retentionpolicy.yaml deleted file mode 100644 index 3d327f9a7..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/sharding/examples/retentionpolicy.yaml +++ /dev/null @@ -1,12 +0,0 @@ -apiVersion: storage.kubestash.com/v1alpha1 -kind: RetentionPolicy -metadata: - name: backup-rp - namespace: demo -spec: - maxRetentionPeriod: 2mo - successfulSnapshots: - last: 10 - usagePolicy: - allowedNamespaces: - from: All \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/standalone/_index.md b/docs/guides/mongodb/backup/kubestash/logical/standalone/_index.md deleted file mode 100644 index d364622dd..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/standalone/_index.md +++ /dev/null @@ -1,586 +0,0 @@ ---- -title: Backup & Restore Standalone MongoDB | KubeStash -description: Backup and restore standalone MongoDB database using KubeStash -menu: - docs_{{ .version }}: - identifier: guides-mongodb-backup-kubestash-logical-standalone - name: Standalone MongoDB - parent: guides-mongodb-backup-kubestash-logical - weight: 20 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -# Backup and Restore MongoDB database using KubeStash - -KubeStash v0.1.0+ supports backup and restoration of MongoDB databases. This guide will show you how you can backup and restore your MongoDB database with KubeStash. - -## 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. If you do not already have a cluster, you can create one by using Minikube. -- Install KubeDB in your cluster following the steps [here](/docs/setup/README.md). -- Install KubeStash Enterprise in your cluster following the steps [here(link needed)](). -- Install KubeStash `kubectl` plugin following the steps [here(link needed)](). -- If you are not familiar with how KubeStash backup and restore MongoDB databases, please check the following guide [here](/docs/guides/mongodb/backup/kubestash/overview/_index.md). - -You have to be familiar with following custom resources: - -- [AppBinding](/docs/guides/mongodb/concepts/appbinding.md) -- [Function](https://stash.run/docs/latest/concepts/crds/function/) -- [Task](https://stash.run/docs/latest/concepts/crds/task/) -- [BackupConfiguration](https://stash.run/docs/latest/concepts/crds/backupconfiguration/) -- [RestoreSession](https://stash.run/docs/latest/concepts/crds/restoresession/) - -To keep things isolated, we are going to use a separate namespace called `demo` throughout this tutorial. Create `demo` namespace if you haven't created yet. - -```console -$ kubectl create ns demo -namespace/demo created -``` - -## Backup MongoDB - -This section will demonstrate how to backup MongoDB database. Here, we are going to deploy a MongoDB database using KubeDB. Then, we are going to backup this database into a S3 bucket. Finally, we are going to restore the backed up data into another MongoDB database. - -### Deploy Sample MongoDB Database - -Let's deploy a sample MongoDB database and insert some data into it. - -**Create MongoDB CRD:** - -Below is the YAML of a sample MongoDB crd that we are going to create for this tutorial: - -```yaml -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: sample-mongodb - namespace: demo -spec: - version: "4.2.24" - storageType: Durable - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - terminationPolicy: WipeOut -``` - -Create the above `MongoDB` crd, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/mongodb.yaml -mongodb.kubedb.com/sample-mongodb created -``` - -KubeDB will deploy a MongoDB database according to the above specification. It will also create the necessary secrets and services to access the database. - -Let's check if the database is ready to use, - -```console -$ kubectl get mg -n demo sample-mongodb -NAME VERSION STATUS AGE -sample-mongodb 4.2.24 Ready 2m9s -``` - -The database is `Ready`. Verify that KubeDB has created a Secret and a Service for this database using the following commands, - -```console -$ kubectl get secret -n demo -l=app.kubernetes.io/instance=sample-mongodb -NAME TYPE DATA AGE -sample-mongodb-auth Opaque 2 2m28s - -$ kubectl get service -n demo -l=app.kubernetes.io/instance=sample-mongodb -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -sample-mongodb ClusterIP 10.107.58.222 27017/TCP 2m48s -sample-mongodb-gvr ClusterIP None 27017/TCP 2m48s -``` - -Here, we have to use service `sample-mongodb` and secret `sample-mongodb-auth` to connect with the database. - -**Insert Sample Data:** - -> Note: You can insert data into this `MongoDB` database using our [KubeDB CLI](https://kubedb.com/docs/latest/setup/install/kubectl_plugin/). - -For simplicity, we are going to exec into the database pod and create some sample data. At first, find out the database pod using the following command, - -```console -$ kubectl get pods -n demo --selector="app.kubernetes.io/instance=sample-mongodb" -NAME READY STATUS RESTARTS AGE -sample-mongodb-0 1/1 Running 0 12m -``` - -Now, let's exec into the pod and create a table, - -```console -$ export USER=$(kubectl get secrets -n demo sample-mongodb-auth -o jsonpath='{.data.\username}' | base64 -d) - -$ export PASSWORD=$(kubectl get secrets -n demo sample-mongodb-auth -o jsonpath='{.data.\password}' | base64 -d) - -$ kubectl exec -it -n demo sample-mongodb-0 -- mongo admin -u $USER -p $PASSWORD - -> show dbs -admin 0.000GB -config 0.000GB -kubedb-system 0.000GB -local 0.000GB - -> show users -{ - "_id" : "admin.root", - "userId" : UUID("b82f8a34-1fc4-4ffe-b616-c6ffa278ecc8"), - "user" : "root", - "db" : "admin", - "roles" : [ - { - "role" : "root", - "db" : "admin" - } - ], - "mechanisms" : [ - "SCRAM-SHA-1", - "SCRAM-SHA-256" - ] -} - -> use newdb -switched to db newdb - -> db.movie.insert({"name":"batman"}); -WriteResult({ "nInserted" : 1 }) - -> db.movie.find().pretty() -{ "_id" : ObjectId("5d19d1cdc93d828f44e37735"), "name" : "batman" } - -> exit -bye -``` - -Now, we are ready to backup this sample database. - -### Prepare Backend - -We are going to store our backed up data into a S3 bucket. At first, we need to create a secret with S3 credentials then we need to create a `BackupStorage` crd. If you want to use a different backend, please read the respective backend configuration doc from [here](https://stash.run/docs/latest/guides/backends/overview/). - -**Create Storage Secret:** - -Let's create a secret called `s3-secret` with access credentials to our desired S3 bucket, - -```console -$ echo -n '' > AWS_ACCESS_KEY_ID -$ echo -n '' > AWS_SECRET_ACCESS_KEY -$ kubectl create secret generic -n demo s3-secret \ - --from-file=./AWS_ACCESS_KEY_ID \ - --from-file=./AWS_SECRET_ACCESS_KEY -secret/s3-secret created -``` - -**Create BackupStorage:** - -Now, crete a `BackupStorage` using this secret. Below is the YAML of BackupStorage crd we are going to create, - -```yaml -apiVersion: storage.kubestash.com/v1alpha1 -kind: BackupStorage -metadata: - name: s3-storage - namespace: demo -spec: - storage: - provider: s3 - s3: - endpoint: us-east-1.linodeobjects.com - bucket: kubestash-testing - region: us-east-1 - prefix: demo - secret: s3-secret - usagePolicy: - allowedNamespaces: - from: All - deletionPolicy: WipeOut -``` - -Let's create the `BackupStorage` we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/backupstorage.yaml -storage.kubestash.com/s3-storage created -``` - -Now, we are ready to backup our database to our desired backend. - -### Backup - -We have to create a `BackupConfiguration` targeting respective MongoDB crd of our desired database. Then KubeStash will create a CronJob to periodically backup the database. Before that we need to create an secret for encrypt data and retention policy. - -**Create Encryption Secret:** - -EncryptionSecret refers to the Secret containing the encryption key which will be used to encode/decode the backed up data. Let's create a secret called `encry-secret` - -```console -$ kubectl create secret generic encry-secret -n demo \ - --from-literal=RESTIC_PASSWORD='123' -n demo -secret/encry-secret created -``` - -**Create Retention Policy:** - -`RetentionPolicy` specifies how the old Snapshots should be cleaned up. This is a namespaced CRD.However, we can refer it from other namespaces as long as it is permitted via `.spec.usagePolicy`. Below is the YAML of the `RetentionPolicy` called `backup-rp` - -```console -apiVersion: storage.kubestash.com/v1alpha1 -kind: RetentionPolicy -metadata: - name: backup-rp - namespace: demo -spec: - maxRetentionPeriod: 2mo - successfulSnapshots: - last: 10 - usagePolicy: - allowedNamespaces: - from: All -``` - -Let's create the RetentionPolicy we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/retentionpolicy.yaml -retentionpolicy.storage.kubestash.com/backup-rp created -``` - -**Create BackupConfiguration:** - -As we just create our encryption secret and retention policy, we are now ready to apply `BackupConfiguration` crd to take backup out database. - -Below is the YAML for `BackupConfiguration` crd to backup the `sample-mongodb` database we have deployed earlier., - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mongodb - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - schedule: "*/3 * * * *" - repositories: - - name: s3-repo - backend: s3-backend - directory: /mongodb - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup -``` - -Here, - -- `spec.target` specifies our targeted `MongoDB` database. -- `spec.backends` specifies `BackupStorage` information for storing data. -- `spec.sessions` specifies common session configurations for this backup -- `spec.sessions.schedule` specifies that we want to backup the database at 5 minutes interval. -- `spec.sessions.addon` refers to the `Addon` crd for backup task - -Let's create the `BackupConfiguration` crd we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/backupconfiguration.yaml -backupconfiguration.core.kubestash.com/mg created -``` - -**Verify Backup Setup Successful:** - -If everything goes well, the phase of the `BackupConfiguration` should be `Ready`. The `Ready` phase indicates that the backup setup is successful. Let's verify the `Phase` of the BackupConfiguration, - -```console -$ kubectl get backupconfiguration -n demo -NAME PHASE PAUSED AGE -mg Ready 85s -``` - -**Verify CronJob:** - -KubeStash will create a CronJob with the schedule specified in `spec.sessions.schedule` field of `BackupConfiguration` crd. - -Verify that the CronJob has been created using the following command, - -```console -$ kubectl get cronjob -n demo -NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE -trigger-mg-frequent */3 * * * * False 0 101s -``` - -**Wait for BackupSession:** - -The `trigger-mg-frequent` CronJob will trigger a backup on each schedule by creating a `BackpSession` crd. - -Wait for the next schedule. Run the following command to watch `BackupSession` crd, - -```console -$ kubectl get backupsession -n demo -NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE -mg-frequent-1701923402 BackupConfiguration mg Succeeded 3m4s -mg-frequent-1701923582 BackupConfiguration mg Running 4s -``` - -We can see above that the backup session has succeeded. Now, we are going to verify that the backed up data has been stored in the backend. - -**Verify Backup:** - -Once a backup is complete, KubeStash will update the respective `Snapshot` crd to reflect the backup. It will be created when a backup is triggered. Check that the `Snapshot` Phase to verify backup. - -```console -$ kubectl get snapshot -n demo -NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE VERIFICATION-STATUS AGE -s3-repo-mg-frequent-1701923402 s3-repo frequent 2023-12-07T04:30:10Z Delete Succeeded 3m25s -s3-repo-mg-frequent-1701923582 s3-repo frequent 2023-12-07T04:33:06Z Delete Succeeded 25s -``` - - -KubeStash will also update the respective `Repository` crd to reflect the backup. Check that the repository `s3-repo` has been updated by the following command, - -```console -$ kubectl get repository -n demo s3-repo -NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE -s3-repo true 2 2.613 KiB Ready 2m42s 8m38s -``` - -Now, if we navigate to the S3 bucket, we are going to see backed up data has been stored in `demo/mongodb/` directory as specified by `spec.sessions.repositories.directory` field of `BackupConfiguration` crd. - -> Note: KubeStash keeps all the backed up data encrypted. So, data in the backend will not make any sense until they are decrypted. - -## Restore MongoDB -You can restore your data into the same database you have backed up from or into a different database in the same cluster or a different cluster. In this section, we are going to show you how to restore in the same database which may be necessary when you have accidentally deleted any data from the running database. - -#### Stop Taking Backup of the Old Database: - -It's important to stop taking any further backup of the old database so that no backup is stored in our repository during restore process. KubeStash operator will automatically pause the `BackupConfiguration` when a `RestoreSession` is running. However if we want to pause the `BackupConfiguration` manually, we can do that by patching or using KubeStash CLI. - -Let's pause the `mg` BackupConfiguration by patching, -```bash -$ kubectl patch backupconfiguration -n demo mg --type="merge" --patch='{"spec": {"paused": true}}' -backupconfiguration.core.kubestash.com/mg patched -``` - -Now, wait for a moment. KubeStash will pause the BackupConfiguration. Verify that the BackupConfiguration has been paused, - -```console -$ kubectl get backupconfiguration -n demo mg -NAME PHASE PAUSED AGE -mg Ready true 26m -``` - -Notice the `PAUSED` column. Value `true` for this field means that the BackupConfiguration has been paused. - -#### Deploy New MongoDB Database For Restoring: - -We are going to deploy a new mongodb standalone database for restoring backed up data. - -Below is the YAML of a sample `MongoDB` crd that we are going to create - -```yaml -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: restore-mongodb - namespace: demo -spec: - version: "4.2.24" - storageType: Durable - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - terminationPolicy: WipeOut -``` - -Create the above `MongoDB` crd, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/mongodb-restore.yaml -mongodb.kubedb.com/restore-mongodb created -``` - -Let's check if the database is ready to use, - -```console -$ kubectl get mg -n demo restore-mongodb -NAME VERSION STATUS AGE -restore-mongodb 4.2.24 Ready 3m30s -``` - -Let's verify all the databases of this `restore-mongodb` by exec into its pod - -```console -$ export USER=$(kubectl get secrets -n demo restore-mongodb-auth -o jsonpath='{.data.\username}' | base64 -d) - -$ export PASSWORD=$(kubectl get secrets -n demo restore-mongodb-auth -o jsonpath='{.data.\password}' | base64 -d) - -$ kubectl exec -it -n demo restore-mongodb-0 -- mongo admin -u $USER -p $PASSWORD - -> show dbs -admin 0.000GB -config 0.000GB -kubedb-system 0.000GB -local 0.000GB - -> show users -{ - "_id" : "admin.root", - "userId" : UUID("a4decc6b-959a-434d-9e4b-19cb9bfa783b"), - "user" : "root", - "db" : "admin", - "roles" : [ - { - "role" : "root", - "db" : "admin" - } - ], - "mechanisms" : [ - "SCRAM-SHA-1", - "SCRAM-SHA-256" - ] -} - -> exit -bye -``` - -As we can see no database named `newdb` exist in this new `restore-mongodb` database. - -#### Create RestoreSession: - -Now, we need to create a `RestoreSession` crd pointing to the `restore-mongodb` database. -Below is the YAML for the `RestoreSession` crd that we are going to create to restore the backed up data. - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: RestoreSession -metadata: - name: mg-restore - namespace: demo -spec: - target: - name: restore-mongodb - namespace: demo - apiGroup: kubedb.com - kind: MongoDB - dataSource: - snapshot: latest - repository: s3-repo - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackupRestore -``` - -Here, - -- `spec.dataSource.repository` specifies the `Repository` crd that holds the backend information where our backed up data has been stored. -- `spec.target` refers to the `MongoDB` crd for the `restore-mongodb` database. -- `spec.dataSource.snapshot` specifies that we are restoring from the latest backup snapshot of the `spec.dataSource.repository`. - -Let's create the `RestoreSession` crd we have shown above, - -```console -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/restoresession.yaml -restoresession.core.kubestash.com/mg-restore created -``` - -Once, you have created the `RestoreSession` crd, KubeStash will create a job to restore. We can watch the `RestoreSession` phase to check if the restore process is succeeded or not. - -Run the following command to watch `RestoreSession` phase, - -```console -$ kubectl get restoresession -n demo sample-mongodb-restore -w -NAME REPOSITORY FAILURE-POLICY PHASE DURATION AGE -mg-restore s3-repo Succeeded 8s 49s -``` - -So, we can see from the output of the above command that the restore process succeeded. - -#### Verify Restored Data: - -In this section, we are going to verify that the desired data has been restored successfully. We are going to connect to the `restore-mongodb` database and check whether the table we had created earlier is restored or not. - -Lets, exec into the database pod and list available tables, - -```console -$ kubectl exec -it -n demo restore-mongodb-0 -- mongo admin -u $USER -p $PASSWORD - -> show dbs -admin 0.000GB -config 0.000GB -kubedb-system 0.000GB -local 0.000GB -newdb 0.000GB - -> show users -{ - "_id" : "admin.root", - "userId" : UUID("a4decc6b-959a-434d-9e4b-19cb9bfa783b"), - "user" : "root", - "db" : "admin", - "roles" : [ - { - "role" : "root", - "db" : "admin" - } - ], - "mechanisms" : [ - "SCRAM-SHA-1", - "SCRAM-SHA-256" - ] -} - -> use newdb -switched to db newdb - -> db.movie.find().pretty() -{ "_id" : ObjectId("5d19d1cdc93d828f44e37735"), "name" : "batman" } - -> exit -bye -``` - -So, from the above output, we can see the database `newdb` that we had created earlier is restored into another new `MongoDB` database. - -## Cleanup - -To cleanup the Kubernetes resources created by this tutorial, run: - -```console -kubectl delete -n demo restoresession mg-restore -kubectl delete -n demo backupconfiguration mg -kubectl delete -n demo mg sample-mongodb -kubectl delete -n demo mg restore-mongodb -kubectl delete -n demo backupstorage s3-storage -``` diff --git a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/backupconfiguration.yaml b/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/backupconfiguration.yaml deleted file mode 100644 index f4b7178cc..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/backupconfiguration.yaml +++ /dev/null @@ -1,36 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: mg - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: MongoDB - namespace: demo - name: sample-mongodb - backends: - - name: s3-backend - storageRef: - namespace: demo - name: s3-storage - retentionPolicy: - name: backup-rp - namespace: demo - sessions: - - name: frequent - scheduler: - jobTemplate: - backoffLimit: 1 - schedule: "*/3 * * * *" - repositories: - - name: s3-repo - backend: s3-backend - directory: /mongodb - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackup \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/backupstorage.yaml b/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/backupstorage.yaml deleted file mode 100644 index 4bed4eee3..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/backupstorage.yaml +++ /dev/null @@ -1,18 +0,0 @@ -apiVersion: storage.kubestash.com/v1alpha1 -kind: BackupStorage -metadata: - name: s3-storage - namespace: demo -spec: - storage: - provider: s3 - s3: - endpoint: us-east-1.linodeobjects.com - bucket: kubestash-testing - region: us-east-1 - prefix: demo - secretName: s3-secret - usagePolicy: - allowedNamespaces: - from: All - deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/mongodb-restore.yaml b/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/mongodb-restore.yaml deleted file mode 100644 index eaa55e00f..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/mongodb-restore.yaml +++ /dev/null @@ -1,16 +0,0 @@ -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: restore-mongodb - namespace: demo -spec: - version: "4.2.24" - storageType: Durable - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - terminationPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/mongodb.yaml b/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/mongodb.yaml deleted file mode 100644 index abaed3c01..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/mongodb.yaml +++ /dev/null @@ -1,16 +0,0 @@ -apiVersion: kubedb.com/v1alpha2 -kind: MongoDB -metadata: - name: sample-mongodb - namespace: demo -spec: - version: "4.2.24" - storageType: Durable - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - terminationPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/restoresession.yaml b/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/restoresession.yaml deleted file mode 100644 index 1020635be..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/restoresession.yaml +++ /dev/null @@ -1,21 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: RestoreSession -metadata: - name: mg-restore - namespace: demo -spec: - target: - name: restore-mongodb - namespace: demo - apiGroup: kubedb.com - kind: MongoDB - dataSource: - snapshot: latest - repository: s3-repo - encryptionSecret: - name: encry-secret - namespace: demo - addon: - name: mongodb-addon - tasks: - - name: LogicalBackupRestore \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/retentionpolicy.yaml b/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/retentionpolicy.yaml deleted file mode 100644 index 3d327f9a7..000000000 --- a/docs/guides/mongodb/backup/kubestash/logical/standalone/examples/retentionpolicy.yaml +++ /dev/null @@ -1,12 +0,0 @@ -apiVersion: storage.kubestash.com/v1alpha1 -kind: RetentionPolicy -metadata: - name: backup-rp - namespace: demo -spec: - maxRetentionPeriod: 2mo - successfulSnapshots: - last: 10 - usagePolicy: - allowedNamespaces: - from: All \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/overview/_index.md b/docs/guides/mongodb/backup/kubestash/overview/_index.md deleted file mode 100644 index b09365f90..000000000 --- a/docs/guides/mongodb/backup/kubestash/overview/_index.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -title: MongoDB Backup & Restore Overview | KubeStash -menu: - docs_{{ .version }}: - identifier: guides-mongodb-backup-kubestash-overview - name: Overview - parent: guides-mongodb-backup-stashv2 - weight: 10 -menu_name: docs_{{ .version }} ---- - -> New to KubeDB? Please start [here](/docs/README.md). - -{{< notice type="warning" message="This is an Enterprise-only feature. Please install [KubeStash Enterprise Edition] to try this feature. You can use KubeDB Enterprise license to install KubeStash Enterprise edition. Database backup with KubeStash is already included in the KubeDB Enterprise license. So, you don't need a separate license for KubeStash." >}} - -# MongoDB Backup & Restore Overview - -KubeDB can also uses [KubeStash](https://kubestash.com/) to backup and restore databases. KubeStash by AppsCode is a cloud native data backup and recovery solution for Kubernetes workloads. KubeStash utilizes [restic](https://github.com/restic/restic) to securely backup stateful applications to any cloud or on-prem storage backends (for example, S3, GCS, Azure Blob storage, Minio, NetApp, Dell EMC etc.). - -## How Backup Works - -The following diagram shows how KubeStash takes backup of a MongoDB database. Open the image in a new tab to see the enlarged version. - -
- MongoDB Backup Overview -
Fig: MongoDB Backup Overview
-
- -The backup process consists of the following steps: - -1. At first, a user creates a secret with access credentials of the backend where the backed up data will be stored. - -2. Then, she creates a `BackupStorage` crd that specifies the backend information along with the secret that holds the credentials to access the backend. - -3. Then, she creates a `BackupConfiguration` crd targeting the crd of the desired `MongoDB` database. The `BackupConfiguration` object also specifies the `Sessions` to use to backup the database. - -4. KubeStash operator watches for `BackupConfiguration` crd. - -5. Once KubeStash operator finds a `BackupConfiguration` crd, it creates a CronJob with the schedule specified in `BackupConfiguration` object to trigger backup periodically. - -6. On the next scheduled slot, the CronJob triggers a backup by creating a `BackupSession` crd. - -7. KubeStash operator also watches for `BackupSession` crd. - -8. When it finds a `BackupSession` object, It creates a `Snapshot` for holding backup information. - -9. KubeStash resolves the respective `Addon` and `Function` and prepares a Job definition to backup. - -10. Then, it creates the Job to backup the targeted database. - -11. The backup Job reads necessary information to connect with the database from the `AppBinding` crd of the targated `MongoDB` database. It also reads backend information and access credentials from `BackupStorage` crd and Storage Secret respectively through `Backend` section of `BackupConfiguration` crd - -12. Then, the Job dumps the targeted database and uploads the output to the backend. KubeStash pipes the output of dump command to uploading process. Hence, backup Job does not require a large volume to hold the entire dump output. - -13. Finally, when the backup is complete, the Job sends Prometheus metrics to the Pushgateway running inside KubeStash operator pod. It also updates the `BackupSession` and `Snapshot` status to reflect the backup procedure. - -### Backup Different MongoDB Configurations - -This section will show you how backup works for different MongoDB configurations. - -#### Standalone MongoDB - -For a standalone MongoDB database, the backup job directly dumps the database using `mongodump` and pipe the output to the backup process. - -
- Standalone MongoDB Backup Overview -
Fig: Standalone MongoDB Backup
-
- -#### MongoDB ReplicaSet Cluster - -For MongoDB ReplicaSet cluster, KubeStash takes backup from one of the secondary replicas. The backup process consists of the following steps: - -1. Identify a secondary replica. -2. Lock the secondary replica. -3. Backup the secondary replica. -4. Unlock the secondary replica. - -
- MongoDB ReplicaSet Cluster Backup Overview -
Fig: MongoDB ReplicaSet Cluster Backup
-
- -#### MongoDB Sharded Cluster - -For MongoDB sharded cluster, KubeStash takes backup of the individual shards as well as the config server. KubeStash takes backup from a secondary replica of the shards and the config server. If there is no secondary replica then KubeStash will take backup from the primary replica. The backup process consists of the following steps: - -1. Disable balancer. -2. Lock config server. -3. Identify a secondary replica for each shard. -4. Lock the secondary replica. -5. Run backup on the secondary replica. -6. Unlock the secondary replica. -7. Unlock config server. -8. Enable balancer. - -
- MongoDB Sharded Cluster Backup Overview -
Fig: MongoDB Sharded Cluster Backup
-
- -## How Restore Process Works - -The following diagram shows how KubeStash restores backed up data into a MongoDB database. Open the image in a new tab to see the enlarged version. - -
- Database Restore Overview -
Fig: MongoDB Restore Process Overview
-
- -The restore process consists of the following steps: - -1. At first, a user creates a `RestoreSession` crd targeting the `AppBinding` of the desired database where the backed up data will be restored. It also specifies the `Repository` crd which holds the backend information and the `Task` to use to restore the target. - -2. KubeStash operator watches for `RestoreSession` object. - -3. Once it finds a `RestoreSession` object, it resolves the respective `Task` and `Function` and prepares a Job definition to restore. - -4. Then, it creates the Job to restore the target. - -5. The Job reads necessary information to connect with the database from respective `AppBinding` crd. It also reads backend information and access credentials from `Repository` crd and Storage Secret respectively. - -6. Then, the job downloads the backed up data from the backend and injects into the desired database. KubeStash pipes the downloaded data to the respective database tool to inject into the database. Hence, restore job does not require a large volume to download entire backup data inside it. - -7. Finally, when the restore process is complete, the Job sends Prometheus metrics to the Pushgateway and update the `RestoreSession` status to reflect restore completion. - -### Restoring Different MongoDB Configurations - -This section will show you restore process works for different MongoDB configurations. - -#### Standalone MongoDB - -For a standalone MongoDB database, the restore job downloads the backed up data from the backend and pipe the downloaded data to `mongorestore` command which inserts the data into the desired MongoDB database. - -
- Standalone MongoDB Restore Overview -
Fig: Standalone MongoDB Restore
-
- -#### MongoDB ReplicaSet Cluster - -For MongoDB ReplicaSet cluster, KubeStash identifies the primary replica and restore into it. - -
- MongoDB ReplicaSet Cluster Restore Overview -
Fig: MongoDB ReplicaSet Cluster Restore
-
- -#### MongoDB Sharded Cluster - -For MongoDB sharded cluster, KubeStash identifies the primary replica of each shard as well as the config server and restore respective backed up data into them. - -
- MongoDB Sharded Cluster Restore -
Fig: MongoDB Sharded Cluster Restore
-
- -## Next Steps - -- Backup a standalone MongoDB databases using KubeStash following the guide from [here](/docs/guides/mongodb/backup/kubestash/logical/standalone/_index.md). -- Backup a MongoDB Replicaset cluster using Stash following the guide from [here](/docs/guides/mongodb/backup/kubestash/logical/replicaset/_index.md). -- Backup a sharded MongoDB cluster using KubeStash following the guide from [here](/docs/guides/mongodb/backup/kubestash/logical/sharding/_index.md). - - diff --git a/docs/guides/mongodb/backup/kubestash/overview/images/backup_overview.svg b/docs/guides/mongodb/backup/kubestash/overview/images/backup_overview.svg deleted file mode 100644 index d2c6722b0..000000000 --- a/docs/guides/mongodb/backup/kubestash/overview/images/backup_overview.svg +++ /dev/null @@ -1 +0,0 @@ - \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/overview/images/replicaset_backup.svg b/docs/guides/mongodb/backup/kubestash/overview/images/replicaset_backup.svg deleted file mode 100644 index e41cdcc77..000000000 --- a/docs/guides/mongodb/backup/kubestash/overview/images/replicaset_backup.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
KubeStash
Backup Job
KubeStash...
R1
R1
R2
R2
R3
R3
MongoDB
ReplicaSet
Cluster
MongoDB...
Primary
Primary
Secondary
Secondary
Secondary
Secondary
mongodump
mongodumpText is not SVG - cannot display \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/overview/images/replicaset_restore.svg b/docs/guides/mongodb/backup/kubestash/overview/images/replicaset_restore.svg deleted file mode 100644 index c6cfa868b..000000000 --- a/docs/guides/mongodb/backup/kubestash/overview/images/replicaset_restore.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
KubeStash
Backup Job
KubeStash...
R1
R1
R2
R2
R3
R3
MongoDB
ReplicaSet
Cluster
MongoDB...
Primary
Primary
Secondary
Secondary
Secondary
Secondary
mongodump
mongodumpText is not SVG - cannot display \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/overview/images/restore_overview.svg b/docs/guides/mongodb/backup/kubestash/overview/images/restore_overview.svg deleted file mode 100644 index 2b587b058..000000000 --- a/docs/guides/mongodb/backup/kubestash/overview/images/restore_overview.svg +++ /dev/null @@ -1 +0,0 @@ - \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/overview/images/sharded_backup.svg b/docs/guides/mongodb/backup/kubestash/overview/images/sharded_backup.svg deleted file mode 100644 index 3e0b4cb46..000000000 --- a/docs/guides/mongodb/backup/kubestash/overview/images/sharded_backup.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
KubeStash
Backup Job
KubeStash...
R1
R1
R2
R2
R3
R3
MongoDB
ReplicaSet
Cluster
MongoDB...
Primary
Primary
Secondary
Secondary
Secondary
Secondary
mongodump
mongodumpText is not SVG - cannot display \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/overview/images/sharded_restore.svg b/docs/guides/mongodb/backup/kubestash/overview/images/sharded_restore.svg deleted file mode 100644 index 25b7126c0..000000000 --- a/docs/guides/mongodb/backup/kubestash/overview/images/sharded_restore.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
KubeStash
Backup Job
KubeStash...
R1
R1
R2
R2
R3
R3
MongoDB
ReplicaSet
Cluster
MongoDB...
Primary
Primary
Secondary
Secondary
Secondary
Secondary
mongodump
mongodumpText is not SVG - cannot display \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/overview/images/standalone_backup.svg b/docs/guides/mongodb/backup/kubestash/overview/images/standalone_backup.svg deleted file mode 100644 index 47eb24665..000000000 --- a/docs/guides/mongodb/backup/kubestash/overview/images/standalone_backup.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
KubeStash
Backup Job
KubeStash...
MongoDB
MongoDB
mongodump
mongodumpText is not SVG - cannot display \ No newline at end of file diff --git a/docs/guides/mongodb/backup/kubestash/overview/images/standalone_restore.svg b/docs/guides/mongodb/backup/kubestash/overview/images/standalone_restore.svg deleted file mode 100644 index 1c72f07bb..000000000 --- a/docs/guides/mongodb/backup/kubestash/overview/images/standalone_restore.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
KubeStash
Backup Job
KubeStash...
R1
R1
R2
R2
R3
R3
MongoDB
ReplicaSet
Cluster
MongoDB...
Primary
Primary
Secondary
Secondary
Secondary
Secondary
mongodump
mongodumpText is not SVG - cannot display \ No newline at end of file