docs(migrationreplicatedDB): added a new section for backup and restore

SUMMARY.md

@@ -37,6 +37,9 @@
 * [Tested Third Party Software](reference/tested-third-party-software.md)
 * [Migrate etcd](quickstart/migrate-etcd.md)
 * [Scale etcd](quickstart/scale-etcd.md)
+* [Migration for Replicated DB](migration-cstor-mayastor\replicateddb-overview.md)
+  * [Backup from cStor](migration-cstor-mayastor\replicateddb-backup.md)
+  * [Restore to Mayastor](migration-cstor-mayastor\replicateddb-restore.md)
 
 ## Platform Support
 

migration-cstor-mayastor/replicateddb-backup.md

@@ -0,0 +1,204 @@
+# Steps to take a Backup from cStor for Replicated DB (Mongo)
+
+{% hint style="note" %}
+If you are deploying databases using operators, you need to find a way to actively modify the entire deployment through the operator. This ensures that you control and manage changes effectively within the operator-driven database deployment.
+{% endhint %}
+
+## Step 1: Backup from cStor Cluster
+
+Currently, we have a cStor cluster as the source, with a clustered MongoDB running as a StatefulSet using cStor volumes. 
+
+
+{% tabs %}
+{% tab title="Command" %}
+```text
+kubectl get pods
+```
+{% endtab %}
+
+{% tab title="Output" %}
+```text
+NAME                            READY   STATUS    RESTARTS   AGE
+mongo-client-758ddd54cc-h2gwl   1/1     Running   0          47m
+mongod-0                        1/1     Running   0          47m
+mongod-1                        1/1     Running   0          44m
+mongod-2                        1/1     Running   0          42m
+ycsb-775fc86c4b-kj5vv           1/1     Running   0          47m
+```
+{% endtab %}
+{% endtabs %}
+
+
+{% tabs %}
+{% tab title="Command" %}
+```text
+kubectl get pvc
+```
+{% endtab %}
+
+{% tab title="Output" %}
+```text
+NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     AGE
+mongodb-persistent-storage-claim-mongod-0   Bound    pvc-cb115a0b-07f4-4912-b686-e160e8a0690d   3Gi        RWO            cstor-csi-disk   54m
+mongodb-persistent-storage-claim-mongod-1   Bound    pvc-c9214764-7670-4cda-87e3-82f0bc59d8c7   3Gi        RWO            cstor-csi-disk   52m
+mongodb-persistent-storage-claim-mongod-2   Bound    pvc-fc1f7ed7-d99e-40c7-a9b7-8d6244403a3e   3Gi        RWO            cstor-csi-disk   50m
+```
+{% endtab %}
+{% endtabs %}
+
+{% tabs %}
+{% tab title="Command" %}
+```text
+kubectl get cvc -n openebs
+```
+{% endtab %}
+
+{% tab title="Output" %}
+```text
+NAME                                       CAPACITY   STATUS   AGE
+pvc-c9214764-7670-4cda-87e3-82f0bc59d8c7   3Gi        Bound    53m
+pvc-cb115a0b-07f4-4912-b686-e160e8a0690d   3Gi        Bound    55m
+pvc-fc1f7ed7-d99e-40c7-a9b7-8d6244403a3e   3Gi        Bound    50m
+```
+{% endtab %}
+{% endtabs %}
+
+
+## Step 2: Install Velero
+
+{% hint style="note" %}
+For the prerequisites, refer to the [overview](migration-cstor-mayastor\replicateddb-overview.md) section.
+{% endhint %}
+
+Run the following command to install Velero:
+
+{% tabs %}
+{% tab title="Command" %}
+```text
+velero install --use-node-agent --provider gcp --plugins velero/velero-plugin-for-gcp:v1.6.0 --bucket velero-backup-datacore --secret-file ./credentials-velero --uploader-type restic
+```
+{% endtab %}
+
+{% tab title="Output" %}
+```text
+[Installation progress output]
+```
+{% endtab %}
+{% endtabs %}
+
+Verify the Velero namespace for Node Agent and Velero pods:
+
+{% tabs %}
+{% tab title="Command" %}
+```text
+kubectl get pods -n velero
+```
+{% endtab %}
+
+{% tab title="Output" %}
+```text
+NAME                      READY   STATUS    RESTARTS   AGE
+node-agent-cwkrn          1/1     Running   0          43s
+node-agent-qg6hd          1/1     Running   0          43s
+node-agent-v6xbk          1/1     Running   0          43s
+velero-56c45f5c64-4hzn7   1/1     Running   0          43s
+```
+{% endtab %}
+{% endtabs %}
+
+
+
+
+## Step 3: Data Validation
+
+On the Primary Database (mongo-0) you can see some sample data.
+
+![](https://hackmd.io/_uploads/HkNDm0CJa.png)
+
+You can also see the data available on the replicated secondary databases.
+
+![](https://hackmd.io/_uploads/H1aKmRCkT.png)
+
+
+## Step 4: Take Velero Backup
+
+MongoDB uses replication, and data partitioning (sharding) for high availability and scalability. Taking a backup of the primary database is enough as the data gets replicated to the secondary databases. Restoring both primary and secondary at the same time can cause data corruption.
+
+For reference: [MongoDB Backup and Restore Error Using Velero](https://www.mongodb.com/community/forums/t/mongodb-backup-and-restore-error-using-velero-and-minio-on-premise-kubernetes-cluster/223683/3)
+
+Velero supports two approaches for discovering pod volumes to be backed up using FSB:
+
+1. **Opt-in approach**: Annotate pods containing volumes to be backed up.
+2. **Opt-out approach**: Backup all pod volumes with the ability to opt-out specific volumes.
+
+### Opt-In for Primary MongoDB Pod:
+
+To ensure that our primary MongoDB pod, which receives writes and replicates data to secondary pods, is included in the backup, we need to annotate it as follows:
+
+```
+kubectl annotate pod/mongod-0 backup.velero.io/backup-volumes=mongodb-persistent-storage-claim
+```
+
+### Opt-Out for Secondary MongoDB Pods and PVCs:
+
+To exclude secondary MongoDB pods and their associated Persistent Volume Claims (PVCs) from the backup, we can label them as follows:
+
+```
+kubectl label pod mongod-1 velero.io/exclude-from-backup=true
+pod/mongod-1 labeled
+```
+
+```
+kubectl label pod mongod-2 velero.io/exclude-from-backup=true
+pod/mongod-2 labeled
+```
+
+```
+kubectl label pvc mongodb-persistent-storage-claim-mongod-1 velero.io/exclude-from-backup=true
+persistentvolumeclaim/mongodb-persistent-storage-claim-mongod-1 labeled
+```
+
+```
+kubectl label pvc mongodb-persistent-storage-claim-mongod-2 velero.io/exclude-from-backup=true
+persistentvolumeclaim/mongodb-persistent-storage-claim-mongod-2 labeled
+```
+
+### Backup Execution:
+
+Create a backup of the entire namespace. If any other applications run in the same namespace as MongoDB, we can exclude them from the backup using labels or flags from the Velero CLI:
+
+{% tabs %}
+{% tab title="Command" %}
+```text
+velero backup create mongo-backup-13-09-23 --include-namespaces default --default-volumes-to-fs-backup --wait
+```
+{% endtab %}
+
+{% tab title="Output" %}
+```text
+Backup request "mongo-backup-13-09-23" submitted successfully.
+Waiting for backup to complete. You may safely press ctrl-c to stop waiting - your backup will continue in the background.
+...........
+Backup completed with status: Completed. You may check for more information using the commands `velero backup describe mongo-backup-13-09-23` and `velero backup logs mongo-backup-13-09-23`.
+```
+{% endtab %}
+{% endtabs %}
+
+### Backup Verification:
+
+To check the status of the backup using the Velero CLI, you can use the following command. If the backup fails for any reason, you can inspect the logs with the velero backup logs command:
+
+
+{% tabs %}
+{% tab title="Command" %}
+```text
+velero get backup | grep 13-09-23
+```
+{% endtab %}
+
+{% tab title="Output" %}
+```text
+mongo-backup-13-09-23     Completed   0        0          2023-09-13 13:15:32 +0000 UTC   29d       default            <none>
+```
+{% endtab %}
+{% endtabs %}

migration-cstor-mayastor/replicateddb-overview.md

@@ -0,0 +1,16 @@
+# Migrating from CStor to Mayastor for Replicated Databases (MongoDB)
+
+
+This documentation provides a comprehensive guide on migrating CStor application volumes to Mayastor. We utilize Velero for the backup and restoration process, enabling a seamless transition from a CStor cluster to Mayastor. This example specifically focuses on a GKE cluster.
+
+Velero offers support for the backup and restoration of Kubernetes volumes attached to pods directly from the volume's file system. This is known as File System Backup (FSB) or Pod Volume Backup. The data movement is facilitated through the use of modules from free, open-source backup tools such as Restic (which is the tool of choice in this guide).
+
+- For cloud providers, you can find the necessary plugins [here](https://velero.io/docs/main/supported-providers/).
+- For detailed Velero GKE configuration prerequisites, refer to [this resource](https://github.com/vmware-tanzu/velero-plugin-for-gcp#setup).
+- It's essential to note that Velero requires an object storage bucket for storing backups, and in our case, we use a [Google Cloud Storage (GCS) bucket](https://github.com/vmware-tanzu/velero-plugin-for-gcp#setup).
+- For detailed instructions on Velero basic installation, visit https://velero.io/docs/v1.11/basic-install/.
+
+
+
+
+