Add SingleStore KubeStash Docs (#681)

Signed-off-by: Ashraful Haque Tani <[email protected]>
Co-authored-by: Anisur Rahman <[email protected]>

docs/guides/mysql/backup/kubestash/auto-backup/index.md

@@ -329,7 +329,7 @@ Once a backup is complete, KubeStash will update the respective `Repository` CR
 
 ```bash
 $ kubectl get repository -n demo default-blueprint
-NAME                       INTEGRITY   SNAPSHOT-COUNT   SIZE    PHASE   LAST-SUCCESSFUL-BACKUP   AGE
+NAME                    INTEGRITY   SNAPSHOT-COUNT   SIZE    PHASE   LAST-SUCCESSFUL-BACKUP   AGE
 default-blueprint          true        1                806 B   Ready   8m27s                    9m18s
 ```
 

docs/guides/mysql/backup/kubestash/customization/index.md

@@ -281,6 +281,7 @@ spec:
 
 KubeStash also uses `mysql` 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 `addon.tasks[*].params` section. 

docs/guides/postgres/backup/kubestash/application-level/index.md

@@ -497,6 +497,7 @@ gcs-postgres-repo-sample-postgres-backup-frequent-backup-1725449400   gcs-postgr
 ```
 
 > Note: KubeStash creates a `Snapshot` with the following labels:
+> - `kubedb.com/db-version: <db-version>`
 > - `kubestash.com/app-ref-kind: <target-kind>`
 > - `kubestash.com/app-ref-name: <target-name>`
 > - `kubestash.com/app-ref-namespace: <target-namespace>`
@@ -519,6 +520,7 @@ metadata:
   - kubestash.com/cleanup
   generation: 1
   labels:
+    kubedb.com/db-version: "16.1"
     kubestash.com/app-ref-kind: Postgres
     kubestash.com/app-ref-name: sample-postgres
     kubestash.com/app-ref-namespace: demo
@@ -630,7 +632,6 @@ spec:
   manifestOptions:
     postgres:
       restoreNamespace: dev
-      db: true
   dataSource:
     repository: gcs-postgres-repo
     snapshot: latest
@@ -682,6 +683,7 @@ sample-postgres   16.1      Ready    9m46s
 
 The output confirms that the `PostgreSQL` database has been successfully created with the same configuration as it had at the time of backup.
 
+
 #### Verify Restored Data:
 
 In this section, we are going to verify whether the desired data has been restored successfully. We are going to connect to the database server and check whether the database and the table we created earlier in the original database are restored.
@@ -740,15 +742,6 @@ demo=# \d
  public | company | table | postgres
 (1 row)
 
-# Verify that the sample data has been restored 
-demo=# SELECT * FROM COMPANY;
-    name     | employee 
--------------+----------
- TechCorp    |      100
- InnovateInc |      150
- AlphaTech   |      200
-(3 rows)
-
 # disconnect from the database
 demo=# \q
 

docs/guides/postgres/backup/kubestash/auto-backup/index.md

@@ -44,6 +44,7 @@ namespace/demo created
 
 > **Note:** YAML files used in this tutorial are stored in [docs/guides/postgres/backup/kubestash/auto-backup/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/postgres/backup/kubestash/auto-backup/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository.
 
+
 ### Prepare Backend
 
 We are going to store our backed up data into a `GCS` bucket. We have to create a `Secret` with necessary credentials and a `BackupStorage` CR to use this backend. If you want to use a different backend, please read the respective backend configuration doc from [here](https://kubestash.com/docs/latest/guides/backends/overview/).
@@ -160,6 +161,7 @@ spec:
       from: All
   backupConfigurationTemplate:
     deletionPolicy: OnDelete
+    # ============== Blueprint for Backends of BackupConfiguration  =================
     backends:
       - name: gcs-backend
         storageRef:
@@ -168,6 +170,7 @@ spec:
         retentionPolicy:
           name: demo-retention
           namespace: demo
+    # ============== Blueprint for Sessions of BackupConfiguration  =================
     sessions:
       - name: frequent-backup
         sessionHistoryLimit: 3
@@ -390,6 +393,7 @@ default-blueprint-appbinding-samgres-frequent-backup-1725533628   default-bluepr
 ```
 
 > Note: KubeStash creates a `Snapshot` with the following labels:
+> - `kubedb.com/db-version: <db-version>`
 > - `kubestash.com/app-ref-kind: <target-kind>`
 > - `kubestash.com/app-ref-name: <target-name>`
 > - `kubestash.com/app-ref-namespace: <target-namespace>`
@@ -553,6 +557,7 @@ backupblueprint.core.kubestash.com/postgres-customize-backup-blueprint created
 
 Now, we are ready to backup our `PostgreSQL` databases using few annotations. You can check available auto-backup annotations for a databases from [here](https://kubestash.com/docs/latest/concepts/crds/backupblueprint/).
 
+
 **Create Database**
 
 Now, we are going to create an `PostgreSQL` CR in demo namespace.
@@ -727,6 +732,7 @@ appbinding-sample-postgres-frequent-backup-1725597000     BackupConfiguration
 
 We can see from the above output that the backup session has succeeded. Now, we are going to verify whether the backed up data has been stored in the backend.
 
+
 **Verify Backup:**
 
 Once a backup is complete, KubeStash will update the respective `Repository` CR to reflect the backup. Check that the repository `customize-blueprint` has been updated by the following command,

docs/guides/postgres/backup/kubestash/customization/index.md

@@ -279,35 +279,6 @@ spec:
 
 `KubeStash` uses [psql](https://www.postgresql.org/docs/current/app-psql.html) 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
-
-You can pass any supported `psql` arguments to the restore process using the `args` field within the `addon.tasks[*].params` section. This example demonstrates how to specify a database `testdb` to connect to during the restore process.
-
-```yaml
-apiVersion: core.kubestash.com/v1alpha1
-kind: RestoreSession
-metadata:
-  name: sample-postgres-restore
-  namespace: demo
-spec:
-  target:
-    apiGroup: kubedb.com
-    kind: Postgres
-    namespace: demo
-    name: restored-postgres
-  dataSource:
-    repository: gcs-postgres-repo
-    snapshot: latest
-    encryptionSecret:
-      name: encrypt-secret
-      namespace: demo
-  addon:
-    name: postgres-addon
-    tasks:
-      - name: logical-backup-restore
-        params:
-          args: --dbname=testdb
-```
 
 ### Restore specific snapshot
 
@@ -348,6 +319,7 @@ spec:
       - name: logical-backup-restore
 ```
 
+
 ### Running restore job as a specific user
 
 Similar to the backup process under the `addon.jobTemplate.spec.` you can provide `securityContext` to run the restore job as a specific user.

docs/guides/postgres/backup/kubestash/logical/index.md

@@ -497,6 +497,7 @@ gcs-postgres-repo-sample-postgres-backup-frequent-backup-1725449400   gcs-postgr
 ```
 
 > Note: KubeStash creates a `Snapshot` with the following labels:
+> - `kubedb.com/db-version: <db-version>`
 > - `kubestash.com/app-ref-kind: <target-kind>`
 > - `kubestash.com/app-ref-name: <target-name>`
 > - `kubestash.com/app-ref-namespace: <target-namespace>`
@@ -587,6 +588,7 @@ Now, if we navigate to the GCS bucket, we will see the backed up data stored in
 
 > Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted.
 
+
 ## Restore
 
 In this section, we are going to restore the database from the backup we have taken in the previous section. We are going to deploy a new database and initialize it from the backup.
@@ -631,7 +633,7 @@ If you check the database status, you will see it is stuck in **`Provisioning`**
 
 ```bash
 $ kubectl get postgres -n demo restored-postgres
-NAME                VERSION   STATUS         AGE
+NAME              VERSION   STATUS         AGE
 restored-postgres   8.2.0     Provisioning   61s
 ```
 
@@ -674,7 +676,7 @@ Here,
 Let's create the RestoreSession CRD object we have shown above,
 
 ```bash
-$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/postgres/backup/kubestash/logical/examples/restoresession.yaml
+$ kubectl apply -f **https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/postgres/backup/kubestash/logical/examples/restoresession.yaml
 restoresession.core.kubestash.com/sample-postgres-restore created
 ```
 
@@ -764,17 +766,18 @@ demo=# \q
 
 So, from the above output, we can see the `demo` database we had created in the original database `sample-postgres` has been restored in the `restored-postgres` database.
 
+
 ## Cleanup
 
 To cleanup the Kubernetes resources created by this tutorial, run:
 
 ```bash
 kubectl delete backupconfigurations.core.kubestash.com  -n demo sample-postgres-backup
 kubectl delete restoresessions.core.kubestash.com -n demo restore-sample-postgres
-kubectl delete retentionpolicies.storage.kubestash.com -n demo demo-retention
 kubectl delete backupstorage -n demo gcs-storage
 kubectl delete secret -n demo gcs-secret
 kubectl delete secret -n demo encrypt-secret
+kubectl delete retentionpolicies.storage.kubestash.com -n demo demo-retention
 kubectl delete postgres -n demo restored-postgres
 kubectl delete postgres -n demo sample-postgres
 ```

docs/guides/singlestore/backup/_index.md

@@ -0,0 +1,10 @@
+---
+title: Backup & Restore SingleStore
+menu:
+  docs_{{ .version }}:
+    identifier: guides-sdb-backup
+    name: Backup & Restore
+    parent: guides-singlestore
+    weight: 40
+menu_name: docs_{{ .version }}
+---

docs/guides/singlestore/backup/kubestash/_index.md

@@ -0,0 +1,10 @@
+---
+title: Backup & Restore SingleStore | KubeStash
+menu:
+  docs_{{ .version }}:
+    identifier: guides-sdb-backup-stashv2
+    name: KubeStash (aka Stash 2.0)
+    parent: guides-sdb-backup
+    weight: 50
+menu_name: docs_{{ .version }}
+---

docs/guides/singlestore/backup/kubestash/application-level/examples/backupconfiguration.yaml

@@ -0,0 +1,37 @@
+apiVersion: core.kubestash.com/v1alpha1
+kind: BackupConfiguration
+metadata:
+  name: sample-singlestore-backup
+  namespace: demo
+spec:
+  target:
+    apiGroup: kubedb.com
+    kind: Singlestore
+    namespace: demo
+    name: sample-singlestore
+  backends:
+    - name: gcs-backend
+      storageRef:
+        namespace: demo
+        name: gcs-storage
+      retentionPolicy:
+        name: demo-retention
+        namespace: demo
+  sessions:
+    - name: frequent-backup
+      scheduler:
+        schedule: "*/5 * * * *"
+        jobTemplate:
+          backoffLimit: 1
+      repositories:
+        - name: gcs-singlestore-repo
+          backend: gcs-backend
+          directory: /singlestore
+          encryptionSecret:
+            name: encrypt-secret
+            namespace: demo
+      addon:
+        name: singlestore-addon
+        tasks:
+          - name: manifest-backup
+          - name: logical-backup

docs/guides/singlestore/backup/kubestash/application-level/examples/backupstorage.yaml

@@ -0,0 +1,17 @@
+apiVersion: storage.kubestash.com/v1alpha1
+kind: BackupStorage
+metadata:
+  name: gcs-storage
+  namespace: demo
+spec:
+  storage:
+    provider: gcs
+    gcs:
+      bucket: kubestash-qa
+      prefix: demo
+      secretName: gcs-secret
+  usagePolicy:
+    allowedNamespaces:
+      from: All
+  default: true
+  deletionPolicy: Delete

docs/guides/singlestore/backup/kubestash/application-level/examples/restoresession.yaml

@@ -0,0 +1,20 @@
+apiVersion: core.kubestash.com/v1alpha1
+kind: RestoreSession
+metadata:
+  name: restore-sample-singlestore
+  namespace: demo
+spec:
+  manifestOptions:
+    singlestore:
+      restoreNamespace: dev
+  dataSource:
+    repository: gcs-singlestore-repo
+    snapshot: latest
+    encryptionSecret:
+      name: encrypt-secret
+      namespace: demo
+  addon:
+    name: singlestore-addon
+    tasks:
+      - name: logical-backup-restore
+      - name: manifest-restore

docs/guides/singlestore/backup/kubestash/application-level/examples/retentionpolicy.yaml

@@ -0,0 +1,15 @@
+apiVersion: storage.kubestash.com/v1alpha1
+kind: RetentionPolicy
+metadata:
+  name: demo-retention
+  namespace: demo
+spec:
+  default: true
+  failedSnapshots:
+    last: 2
+  maxRetentionPeriod: 2mo
+  successfulSnapshots:
+    last: 5
+  usagePolicy:
+    allowedNamespaces:
+      from: All

docs/guides/singlestore/backup/kubestash/application-level/examples/sample-singlestore.yaml

@@ -0,0 +1,50 @@
+apiVersion: kubedb.com/v1alpha2
+kind: Singlestore
+metadata:
+  name: sample-singlestore
+  namespace: demo
+spec:
+  version: "8.7.10"
+  topology:
+    aggregator:
+      replicas: 2
+      podTemplate:
+        spec:
+          containers:
+          - name: singlestore
+            resources:
+              limits:
+                memory: "2Gi"
+                cpu: "600m"
+              requests:
+                memory: "2Gi"
+                cpu: "600m"
+      storage:
+        accessModes:
+        - ReadWriteOnce
+        resources:
+          requests:
+            storage: 1Gi
+    leaf:
+      replicas: 3
+      podTemplate:
+        spec:
+          containers:
+            - name: singlestore
+              resources:
+                limits:
+                  memory: "2Gi"
+                  cpu: "600m"
+                requests:
+                  memory: "2Gi"
+                  cpu: "600m"                      
+      storage:
+        accessModes:
+          - ReadWriteOnce
+        resources:
+          requests:
+            storage: 10Gi
+  licenseSecret:
+    name: license-secret
+  storageType: Durable
+  deletionPolicy: WipeOut