From 4108b42af1f4efbba0b7d9ce91911845235475f4 Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Mon, 16 Sep 2024 15:34:17 +0600 Subject: [PATCH 01/11] Keep separate section for stash Signed-off-by: Neaj Morshad --- docs/guides/redis/backup/{ => stash}/_index.md | 0 .../auto-backup/examples/backupblueprint.yaml | 0 .../auto-backup/examples/sample-redis-1.yaml | 0 .../auto-backup/examples/sample-redis-2.yaml | 0 .../auto-backup/examples/sample-redis-3.yaml | 0 .../auto-backup/images/sample-redis-1.png | Bin .../auto-backup/images/sample-redis-2.png | Bin .../auto-backup/images/sample-redis-3.png | Bin .../redis/backup/{ => stash}/auto-backup/index.md | 8 ++++---- .../examples/limits-for-backup-job.yaml | 0 .../examples/limits-for-restore-job.yaml | 0 .../examples/multiple-retention-policy.yaml | 0 .../examples/passing-args-to-backup.yaml | 0 .../examples/passing-args-to-restore.yaml | 0 .../examples/restore-specific-snapshot.yaml | 0 .../examples/run-backup-as-a-specific-user.yaml | 0 .../examples/run-restore-as-a-specific-user.yaml | 0 .../redis/backup/{ => stash}/customization/index.md | 0 .../overview/images/redis-logical-backup.svg | 0 .../overview/images/redis-logical-restore.svg | 0 .../redis/backup/{ => stash}/overview/index.md | 6 +++--- .../standalone/examples/backupconfiguration.yaml | 0 .../{ => stash}/standalone/examples/redis.yaml | 0 .../{ => stash}/standalone/examples/repository.yaml | 0 .../standalone/examples/restoresession.yaml | 0 .../standalone/images/sample-redis-backup.png | Bin .../redis/backup/{ => stash}/standalone/index.md | 4 ++-- docs/guides/redis/initialization/using-script.md | 2 +- docs/guides/redis/reconfigure-tls/sentinel.md | 2 +- docs/guides/redis/reconfigure-tls/standalone.md | 2 +- docs/guides/redis/tls/cluster.md | 2 +- docs/guides/redis/tls/sentinel.md | 2 +- docs/guides/redis/tls/standalone.md | 2 +- 33 files changed, 15 insertions(+), 15 deletions(-) rename docs/guides/redis/backup/{ => stash}/_index.md (100%) rename docs/guides/redis/backup/{ => stash}/auto-backup/examples/backupblueprint.yaml (100%) rename docs/guides/redis/backup/{ => stash}/auto-backup/examples/sample-redis-1.yaml (100%) rename docs/guides/redis/backup/{ => stash}/auto-backup/examples/sample-redis-2.yaml (100%) rename docs/guides/redis/backup/{ => stash}/auto-backup/examples/sample-redis-3.yaml (100%) rename docs/guides/redis/backup/{ => stash}/auto-backup/images/sample-redis-1.png (100%) rename docs/guides/redis/backup/{ => stash}/auto-backup/images/sample-redis-2.png (100%) rename docs/guides/redis/backup/{ => stash}/auto-backup/images/sample-redis-3.png (100%) rename docs/guides/redis/backup/{ => stash}/auto-backup/index.md (99%) rename docs/guides/redis/backup/{ => stash}/customization/examples/limits-for-backup-job.yaml (100%) rename docs/guides/redis/backup/{ => stash}/customization/examples/limits-for-restore-job.yaml (100%) rename docs/guides/redis/backup/{ => stash}/customization/examples/multiple-retention-policy.yaml (100%) rename docs/guides/redis/backup/{ => stash}/customization/examples/passing-args-to-backup.yaml (100%) rename docs/guides/redis/backup/{ => stash}/customization/examples/passing-args-to-restore.yaml (100%) rename docs/guides/redis/backup/{ => stash}/customization/examples/restore-specific-snapshot.yaml (100%) rename docs/guides/redis/backup/{ => stash}/customization/examples/run-backup-as-a-specific-user.yaml (100%) rename docs/guides/redis/backup/{ => stash}/customization/examples/run-restore-as-a-specific-user.yaml (100%) rename docs/guides/redis/backup/{ => stash}/customization/index.md (100%) rename docs/guides/redis/backup/{ => stash}/overview/images/redis-logical-backup.svg (100%) rename docs/guides/redis/backup/{ => stash}/overview/images/redis-logical-restore.svg (100%) rename docs/guides/redis/backup/{ => stash}/overview/index.md (96%) rename docs/guides/redis/backup/{ => stash}/standalone/examples/backupconfiguration.yaml (100%) rename docs/guides/redis/backup/{ => stash}/standalone/examples/redis.yaml (100%) rename docs/guides/redis/backup/{ => stash}/standalone/examples/repository.yaml (100%) rename docs/guides/redis/backup/{ => stash}/standalone/examples/restoresession.yaml (100%) rename docs/guides/redis/backup/{ => stash}/standalone/images/sample-redis-backup.png (100%) rename docs/guides/redis/backup/{ => stash}/standalone/index.md (99%) diff --git a/docs/guides/redis/backup/_index.md b/docs/guides/redis/backup/stash/_index.md similarity index 100% rename from docs/guides/redis/backup/_index.md rename to docs/guides/redis/backup/stash/_index.md diff --git a/docs/guides/redis/backup/auto-backup/examples/backupblueprint.yaml b/docs/guides/redis/backup/stash/auto-backup/examples/backupblueprint.yaml similarity index 100% rename from docs/guides/redis/backup/auto-backup/examples/backupblueprint.yaml rename to docs/guides/redis/backup/stash/auto-backup/examples/backupblueprint.yaml diff --git a/docs/guides/redis/backup/auto-backup/examples/sample-redis-1.yaml b/docs/guides/redis/backup/stash/auto-backup/examples/sample-redis-1.yaml similarity index 100% rename from docs/guides/redis/backup/auto-backup/examples/sample-redis-1.yaml rename to docs/guides/redis/backup/stash/auto-backup/examples/sample-redis-1.yaml diff --git a/docs/guides/redis/backup/auto-backup/examples/sample-redis-2.yaml b/docs/guides/redis/backup/stash/auto-backup/examples/sample-redis-2.yaml similarity index 100% rename from docs/guides/redis/backup/auto-backup/examples/sample-redis-2.yaml rename to docs/guides/redis/backup/stash/auto-backup/examples/sample-redis-2.yaml diff --git a/docs/guides/redis/backup/auto-backup/examples/sample-redis-3.yaml b/docs/guides/redis/backup/stash/auto-backup/examples/sample-redis-3.yaml similarity index 100% rename from docs/guides/redis/backup/auto-backup/examples/sample-redis-3.yaml rename to docs/guides/redis/backup/stash/auto-backup/examples/sample-redis-3.yaml diff --git a/docs/guides/redis/backup/auto-backup/images/sample-redis-1.png b/docs/guides/redis/backup/stash/auto-backup/images/sample-redis-1.png similarity index 100% rename from docs/guides/redis/backup/auto-backup/images/sample-redis-1.png rename to docs/guides/redis/backup/stash/auto-backup/images/sample-redis-1.png diff --git a/docs/guides/redis/backup/auto-backup/images/sample-redis-2.png b/docs/guides/redis/backup/stash/auto-backup/images/sample-redis-2.png similarity index 100% rename from docs/guides/redis/backup/auto-backup/images/sample-redis-2.png rename to docs/guides/redis/backup/stash/auto-backup/images/sample-redis-2.png diff --git a/docs/guides/redis/backup/auto-backup/images/sample-redis-3.png b/docs/guides/redis/backup/stash/auto-backup/images/sample-redis-3.png similarity index 100% rename from docs/guides/redis/backup/auto-backup/images/sample-redis-3.png rename to docs/guides/redis/backup/stash/auto-backup/images/sample-redis-3.png diff --git a/docs/guides/redis/backup/auto-backup/index.md b/docs/guides/redis/backup/stash/auto-backup/index.md similarity index 99% rename from docs/guides/redis/backup/auto-backup/index.md rename to docs/guides/redis/backup/stash/auto-backup/index.md index 061ea48c07..a5b78b49b5 100644 --- a/docs/guides/redis/backup/auto-backup/index.md +++ b/docs/guides/redis/backup/stash/auto-backup/index.md @@ -22,7 +22,7 @@ In this tutorial, we are going to show how you can configure a backup blueprint - At first, you need to have a Kubernetes cluster, and the `kubectl` command-line tool must be configured to communicate with your cluster. - Install KubeDB in your cluster following the steps [here](/docs/setup/README.md). - Install Stash in your cluster following the steps [here](https://stash.run/docs/latest/setup/install/stash/). -- If you are not familiar with how Stash backup and restore Redis databases, please check the following guide [here](/docs/guides/redis/backup/overview/index.md). +- If you are not familiar with how Stash backup and restore Redis databases, please check the following guide [here](/docs/guides/redis/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/). @@ -280,7 +280,7 @@ app-sample-redis-1-1627567808 BackupConfiguration app-sample-redis-1 Succe 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 `prefix` field of the `Repository`.
- Backup data in GCS Bucket + Backup data in GCS Bucket
Fig: Backup data in GCS Bucket
@@ -462,7 +462,7 @@ app-sample-redis-2-1627568283 BackupConfiguration app-sample-redis-2 Succe Once the backup has been completed successfully, you should see that Stash has created a new directory as pointed by the `prefix` field of the new `Repository` and stored the backed up data there.
- Backup data in GCS Bucket + Backup data in GCS Bucket
Fig: Backup data in GCS Bucket
@@ -643,7 +643,7 @@ app-sample-redis-3-1627568709 BackupConfiguration app-sample-redis-3 Succe Once the backup has been completed successfully, you should see that Stash has created a new directory as pointed by the `prefix` field of the new `Repository` and stored the backed up data there.
- Backup data in GCS Bucket + Backup data in GCS Bucket
Fig: Backup data in GCS Bucket
diff --git a/docs/guides/redis/backup/customization/examples/limits-for-backup-job.yaml b/docs/guides/redis/backup/stash/customization/examples/limits-for-backup-job.yaml similarity index 100% rename from docs/guides/redis/backup/customization/examples/limits-for-backup-job.yaml rename to docs/guides/redis/backup/stash/customization/examples/limits-for-backup-job.yaml diff --git a/docs/guides/redis/backup/customization/examples/limits-for-restore-job.yaml b/docs/guides/redis/backup/stash/customization/examples/limits-for-restore-job.yaml similarity index 100% rename from docs/guides/redis/backup/customization/examples/limits-for-restore-job.yaml rename to docs/guides/redis/backup/stash/customization/examples/limits-for-restore-job.yaml diff --git a/docs/guides/redis/backup/customization/examples/multiple-retention-policy.yaml b/docs/guides/redis/backup/stash/customization/examples/multiple-retention-policy.yaml similarity index 100% rename from docs/guides/redis/backup/customization/examples/multiple-retention-policy.yaml rename to docs/guides/redis/backup/stash/customization/examples/multiple-retention-policy.yaml diff --git a/docs/guides/redis/backup/customization/examples/passing-args-to-backup.yaml b/docs/guides/redis/backup/stash/customization/examples/passing-args-to-backup.yaml similarity index 100% rename from docs/guides/redis/backup/customization/examples/passing-args-to-backup.yaml rename to docs/guides/redis/backup/stash/customization/examples/passing-args-to-backup.yaml diff --git a/docs/guides/redis/backup/customization/examples/passing-args-to-restore.yaml b/docs/guides/redis/backup/stash/customization/examples/passing-args-to-restore.yaml similarity index 100% rename from docs/guides/redis/backup/customization/examples/passing-args-to-restore.yaml rename to docs/guides/redis/backup/stash/customization/examples/passing-args-to-restore.yaml diff --git a/docs/guides/redis/backup/customization/examples/restore-specific-snapshot.yaml b/docs/guides/redis/backup/stash/customization/examples/restore-specific-snapshot.yaml similarity index 100% rename from docs/guides/redis/backup/customization/examples/restore-specific-snapshot.yaml rename to docs/guides/redis/backup/stash/customization/examples/restore-specific-snapshot.yaml diff --git a/docs/guides/redis/backup/customization/examples/run-backup-as-a-specific-user.yaml b/docs/guides/redis/backup/stash/customization/examples/run-backup-as-a-specific-user.yaml similarity index 100% rename from docs/guides/redis/backup/customization/examples/run-backup-as-a-specific-user.yaml rename to docs/guides/redis/backup/stash/customization/examples/run-backup-as-a-specific-user.yaml diff --git a/docs/guides/redis/backup/customization/examples/run-restore-as-a-specific-user.yaml b/docs/guides/redis/backup/stash/customization/examples/run-restore-as-a-specific-user.yaml similarity index 100% rename from docs/guides/redis/backup/customization/examples/run-restore-as-a-specific-user.yaml rename to docs/guides/redis/backup/stash/customization/examples/run-restore-as-a-specific-user.yaml diff --git a/docs/guides/redis/backup/customization/index.md b/docs/guides/redis/backup/stash/customization/index.md similarity index 100% rename from docs/guides/redis/backup/customization/index.md rename to docs/guides/redis/backup/stash/customization/index.md diff --git a/docs/guides/redis/backup/overview/images/redis-logical-backup.svg b/docs/guides/redis/backup/stash/overview/images/redis-logical-backup.svg similarity index 100% rename from docs/guides/redis/backup/overview/images/redis-logical-backup.svg rename to docs/guides/redis/backup/stash/overview/images/redis-logical-backup.svg diff --git a/docs/guides/redis/backup/overview/images/redis-logical-restore.svg b/docs/guides/redis/backup/stash/overview/images/redis-logical-restore.svg similarity index 100% rename from docs/guides/redis/backup/overview/images/redis-logical-restore.svg rename to docs/guides/redis/backup/stash/overview/images/redis-logical-restore.svg diff --git a/docs/guides/redis/backup/overview/index.md b/docs/guides/redis/backup/stash/overview/index.md similarity index 96% rename from docs/guides/redis/backup/overview/index.md rename to docs/guides/redis/backup/stash/overview/index.md index 1ef9f56771..2ee01a4a96 100644 --- a/docs/guides/redis/backup/overview/index.md +++ b/docs/guides/redis/backup/stash/overview/index.md @@ -36,7 +36,7 @@ Stash supports taking logical backup of Redis databases using [redis-dump-go](ht The following diagram shows how Stash takes logical backup of a Redis database. Open the image in a new tab to see the enlarged version.
-  Redis Backup Overview +  Redis Backup Overview
Fig: Redis Logical Backup Overview
@@ -71,7 +71,7 @@ The backup process consists of the following steps: The following diagram shows how Stash restores a Redis database from a logical backup. Open the image in a new tab to see the enlarged version.
-  Database Restore Overview +  Database Restore Overview
Fig: Redis Logical Restore Process Overview
@@ -93,4 +93,4 @@ The restore process consists of the following steps: ## Next Steps -- Backup your Redis database using Stash following the guide from [here](/docs/guides/redis/backup/standalone/index.md). +- Backup your Redis database using Stash following the guide from [here](/docs/guides/redis/backup/stash/standalone/index.md). diff --git a/docs/guides/redis/backup/standalone/examples/backupconfiguration.yaml b/docs/guides/redis/backup/stash/standalone/examples/backupconfiguration.yaml similarity index 100% rename from docs/guides/redis/backup/standalone/examples/backupconfiguration.yaml rename to docs/guides/redis/backup/stash/standalone/examples/backupconfiguration.yaml diff --git a/docs/guides/redis/backup/standalone/examples/redis.yaml b/docs/guides/redis/backup/stash/standalone/examples/redis.yaml similarity index 100% rename from docs/guides/redis/backup/standalone/examples/redis.yaml rename to docs/guides/redis/backup/stash/standalone/examples/redis.yaml diff --git a/docs/guides/redis/backup/standalone/examples/repository.yaml b/docs/guides/redis/backup/stash/standalone/examples/repository.yaml similarity index 100% rename from docs/guides/redis/backup/standalone/examples/repository.yaml rename to docs/guides/redis/backup/stash/standalone/examples/repository.yaml diff --git a/docs/guides/redis/backup/standalone/examples/restoresession.yaml b/docs/guides/redis/backup/stash/standalone/examples/restoresession.yaml similarity index 100% rename from docs/guides/redis/backup/standalone/examples/restoresession.yaml rename to docs/guides/redis/backup/stash/standalone/examples/restoresession.yaml diff --git a/docs/guides/redis/backup/standalone/images/sample-redis-backup.png b/docs/guides/redis/backup/stash/standalone/images/sample-redis-backup.png similarity index 100% rename from docs/guides/redis/backup/standalone/images/sample-redis-backup.png rename to docs/guides/redis/backup/stash/standalone/images/sample-redis-backup.png diff --git a/docs/guides/redis/backup/standalone/index.md b/docs/guides/redis/backup/stash/standalone/index.md similarity index 99% rename from docs/guides/redis/backup/standalone/index.md rename to docs/guides/redis/backup/stash/standalone/index.md index a65d4cbc2e..8d126b344f 100644 --- a/docs/guides/redis/backup/standalone/index.md +++ b/docs/guides/redis/backup/stash/standalone/index.md @@ -21,7 +21,7 @@ Stash 0.9.0+ supports backup and restoration of Redis databases. This guide will - Install KubeDB in your cluster following the steps [here](/docs/setup/README.md). - Install Stash in your cluster following the steps [here](https://stash.run/docs/latest/setup/install/stash/). - Install Stash `kubectl` plugin following the steps [here](https://stash.run/docs/latest/setup/install/kubectl-plugin/). -- If you are not familiar with how Stash backup and restore Redis databases, please check the following guide [here](/docs/guides/redis/backup/overview/index.md): +- If you are not familiar with how Stash backup and restore Redis databases, please check the following guide [here](/docs/guides/redis/backup/stash/overview/index.md): You have to be familiar with following custom resources: @@ -369,7 +369,7 @@ gcs-repo true 1.327 MiB 1 60s 8m Now, if we navigate to the GCS bucket, we will see the backed up data has been stored in `demo/redis/sample-redis` directory as specified by `.spec.backend.gcs.prefix` field of the `Repository` object.
- Backup data in GCS Bucket + Backup data in GCS Bucket
Fig: Backup data in GCS Bucket
diff --git a/docs/guides/redis/initialization/using-script.md b/docs/guides/redis/initialization/using-script.md index 257d22d917..113829bc56 100644 --- a/docs/guides/redis/initialization/using-script.md +++ b/docs/guides/redis/initialization/using-script.md @@ -428,7 +428,7 @@ kubectl delete ns demo ## Next Steps -- [Backup and Restore](/docs/guides/redis/backup/overview/index.md) Redis databases using Stash. +- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. - Initialize [Redis with Script](/docs/guides/redis/initialization/using-script.md). - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). diff --git a/docs/guides/redis/reconfigure-tls/sentinel.md b/docs/guides/redis/reconfigure-tls/sentinel.md index 0c3b90fb4b..d4e31ccb9b 100644 --- a/docs/guides/redis/reconfigure-tls/sentinel.md +++ b/docs/guides/redis/reconfigure-tls/sentinel.md @@ -517,6 +517,6 @@ redissentinelopsrequest.ops.kubedb.com "sen-ops-rotate" deleted ## Next Steps - Detail concepts of [Redis object](/docs/guides/redis/concepts/redis.md). -- [Backup and Restore](/docs/guides/redis/backup/overview/index.md) Redis databases using Stash. . +- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. . - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). diff --git a/docs/guides/redis/reconfigure-tls/standalone.md b/docs/guides/redis/reconfigure-tls/standalone.md index 8effca21f4..927efa8519 100644 --- a/docs/guides/redis/reconfigure-tls/standalone.md +++ b/docs/guides/redis/reconfigure-tls/standalone.md @@ -483,6 +483,6 @@ redisopsrequest.ops.kubedb.com "rd-change-issuer" deleted ## Next Steps - Detail concepts of [Redis object](/docs/guides/redis/concepts/redis.md). -- [Backup and Restore](/docs/guides/redis/backup/overview/index.md) Redis databases using Stash. . +- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. . - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). diff --git a/docs/guides/redis/tls/cluster.md b/docs/guides/redis/tls/cluster.md index 5e7eb1899a..e0475ec7ef 100644 --- a/docs/guides/redis/tls/cluster.md +++ b/docs/guides/redis/tls/cluster.md @@ -197,7 +197,7 @@ issuer.cert-manager.io "redis-ca-issuer" deleted ## Next Steps - Detail concepts of [Redis object](/docs/guides/redis/concepts/redis.md). -- [Backup and Restore](/docs/guides/redis/backup/overview/index.md) Redis databases using Stash. . +- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. . - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). diff --git a/docs/guides/redis/tls/sentinel.md b/docs/guides/redis/tls/sentinel.md index fa0727ed25..30df02eaa0 100644 --- a/docs/guides/redis/tls/sentinel.md +++ b/docs/guides/redis/tls/sentinel.md @@ -281,6 +281,6 @@ clusterissuer.cert-manager.io "redis-ca-issuer" deleted ## Next Steps - Detail concepts of [Redis object](/docs/guides/redis/concepts/redis.md). -- [Backup and Restore](/docs/guides/redis/backup/overview/index.md) Redis databases using Stash. . +- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. . - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). diff --git a/docs/guides/redis/tls/standalone.md b/docs/guides/redis/tls/standalone.md index 14e1f1bd77..378f412617 100644 --- a/docs/guides/redis/tls/standalone.md +++ b/docs/guides/redis/tls/standalone.md @@ -193,6 +193,6 @@ issuer.cert-manager.io "redis-ca-issuer" deleted ## Next Steps - Detail concepts of [Redis object](/docs/guides/redis/concepts/redis.md). -- [Backup and Restore](/docs/guides/redis/backup/overview/index.md) Redis databases using Stash. . +- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. . - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). From 6c6316b727e9048c3efa4a5f06bd9541c9e4ccf5 Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Mon, 16 Sep 2024 15:59:04 +0600 Subject: [PATCH 02/11] Add redis kubestash doc intitial Signed-off-by: Neaj Morshad --- docs/guides/redis/backup/kubestash/_index.md | 10 + .../examples/backupconfiguration.yaml | 37 + .../examples/backupstorage.yaml | 17 + .../examples/restoresession.yaml | 21 + .../examples/retentionpolicy.yaml | 15 + .../examples/sample-postgres.yaml | 18 + .../kubestash/application-level/index.md | 776 ++++++++++++++++ .../auto-backup/examples/backupstorage.yaml | 17 + .../examples/customize-backupblueprint.yaml | 42 + .../examples/default-backupblueprint.yaml | 39 + .../auto-backup/examples/retentionpolicy.yaml | 15 + .../examples/sample-postgres-2.yaml | 26 + .../auto-backup/examples/sample-postgres.yaml | 21 + .../backup/kubestash/auto-backup/index.md | 857 ++++++++++++++++++ .../backup/multiple-repository.yaml | 42 + .../customization/backup/passing-args.yaml | 38 + .../backup/passing-database.yaml | 39 + .../customization/backup/resources-limit.yaml | 45 + .../customization/backup/specific-user.yaml | 41 + .../customization/common/backupstorage.yaml | 17 + .../customization/common/retentionpolicy.yaml | 15 + .../customization/common/sample-postgres.yaml | 18 + .../backup/kubestash/customization/index.md | 414 +++++++++ .../restore/resources-limit.yaml | 30 + .../restore/specific-snapshot.yaml | 21 + .../customization/restore/specific-user.yaml | 26 + .../logical/examples/backupconfiguration.yaml | 36 + .../logical/examples/backupstorage.yaml | 17 + .../logical/examples/restored-postgres.yaml | 20 + .../logical/examples/restoresession.yaml | 21 + .../logical/examples/retentionpolicy.yaml | 15 + .../logical/examples/sample-postgres.yaml | 18 + .../redis/backup/kubestash/logical/index.md | 780 ++++++++++++++++ .../overview/images/backup_overview.svg | 1 + .../overview/images/kubedb_plus_kubestash.svg | 21 + .../overview/images/restore_overview.svg | 1 + .../redis/backup/kubestash/overview/index.md | 98 ++ 37 files changed, 3685 insertions(+) create mode 100644 docs/guides/redis/backup/kubestash/_index.md create mode 100644 docs/guides/redis/backup/kubestash/application-level/examples/backupconfiguration.yaml create mode 100644 docs/guides/redis/backup/kubestash/application-level/examples/backupstorage.yaml create mode 100644 docs/guides/redis/backup/kubestash/application-level/examples/restoresession.yaml create mode 100644 docs/guides/redis/backup/kubestash/application-level/examples/retentionpolicy.yaml create mode 100644 docs/guides/redis/backup/kubestash/application-level/examples/sample-postgres.yaml create mode 100644 docs/guides/redis/backup/kubestash/application-level/index.md create mode 100644 docs/guides/redis/backup/kubestash/auto-backup/examples/backupstorage.yaml create mode 100644 docs/guides/redis/backup/kubestash/auto-backup/examples/customize-backupblueprint.yaml create mode 100644 docs/guides/redis/backup/kubestash/auto-backup/examples/default-backupblueprint.yaml create mode 100644 docs/guides/redis/backup/kubestash/auto-backup/examples/retentionpolicy.yaml create mode 100644 docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres-2.yaml create mode 100644 docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres.yaml create mode 100644 docs/guides/redis/backup/kubestash/auto-backup/index.md create mode 100644 docs/guides/redis/backup/kubestash/customization/backup/multiple-repository.yaml create mode 100644 docs/guides/redis/backup/kubestash/customization/backup/passing-args.yaml create mode 100644 docs/guides/redis/backup/kubestash/customization/backup/passing-database.yaml create mode 100644 docs/guides/redis/backup/kubestash/customization/backup/resources-limit.yaml create mode 100644 docs/guides/redis/backup/kubestash/customization/backup/specific-user.yaml create mode 100644 docs/guides/redis/backup/kubestash/customization/common/backupstorage.yaml create mode 100644 docs/guides/redis/backup/kubestash/customization/common/retentionpolicy.yaml create mode 100644 docs/guides/redis/backup/kubestash/customization/common/sample-postgres.yaml create mode 100644 docs/guides/redis/backup/kubestash/customization/index.md create mode 100644 docs/guides/redis/backup/kubestash/customization/restore/resources-limit.yaml create mode 100644 docs/guides/redis/backup/kubestash/customization/restore/specific-snapshot.yaml create mode 100644 docs/guides/redis/backup/kubestash/customization/restore/specific-user.yaml create mode 100644 docs/guides/redis/backup/kubestash/logical/examples/backupconfiguration.yaml create mode 100644 docs/guides/redis/backup/kubestash/logical/examples/backupstorage.yaml create mode 100644 docs/guides/redis/backup/kubestash/logical/examples/restored-postgres.yaml create mode 100644 docs/guides/redis/backup/kubestash/logical/examples/restoresession.yaml create mode 100644 docs/guides/redis/backup/kubestash/logical/examples/retentionpolicy.yaml create mode 100644 docs/guides/redis/backup/kubestash/logical/examples/sample-postgres.yaml create mode 100644 docs/guides/redis/backup/kubestash/logical/index.md create mode 100644 docs/guides/redis/backup/kubestash/overview/images/backup_overview.svg create mode 100644 docs/guides/redis/backup/kubestash/overview/images/kubedb_plus_kubestash.svg create mode 100644 docs/guides/redis/backup/kubestash/overview/images/restore_overview.svg create mode 100644 docs/guides/redis/backup/kubestash/overview/index.md diff --git a/docs/guides/redis/backup/kubestash/_index.md b/docs/guides/redis/backup/kubestash/_index.md new file mode 100644 index 0000000000..51888b1792 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/_index.md @@ -0,0 +1,10 @@ +--- +title: Backup & Restore Redis | KubeStash +menu: + docs_{{ .version }}: + identifier: guides-rd-backup-stashv2 + name: KubeStash (aka Stash 2.0) + parent: guides-rd-backup + weight: 50 +menu_name: docs_{{ .version }} +--- \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/application-level/examples/backupconfiguration.yaml b/docs/guides/redis/backup/kubestash/application-level/examples/backupconfiguration.yaml new file mode 100644 index 0000000000..b8a30a7852 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/application-level/examples/backupconfiguration.yaml @@ -0,0 +1,37 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: manifest-backup + - name: logical-backup \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/application-level/examples/backupstorage.yaml b/docs/guides/redis/backup/kubestash/application-level/examples/backupstorage.yaml new file mode 100644 index 0000000000..0461b26762 --- /dev/null +++ b/docs/guides/redis/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: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/application-level/examples/restoresession.yaml b/docs/guides/redis/backup/kubestash/application-level/examples/restoresession.yaml new file mode 100644 index 0000000000..0c02e2989c --- /dev/null +++ b/docs/guides/redis/backup/kubestash/application-level/examples/restoresession.yaml @@ -0,0 +1,21 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: RestoreSession +metadata: + name: restore-sample-redis + namespace: demo +spec: + manifestOptions: + restoreNamespace: dev + redis: + db: true + dataSource: + repository: gcs-redis-repo + snapshot: latest + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup-restore + - name: manifest-restore \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/application-level/examples/retentionpolicy.yaml b/docs/guides/redis/backup/kubestash/application-level/examples/retentionpolicy.yaml new file mode 100644 index 0000000000..4591562860 --- /dev/null +++ b/docs/guides/redis/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 \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/application-level/examples/sample-postgres.yaml b/docs/guides/redis/backup/kubestash/application-level/examples/sample-postgres.yaml new file mode 100644 index 0000000000..ce97b5a41c --- /dev/null +++ b/docs/guides/redis/backup/kubestash/application-level/examples/sample-postgres.yaml @@ -0,0 +1,18 @@ +apiVersion: kubedb.com/v1 +kind: Redis +metadata: + name: sample-redis + namespace: demo +spec: + version: "16.1" + replicas: 3 + standbyMode: Hot + streamingMode: Synchronous + storageType: Durable + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/application-level/index.md b/docs/guides/redis/backup/kubestash/application-level/index.md new file mode 100644 index 0000000000..0ec66e51d3 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/application-level/index.md @@ -0,0 +1,776 @@ +--- +title: Application Level Backup & Restore Redis | KubeStash +description: Application Level Backup and Restore using KubeStash +menu: + docs_{{ .version }}: + identifier: guides-application-level-backup-stashv2 + name: Application Level Backup + parent: guides-rd-backup-stashv2 + weight: 40 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +# Application Level Backup and Restore Redis database using KubeStash + +KubeStash offers application-level backup and restore functionality for `Redis` databases. It captures both manifest and data backups of any `Redis` database in a single snapshot. During the restore process, KubeStash first applies the `Redis` manifest to the cluster and then restores the data into it. + +This guide will give you an overview how you can take application-level backup and restore your `Redis` databases using `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` or `Kind`. +- Install `KubeDB` in your cluster following the steps [here](/docs/setup/README.md). +- Install `KubeStash` in your cluster following the steps [here](https://kubestash.com/docs/latest/setup/install/kubestash). +- Install KubeStash `kubectl` plugin following the steps [here](https://kubestash.com/docs/latest/setup/install/kubectl-plugin/). +- If you are not familiar with how KubeStash backup and restore Redis databases, please check the following guide [here](/docs/guides/redis/backup/kubestash/overview/index.md). + +You should be familiar with the following `KubeStash` concepts: + +- [BackupStorage](https://kubestash.com/docs/latest/concepts/crds/backupstorage/) +- [BackupConfiguration](https://kubestash.com/docs/latest/concepts/crds/backupconfiguration/) +- [BackupSession](https://kubestash.com/docs/latest/concepts/crds/backupsession/) +- [RestoreSession](https://kubestash.com/docs/latest/concepts/crds/restoresession/) +- [Addon](https://kubestash.com/docs/latest/concepts/crds/addon/) +- [Function](https://kubestash.com/docs/latest/concepts/crds/function/) +- [Task](https://kubestash.com/docs/latest/concepts/crds/addon/#task-specification) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/guides/redis/backup/kubestash/application-level/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/application-level/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. + +## Backup Redis + +KubeStash supports backups for `Redis` instances across different configurations, including Standalone and HA Cluster setups. In this demonstration, we'll focus on a `Redis` database using HA cluster configuration. The backup and restore process is similar for Standalone configuration. + +This section will demonstrate how to take application-level backup of a `Redis` database. Here, we are going to deploy a `Redis` database using KubeDB. Then, we are going to back up the database at the application level to a `GCS` bucket. Finally, we will restore the entire `Redis` database. + +### Deploy Sample Redis Database + +Let's deploy a sample `Redis` database and insert some data into it. + +**Create Redis CR:** + +Below is the YAML of a sample `Redis` CR that we are going to create for this tutorial: + +```yaml +apiVersion: kubedb.com/v1 +kind: Redis +metadata: + name: sample-redis + namespace: demo +spec: + version: "16.1" + replicas: 3 + standbyMode: Hot + streamingMode: Synchronous + storageType: Durable + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Create the above `Redis` CR, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/application-level/examples/sample-redis.yaml +redis.kubedb.com/sample-redis created +``` + +KubeDB will deploy a `Redis` 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, + +```bash +$ kubectl get rd -n demo sample-redis +NAME VERSION STATUS AGE +sample-redis 16.1 Ready 5m1s +``` + +The database is `Ready`. Verify that KubeDB has created a `Secret` and a `Service` for this database using the following commands, + +```bash +$ kubectl get secret -n demo +NAME TYPE DATA AGE +sample-redis-auth kubernetes.io/basic-auth 2 5m20s + +$ kubectl get service -n demo -l=app.kubernetes.io/instance=sample-redis +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +sample-redis ClusterIP 10.96.23.177 5432/TCP,2379/TCP 5m55s +sample-redis-pods ClusterIP None 5432/TCP,2380/TCP,2379/TCP 5m55s +sample-redis-standby ClusterIP 10.96.26.118 5432/TCP 5m55s +``` + +Here, we have to use service `sample-redis` and secret `sample-redis-auth` to connect with the database. `KubeDB` creates an [AppBinding](/docs/guides/redis/concepts/appbinding.md) CR that holds the necessary information to connect with the database. + + +**Verify AppBinding:** + +Verify that the `AppBinding` has been created successfully using the following command, + +```bash +$ kubectl get appbindings -n demo +NAME TYPE VERSION AGE +sample-redis kubedb.com/redis 16.1 9m30s +``` + +Let's check the YAML of the above `AppBinding`, + +```bash +$ kubectl get appbindings -n demo sample-redis -o yaml +``` + +```yaml +apiVersion: appcatalog.appscode.com/v1alpha1 +kind: AppBinding +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"kubedb.com/v1","kind":"Redis","metadata":{"annotations":{},"name":"sample-redis","namespace":"demo"},"spec":{"deletionPolicy":"DoNotTerminate","replicas":3,"standbyMode":"Hot","storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}}},"storageType":"Durable","streamingMode":"Synchronous","version":"16.1"}} + creationTimestamp: "2024-09-04T10:07:04Z" + generation: 1 + labels: + app.kubernetes.io/component: database + app.kubernetes.io/instance: sample-redis + app.kubernetes.io/managed-by: kubedb.com + app.kubernetes.io/name: redises.kubedb.com + name: sample-redis + namespace: demo + ownerReferences: + - apiVersion: kubedb.com/v1 + blockOwnerDeletion: true + controller: true + kind: Redis + name: sample-redis + uid: 0810a96c-a2b6-4e8a-a70a-51753660450c + resourceVersion: "245972" + uid: 73bdba85-c932-464b-93a8-7f1ba8dfff1b +spec: + appRef: + apiGroup: kubedb.com + kind: Redis + name: sample-redis + namespace: demo + clientConfig: + service: + name: sample-redis + path: / + port: 5432 + query: sslmode=disable + scheme: redisql + parameters: + apiVersion: appcatalog.appscode.com/v1alpha1 + kind: StashAddon + stash: + addon: + backupTask: + name: redis-backup-16.1 + restoreTask: + name: redis-restore-16.1 + secret: + name: sample-redis-auth + type: kubedb.com/redis + version: "16.1" +``` + +KubeStash uses the `AppBinding` CR to connect with the target database. It requires the following two fields to set in AppBinding's `.spec` section. + +Here, + +- `.spec.clientConfig.service.name` specifies the name of the Service that connects to the database. +- `.spec.secret` specifies the name of the Secret that holds necessary credentials to access the database. +- `.spec.type` specifies the types of the app that this AppBinding is pointing to. KubeDB generated AppBinding follows the following format: `/`. + +**Insert Sample Data:** + +Now, we are going to exec into one of the database pod and create some sample data. At first, find out the database `Pod` using the following command, + +```bash +$ kubectl get pods -n demo --selector="app.kubernetes.io/instance=sample-redis" +NAME READY STATUS RESTARTS AGE +sample-redis-0 2/2 Running 0 16m +sample-redis-1 2/2 Running 0 13m +sample-redis-2 2/2 Running 0 13m +``` + +Now, let’s exec into the pod and create a table, + +```bash +$ kubectl exec -it -n demo sample-redis-0 -- sh + +# login as "redis" superuser. +/ $ psql -U redis +psql (16.1) +Type "help" for help. + +# list available databases +redis=# \l + List of databases + Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges +---------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- + kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis + template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis +(4 rows) + +# create a database named "demo" +redis=# create database demo; +CREATE DATABASE + +# verify that the "demo" database has been created +redis=# \l + List of databases + Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges +---------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- + demo | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis + template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis +(5 rows) + +# connect to the "demo" database +redis=# \c demo +You are now connected to database "demo" as user "redis". + +# create a sample table +demo=# CREATE TABLE COMPANY( NAME TEXT NOT NULL, EMPLOYEE INT NOT NULL); +CREATE TABLE + +# verify that the table has been created +demo=# \d + List of relations + Schema | Name | Type | Owner +--------+---------+-------+---------- + public | company | table | redis +(1 row) + +# insert multiple rows of data into the table +demo=# INSERT INTO COMPANY (NAME, EMPLOYEE) VALUES ('TechCorp', 100), ('InnovateInc', 150), ('AlphaTech', 200); +INSERT 0 3 + +# verify the data insertion +demo=# SELECT * FROM COMPANY; + name | employee +-------------+---------- + TechCorp | 100 + InnovateInc | 150 + AlphaTech | 200 +(3 rows) + +# quit from the database +demo=# \q + +# exit from the pod +/ $ exit +``` + +Now, we are ready to backup the database. + +### 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/). + +**Create Secret:** + +Let's create a secret called `gcs-secret` with access credentials to our desired GCS bucket, + +```bash +$ echo -n '' > GOOGLE_PROJECT_ID +$ cat /path/to/downloaded-sa-key.json > GOOGLE_SERVICE_ACCOUNT_JSON_KEY +$ kubectl create secret generic -n demo gcs-secret \ + --from-file=./GOOGLE_PROJECT_ID \ + --from-file=./GOOGLE_SERVICE_ACCOUNT_JSON_KEY +secret/gcs-secret created +``` + +**Create BackupStorage:** + +Now, create a `BackupStorage` using this secret. Below is the YAML of `BackupStorage` CR we are going to create, + +```yaml +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: WipeOut +``` + +Let's create the BackupStorage we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples/backupstorage.yaml +backupstorage.storage.kubestash.com/gcs-storage created +``` + +Now, we are ready to backup our database to our desired backend. + +**Create RetentionPolicy:** + +Now, let's create a `RetentionPolicy` to specify how the old Snapshots should be cleaned up. + +Below is the YAML of the `RetentionPolicy` object that we are going to create, + +```yaml +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 +``` + +Let’s create the above `RetentionPolicy`, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples/retentionpolicy.yaml +retentionpolicy.storage.kubestash.com/demo-retention created +``` + +### Backup + +We have to create a `BackupConfiguration` targeting respective `sample-redis` Redis database. Then, KubeStash will create a `CronJob` for each session to take periodic backup of that database. + +At first, we need to create a secret with a Restic password for backup data encryption. + +**Create Secret:** + +Let's create a secret called `encrypt-secret` with the Restic password, + +```bash +$ echo -n 'changeit' > RESTIC_PASSWORD +$ kubectl create secret generic -n demo encrypt-secret \ + --from-file=./RESTIC_PASSWORD \ +secret "encrypt-secret" created +``` + +**Create BackupConfiguration:** + +Below is the YAML for `BackupConfiguration` CR to take application-level backup of the `sample-redis` database that we have deployed earlier, + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: manifest-backup + - name: logical-backup +``` + +- `.spec.sessions[*].schedule` specifies that we want to backup at `5 minutes` interval. +- `.spec.target` refers to the targeted `sample-redis` Redis database that we created earlier. +- `.spec.sessions[*].addon.tasks[*].name[*]` specifies that both the `manifest-backup` and `logical-backup` will be taken together. + + +Let's create the `BackupConfiguration` CR that we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/kubestash/application-level/examples/backupconfiguration.yaml +backupconfiguration.core.kubestash.com/sample-redis-backup 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, + +```bash +$ kubectl get backupconfiguration -n demo +NAME PHASE PAUSED AGE +sample-redis-backup Ready 2m50s +``` + +Additionally, we can verify that the `Repository` specified in the `BackupConfiguration` has been created using the following command, + +```bash +$ kubectl get repo -n demo +NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE +gcs-redis-repo 0 0 B Ready 3m +``` + +KubeStash keeps the backup for `Repository` YAMLs. If we navigate to the GCS bucket, we will see the `Repository` YAML stored in the `demo/redis` directory. + +**Verify CronJob:** + +It will also create a `CronJob` with the schedule specified in `spec.sessions[*].scheduler.schedule` field of `BackupConfiguration` CR. + +Verify that the `CronJob` has been created using the following command, + +```bash +$ kubectl get cronjob -n demo +NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE +trigger-sample-redis-backup-frequent-backup */5 * * * * 0 2m45s 3m25s +``` + +**Verify BackupSession:** + +KubeStash triggers an instant backup as soon as the `BackupConfiguration` is ready. After that, backups are scheduled according to the specified schedule. + +```bash +$ kubectl get backupsession -n demo -w +NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE +sample-redis-backup-frequent-backup-1725449400 BackupConfiguration sample-redis-backup Succeeded 7m22s +``` + +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 `sample-redis-backup` has been updated by the following command, + +```bash +$ kubectl get repository -n demo sample-redis-backup +NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE +sample-redis-backup true 1 806 B Ready 8m27s 9m18s +``` + +At this moment we have one `Snapshot`. Run the following command to check the respective `Snapshot` which represents the state of a backup run for an application. + +```bash +$ kubectl get snapshots -n demo -l=kubestash.com/repo-name=gcs-redis-repo +NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE AGE +gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 gcs-redis-repo frequent-backup 2024-01-23T13:10:54Z Delete Succeeded 16h +``` + +> Note: KubeStash creates a `Snapshot` with the following labels: +> - `kubestash.com/app-ref-kind: ` +> - `kubestash.com/app-ref-name: ` +> - `kubestash.com/app-ref-namespace: ` +> - `kubestash.com/repo-name: ` +> +> These labels can be used to watch only the `Snapshot`s related to our target Database or `Repository`. + +If we check the YAML of the `Snapshot`, we can find the information about the backed up components of the Database. + +```bash +$ kubectl get snapshots -n demo gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 -oyaml +``` + +```yaml +apiVersion: storage.kubestash.com/v1alpha1 +kind: Snapshot +metadata: + creationTimestamp: "2024-09-05T09:08:03Z" + finalizers: + - kubestash.com/cleanup + generation: 1 + labels: + kubestash.com/app-ref-kind: Redis + kubestash.com/app-ref-name: sample-redis + kubestash.com/app-ref-namespace: demo + kubestash.com/repo-name: gcs-redis-repo + annotations: + kubedb.com/db-version: "16.1" + name: gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 + namespace: demo + ownerReferences: + - apiVersion: storage.kubestash.com/v1alpha1 + blockOwnerDeletion: true + controller: true + kind: Repository + name: gcs-redis-repo + uid: fa9086e5-285a-4b4a-9096-072bf7dbe2f7 + resourceVersion: "289843" + uid: 43f17a3f-4ac7-443c-a139-151f2e5bf462 +spec: + appRef: + apiGroup: kubedb.com + kind: Redis + name: sample-redis + namespace: demo + backupSession: sample-redis-backup-frequent-backup-1725527283 + deletionPolicy: Delete + repository: gcs-redis-repo + session: frequent-backup + snapshotID: 01J70Q1NT6FW11YBBARRFJ6SYB + type: FullBackup + version: v1 +status: + components: + dump: + driver: Restic + duration: 6.684476865s + integrity: true + path: repository/v1/frequent-backup/dump + phase: Succeeded + resticStats: + - hostPath: dumpfile.sql + id: 4b820700710f9f7b6a8d5b052367b51875e68dcd9052c749a686506db6a66374 + size: 3.345 KiB + uploaded: 3.634 KiB + size: 1.135 KiB + manifest: + driver: Restic + duration: 7.477728298s + integrity: true + path: repository/v1/frequent-backup/manifest + phase: Succeeded + resticStats: + - hostPath: /kubestash-tmp/manifest + id: 9da4d1b7df6dd946e15a8a0d2a2a3c14776351e27926156770530ca03f6f8002 + size: 3.064 KiB + uploaded: 1.443 KiB + size: 2.972 KiB + conditions: + - lastTransitionTime: "2024-09-05T09:08:03Z" + message: Recent snapshot list updated successfully + reason: SuccessfullyUpdatedRecentSnapshotList + status: "True" + type: RecentSnapshotListUpdated + - lastTransitionTime: "2024-09-05T09:08:49Z" + message: Metadata uploaded to backend successfully + reason: SuccessfullyUploadedSnapshotMetadata + status: "True" + type: SnapshotMetadataUploaded + integrity: true + phase: Succeeded + size: 4.106 KiB + snapshotTime: "2024-09-05T09:08:03Z" + totalComponents: 2 +``` + +> KubeStash uses a logical backup approach to take backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. Do the same for auto-backup, application backup and customize backup if necessary. + +> KubeStash set component name as `manifest` for the `manifest backup` of Redis databases. + +Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/popstgres/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/redis/snapshots` directory. + +> 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 entire database from the backup that we have taken in the previous section. + +For this tutorial, we will restore the database in a separate namespace called `dev`. + +First, create the namespace by running the following command: + +```bash +$ kubectl create ns dev +namespace/dev created +``` + +#### Create RestoreSession: + +We need to create a RestoreSession CR. + +Below, is the contents of YAML file of the `RestoreSession` CR that we are going to create to restore the entire database. + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: RestoreSession +metadata: + name: restore-sample-redis + namespace: demo +spec: + manifestOptions: + restoreNamespace: dev + redis: + db: true + dataSource: + repository: gcs-redis-repo + snapshot: latest + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup-restore + - name: manifest-restore +``` + +Here, + +- `.spec.manifestOptions.redis.db` specifies whether to restore the DB manifest or not. +- `.spec.dataSource.repository` specifies the Repository object that holds the backed up data. +- `.spec.dataSource.snapshot` specifies to restore from latest `Snapshot`. +- `.spec.addon.tasks[*]` specifies that both the `manifest-restore` and `logical-backup-restore` tasks. + +Let's create the RestoreSession CR object we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/application-level/examples/restoresession.yaml +restoresession.core.kubestash.com/restore-sample-redis created +``` + +Once, you have created the `RestoreSession` object, KubeStash will create restore Job. Run the following command to watch the phase of the `RestoreSession` object, + +```bash +$ watch kubectl get restoresession -n demo +Every 2.0s: kubectl get restores... AppsCode-PC-03: Wed Aug 21 10:44:05 2024 +NAME REPOSITORY FAILURE-POLICY PHASE DURATION AGE +restore-sample-redis gcs-redis-repo Succeeded 3s 53s +``` + +The `Succeeded` phase means that the restore process has been completed successfully. + + +#### Verify Restored Redis Manifest: + +In this section, we will verify whether the desired `Redis` database manifest has been successfully applied to the cluster. + +```bash +$ kubectl get redis -n dev +NAME VERSION STATUS AGE +sample-redis 16.1 Ready 9m46s +``` + +The output confirms that the `Redis` 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. + +At first, check if the database has gone into **`Ready`** state by the following command, + +```bash +$ kubectl get redis -n dev sample-redis +NAME VERSION STATUS AGE +sample-redis 16.1 Ready 9m46s +``` + +Now, find out the database `Pod` by the following command, + +```bash +$ kubectl get pods -n dev --selector="app.kubernetes.io/instance=sample-redis" +NAME READY STATUS RESTARTS AGE +sample-redis-0 2/2 Running 0 12m +sample-redis-1 2/2 Running 0 12m +sample-redis-2 2/2 Running 0 12m +``` + + +Now, lets exec one of the Pod and verify restored data. + +```bash +$ kubectl exec -it -n dev sample-redis-0 -- /bin/sh +# login as "redis" superuser. +/ # psql -U redis +psql (11.11) +Type "help" for help. + +# verify that the "demo" database has been restored +redis=# \l + List of databases + Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges +---------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- + demo | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis + template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis +(5 rows) + +# connect to the "demo" database +redis=# \c demo +You are now connected to database "demo" as user "redis". + +# verify that the sample table has been restored +demo=# \d + List of relations + Schema | Name | Type | Owner +--------+---------+-------+---------- + public | company | table | redis +(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 + +# exit from the pod +/ # exit +``` + +So, from the above output, we can see the `demo` database we had created in the original database `sample-redis` has been restored successfully. + +## Cleanup + +To cleanup the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete backupconfigurations.core.kubestash.com -n demo sample-redis-backup +kubectl delete retentionpolicies.storage.kubestash.com -n demo demo-retention +kubectl delete restoresessions.core.kubestash.com -n demo restore-sample-redis +kubectl delete backupstorage -n demo gcs-storage +kubectl delete secret -n demo gcs-secret +kubectl delete secret -n demo encrypt-secret +kubectl delete redis -n demo sample-redis +kubectl delete redis -n dev sample-redis +``` diff --git a/docs/guides/redis/backup/kubestash/auto-backup/examples/backupstorage.yaml b/docs/guides/redis/backup/kubestash/auto-backup/examples/backupstorage.yaml new file mode 100644 index 0000000000..0461b26762 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/auto-backup/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: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/auto-backup/examples/customize-backupblueprint.yaml b/docs/guides/redis/backup/kubestash/auto-backup/examples/customize-backupblueprint.yaml new file mode 100644 index 0000000000..7a7634b3a5 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/auto-backup/examples/customize-backupblueprint.yaml @@ -0,0 +1,42 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupBlueprint +metadata: + name: redis-customize-backup-blueprint + namespace: demo +spec: + usagePolicy: + allowedNamespaces: + from: All + backupConfigurationTemplate: + deletionPolicy: OnDelete + # ============== Blueprint for Backends of BackupConfiguration ================= + backends: + - name: gcs-backend + storageRef: + namespace: demo + name: gcs-storage + retentionPolicy: + name: demo-retention + namespace: demo + # ============== Blueprint for Sessions of BackupConfiguration ================= + sessions: + - name: frequent-backup + sessionHistoryLimit: 3 + scheduler: + schedule: ${schedule} + jobTemplate: + backoffLimit: 1 + repositories: + - name: ${repoName} + backend: gcs-backend + directory: ${namespace}/${targetName} + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup + params: + backupCmd: rd_dump + args: ${targetedDatabase} \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/auto-backup/examples/default-backupblueprint.yaml b/docs/guides/redis/backup/kubestash/auto-backup/examples/default-backupblueprint.yaml new file mode 100644 index 0000000000..53745170e7 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/auto-backup/examples/default-backupblueprint.yaml @@ -0,0 +1,39 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupBlueprint +metadata: + name: redis-default-backup-blueprint + namespace: demo +spec: + usagePolicy: + allowedNamespaces: + from: All + backupConfigurationTemplate: + deletionPolicy: OnDelete + # ============== Blueprint for Backends of BackupConfiguration ================= + backends: + - name: gcs-backend + storageRef: + namespace: demo + name: gcs-storage + retentionPolicy: + name: demo-retention + namespace: demo + # ============== Blueprint for Sessions of BackupConfiguration ================= + sessions: + - name: frequent-backup + sessionHistoryLimit: 3 + scheduler: + schedule: "*/5 * * * *" + jobTemplate: + backoffLimit: 1 + repositories: + - name: default-blueprint + backend: gcs-backend + directory: /default-blueprint + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/auto-backup/examples/retentionpolicy.yaml b/docs/guides/redis/backup/kubestash/auto-backup/examples/retentionpolicy.yaml new file mode 100644 index 0000000000..4591562860 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/auto-backup/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 \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres-2.yaml b/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres-2.yaml new file mode 100644 index 0000000000..3c357e5386 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres-2.yaml @@ -0,0 +1,26 @@ +apiVersion: kubedb.com/v1 +kind: Redis +metadata: + name: sample-redis-2 + namespace: demo + annotations: + blueprint.kubestash.com/name: redis-customize-backup-blueprint + blueprint.kubestash.com/namespace: demo + variables.kubestash.com/schedule: "*/10 * * * *" + variables.kubestash.com/repoName: customize-blueprint + variables.kubestash.com/namespace: demo + variables.kubestash.com/targetName: sample-redis-2 + variables.kubestash.com/targetedDatabase: redis +spec: + version: "16.1" + replicas: 3 + standbyMode: Hot + streamingMode: Synchronous + storageType: Durable + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres.yaml b/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres.yaml new file mode 100644 index 0000000000..41f1987427 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres.yaml @@ -0,0 +1,21 @@ +apiVersion: kubedb.com/v1 +kind: Redis +metadata: + name: sample-redis + namespace: demo + annotations: + blueprint.kubestash.com/name: redis-default-backup-blueprint + blueprint.kubestash.com/namespace: demo +spec: + version: "16.1" + replicas: 3 + standbyMode: Hot + streamingMode: Synchronous + storageType: Durable + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/auto-backup/index.md b/docs/guides/redis/backup/kubestash/auto-backup/index.md new file mode 100644 index 0000000000..4031fc6dd6 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/auto-backup/index.md @@ -0,0 +1,857 @@ +--- +title: Redis Auto-Backup | KubeStash +description: Backup Redis using KubeStash Auto-Backup +menu: + docs_{{ .version }}: + identifier: guides-rd-auto-backup-stashv2 + name: Auto-Backup + parent: guides-rd-backup-stashv2 + weight: 30 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +# Backup Redis using KubeStash Auto-Backup + +KubeStash can automatically be configured to backup any `Redis` databases in your cluster. KubeStash enables cluster administrators to deploy backup `blueprints` ahead of time so database owners can easily backup any `Redis` database with a few annotations. + +In this tutorial, we are going to show how you can configure a backup blueprint for `Redis` databases in your cluster and backup them with a 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. If you do not already have a cluster, you can create one by using `Minikube` or `Kind`. +- Install `KubeDB` in your cluster following the steps [here](/docs/setup/README.md). +- Install `KubeStash` in your cluster following the steps [here](https://kubestash.com/docs/latest/setup/install/kubestash). +- Install KubeStash `kubectl` plugin following the steps [here](https://kubestash.com/docs/latest/setup/install/kubectl-plugin/). +- If you are not familiar with how KubeStash backup and restore `Redis` databases, please check the following guide [here](/docs/guides/redis/backup/kubestash/overview/index.md). + +You should be familiar with the following `KubeStash` concepts: + +- [BackupStorage](https://kubestash.com/docs/latest/concepts/crds/backupstorage/) +- [BackupConfiguration](https://kubestash.com/docs/latest/concepts/crds/backupconfiguration/) +- [BackupSession](https://kubestash.com/docs/latest/concepts/crds/backupsession/) +- [RestoreSession](https://kubestash.com/docs/latest/concepts/crds/restoresession/) +- [Addon](https://kubestash.com/docs/latest/concepts/crds/addon/) +- [Function](https://kubestash.com/docs/latest/concepts/crds/function/) +- [Task](https://kubestash.com/docs/latest/concepts/crds/addon/#task-specification) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/guides/redis/backup/kubestash/auto-backup/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/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/). + +**Create Secret:** + +Let's create a secret called `gcs-secret` with access credentials to our desired GCS bucket, + +```bash +$ echo -n '' > GOOGLE_PROJECT_ID +$ cat /path/to/downloaded-sa-key.json > GOOGLE_SERVICE_ACCOUNT_JSON_KEY +$ kubectl create secret generic -n demo gcs-secret \ + --from-file=./GOOGLE_PROJECT_ID \ + --from-file=./GOOGLE_SERVICE_ACCOUNT_JSON_KEY +secret/gcs-secret created +``` + +**Create BackupStorage:** + +Now, create a `BackupStorage` using this secret. Below is the YAML of `BackupStorage` CR we are going to create, + +```yaml +apiVersion: storage.kubestash.com/v1alpha1 +kind: BackupStorage +metadata: + name: gcs-storage + namespace: demo +spec: + storage: + provider: gcs + gcs: + bucket: kubestash-qa + prefix: blueprint + secretName: gcs-secret + usagePolicy: + allowedNamespaces: + from: All + default: true + deletionPolicy: WipeOut +``` + +Let's create the BackupStorage we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/auto-backup/examples/backupstorage.yaml +backupstorage.storage.kubestash.com/gcs-storage created +``` + +Now, we are ready to backup our database to our desired backend. + +**Create RetentionPolicy:** + +Now, let's create a `RetentionPolicy` to specify how the old Snapshots should be cleaned up. + +Below is the YAML of the `RetentionPolicy` object that we are going to create, + +```yaml +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 +``` + +Let’s create the above `RetentionPolicy`, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/auto-backup/examples/retentionpolicy.yaml +retentionpolicy.storage.kubestash.com/demo-retention created +``` + +**Create Secret:** + +We also need to create a secret with a `Restic` password for backup data encryption. + +Let's create a secret called `encrypt-secret` with the Restic password, + +```bash +$ echo -n 'changeit' > RESTIC_PASSWORD +$ kubectl create secret generic -n demo encrypt-secret \ + --from-file=./RESTIC_PASSWORD \ +secret "encrypt-secret" created +``` + +## Auto-backup with default configurations + +In this section, we are going to backup a `Redis` database of `demo` namespace. We are going to use the default configurations which will be specified in the `BackupBlueprint` CR. + +**Prepare Backup Blueprint** + +A `BackupBlueprint` allows you to specify a template for the `Repository`,`Session` or `Variables` of `BackupConfiguration` in a Kubernetes native way. + +Now, we have to create a `BackupBlueprint` CR with a blueprint for `BackupConfiguration` object. + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupBlueprint +metadata: + name: redis-default-backup-blueprint + namespace: demo +spec: + usagePolicy: + allowedNamespaces: + from: All + backupConfigurationTemplate: + deletionPolicy: OnDelete + backends: + - name: gcs-backend + storageRef: + namespace: demo + name: gcs-storage + retentionPolicy: + name: demo-retention + namespace: demo + sessions: + - name: frequent-backup + sessionHistoryLimit: 3 + scheduler: + schedule: "*/5 * * * *" + jobTemplate: + backoffLimit: 1 + repositories: + - name: default-blueprint + backend: gcs-backend + directory: /default-blueprint + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup +``` + +Here, + +- `.spec.backupConfigurationTemplate.backends[*].storageRef` refers our earlier created `gcs-storage` backupStorage. +- `.spec.backupConfigurationTemplate.sessions[*].schedule` specifies that we want to backup the database at `5 minutes` interval. + +Let's create the `BackupBlueprint` we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/auto-backup/examples/default-backupblueprint.yaml +backupblueprint.core.kubestash.com/redis-default-backup-blueprint created +``` + +Now, we are ready to backup our `Redis` databases using few annotations. + +**Create Database** + +Now, we are going to create an `Redis` CR in demo namespace. + +Below is the YAML of the `Redis` object that we are going to create, + +```yaml +apiVersion: kubedb.com/v1 +kind: Redis +metadata: + name: sample-redis + namespace: demo + annotations: + blueprint.kubestash.com/name: redis-default-backup-blueprint + blueprint.kubestash.com/namespace: demo +spec: + version: "16.1" + replicas: 3 + standbyMode: Hot + streamingMode: Synchronous + storageType: Durable + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Here, + +- `.spec.annotations.blueprint.kubestash.com/name: redis-default-backup-blueprint` specifies the name of the `BackupBlueprint` that will use in backup. +- `.spec.annotations.blueprint.kubestash.com/namespace: demo` specifies the name of the `namespace` where the `BackupBlueprint` resides. + +Let's create the `Redis` we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-redis.yaml +redis.kubedb.com/sample-redis created +``` + +**Verify BackupConfiguration** + +If everything goes well, KubeStash should create a `BackupConfiguration` for our Redis in demo namespace and the phase of that `BackupConfiguration` should be `Ready`. Verify the `BackupConfiguration` object by the following command, + +```bash +$ kubectl get backupconfiguration -n demo +NAME PHASE PAUSED AGE +appbinding-sample-redis Ready 2m50m +``` + +Now, let’s check the YAML of the `BackupConfiguration`. + +```bash +$ kubectl get backupconfiguration -n demo appbinding-sample-redis -o yaml +``` + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + creationTimestamp: "2024-09-05T10:53:48Z" + finalizers: + - kubestash.com/cleanup + generation: 1 + labels: + app.kubernetes.io/managed-by: kubestash.com + kubestash.com/invoker-name: redis-default-backup-blueprint + kubestash.com/invoker-namespace: demo + name: appbinding-sample-redis + namespace: demo + resourceVersion: "298502" + uid: b6537c60-051f-4348-9ca4-c28f3880dbc1 +spec: + backends: + - name: gcs-backend + retentionPolicy: + name: demo-retention + namespace: demo + storageRef: + name: gcs-storage + namespace: demo + sessions: + - addon: + name: redis-addon + tasks: + - name: logical-backup + name: frequent-backup + repositories: + - backend: gcs-backend + directory: /default-blueprint + encryptionSecret: + name: encrypt-secret + namespace: demo + name: default-blueprint + scheduler: + jobTemplate: + backoffLimit: 1 + template: + controller: {} + metadata: {} + spec: + resources: {} + schedule: '*/5 * * * *' + sessionHistoryLimit: 3 + target: + apiGroup: kubedb.com + kind: Redis + name: sample-redis + namespace: demo +status: + backends: + - name: gcs-backend + ready: true + retentionPolicy: + found: true + ref: + name: demo-retention + namespace: demo + storage: + phase: Ready + ref: + name: gcs-storage + namespace: demo + conditions: + - lastTransitionTime: "2024-09-05T10:53:48Z" + message: Validation has been passed successfully. + reason: ResourceValidationPassed + status: "True" + type: ValidationPassed + dependencies: + - found: true + kind: Addon + name: redis-addon + phase: Ready + repositories: + - name: default-blueprint + phase: Ready + sessions: + - conditions: + - lastTransitionTime: "2024-09-05T10:53:59Z" + message: Scheduler has been ensured successfully. + reason: SchedulerEnsured + status: "True" + type: SchedulerEnsured + - lastTransitionTime: "2024-09-05T10:53:59Z" + message: Initial backup has been triggered successfully. + reason: SuccessfullyTriggeredInitialBackup + status: "True" + type: InitialBackupTriggered + name: frequent-backup + targetFound: true +``` + +Notice the `spec.backends`, `spec.sessions` and `spec.target` sections, KubeStash automatically resolved those info from the `BackupBluePrint` and created above `BackupConfiguration`. + + +**Verify BackupSession:** + +KubeStash triggers an instant backup as soon as the `BackupConfiguration` is ready. After that, backups are scheduled according to the specified schedule. + +```bash +$ kubectl get backupsession -n demo -w +NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE +appbinding-sample-redis-frequent-backup-1725533628 BackupConfiguration appbinding-sample-redis Succeeded 23s 6m40s +``` + +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 `sample-redis-backup` has been updated by the following command, + +```bash +$ kubectl get repository -n demo default-blueprint +NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE +default-blueprint true 3 1.559 KiB Ready 80s 7m32s +``` + +At this moment we have one `Snapshot`. Run the following command to check the respective `Snapshot` which represents the state of a backup run for an application. + +```bash +$ kubectl get snapshots -n demo -l=kubestash.com/repo-name=default-blueprint +NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE AGE +default-blueprint-appbinding-samgres-frequent-backup-1725533628 default-blueprint frequent-backup 2024-09-05T10:53:59Z Delete Succeeded 7m48s +``` + +> Note: KubeStash creates a `Snapshot` with the following labels: +> - `kubestash.com/app-ref-kind: ` +> - `kubestash.com/app-ref-name: ` +> - `kubestash.com/app-ref-namespace: ` +> - `kubestash.com/repo-name: ` +> +> These labels can be used to watch only the `Snapshot`s related to our target Database or `Repository`. + +If we check the YAML of the `Snapshot`, we can find the information about the backed up components of the Database. + +```bash +$ kubectl get snapshots -n demo default-blueprint-appbinding-samgres-frequent-backup-1725533628 -oyaml +``` + +```yaml +apiVersion: storage.kubestash.com/v1alpha1 +kind: Snapshot +metadata: + creationTimestamp: "2024-09-05T10:53:59Z" + finalizers: + - kubestash.com/cleanup + generation: 1 + labels: + kubestash.com/app-ref-kind: Redis + kubestash.com/app-ref-name: sample-redis + kubestash.com/app-ref-namespace: demo + kubestash.com/repo-name: default-blueprint + annotations: + kubedb.com/db-version: "16.1" + name: default-blueprint-appbinding-samgres-frequent-backup-1725533628 + namespace: demo + ownerReferences: + - apiVersion: storage.kubestash.com/v1alpha1 + blockOwnerDeletion: true + controller: true + kind: Repository + name: default-blueprint + uid: 1125a82f-2bd8-4029-aae6-078ff5413383 + resourceVersion: "298559" + uid: c179b758-6ba4-4a32-81f1-fa41ba3dc527 +spec: + appRef: + apiGroup: kubedb.com + kind: Redis + name: sample-redis + namespace: demo + backupSession: appbinding-sample-redis-frequent-backup-1725533628 + deletionPolicy: Delete + repository: default-blueprint + session: frequent-backup + snapshotID: 01J70X3MGSYT4TJK77R8YXEV3T + type: FullBackup + version: v1 +status: + components: + dump: + driver: Restic + duration: 5.952466363s + integrity: true + path: repository/v1/frequent-backup/dump + phase: Succeeded + resticStats: + - hostPath: dumpfile.sql + id: a30f8ec138e24cbdbcce088a73e5b9d73a58750c38793ef05ff7d570148ddd2c + size: 3.345 KiB + uploaded: 3.637 KiB + size: 1.132 KiB + conditions: + - lastTransitionTime: "2024-09-05T10:53:59Z" + message: Recent snapshot list updated successfully + reason: SuccessfullyUpdatedRecentSnapshotList + status: "True" + type: RecentSnapshotListUpdated + - lastTransitionTime: "2024-09-05T10:54:20Z" + message: Metadata uploaded to backend successfully + reason: SuccessfullyUploadedSnapshotMetadata + status: "True" + type: SnapshotMetadataUploaded + integrity: true + phase: Succeeded + size: 1.132 KiB + snapshotTime: "2024-09-05T10:53:59Z" + totalComponents: 1 +``` + +> KubeStash uses a logical backup approach to take backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. Do the same for auto-backup, application backup and customize backup if necessary. + +Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `blueprint/default-blueprint/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `blueprint/default-blueprint/snapshots` directory. + +> Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. + + +## Auto-backup with custom configurations + +In this section, we are going to backup a `Redis` database of `demo` namespace. We are going to use the custom configurations which will be specified in the `BackupBlueprint` CR. + +**Prepare Backup Blueprint** + +A `BackupBlueprint` allows you to specify a template for the `Repository`,`Session` or `Variables` of `BackupConfiguration` in a Kubernetes native way. + +Now, we have to create a `BackupBlueprint` CR with a blueprint for `BackupConfiguration` object. + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupBlueprint +metadata: + name: redis-customize-backup-blueprint + namespace: demo +spec: + usagePolicy: + allowedNamespaces: + from: All + backupConfigurationTemplate: + deletionPolicy: OnDelete + # ============== Blueprint for Backends of BackupConfiguration ================= + backends: + - name: gcs-backend + storageRef: + namespace: demo + name: gcs-storage + retentionPolicy: + name: demo-retention + namespace: demo + # ============== Blueprint for Sessions of BackupConfiguration ================= + sessions: + - name: frequent-backup + sessionHistoryLimit: 3 + scheduler: + schedule: ${schedule} + jobTemplate: + backoffLimit: 1 + repositories: + - name: ${repoName} + backend: gcs-backend + directory: ${namespace}/${targetName} + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup + params: + backupCmd: rd_dump + args: ${targetedDatabase} +``` + +Note that we have used some variables (format: `${}`) in different fields. KubeStash will substitute these variables with values from the respective target’s annotations. You’re free to use any variables you like. + +Here, + +- `.spec.backupConfigurationTemplate.backends[*].storageRef` refers our earlier created `gcs-storage` backupStorage. +- `.spec.backupConfigurationTemplate.sessions[*]`: + - `.schedule` defines `${schedule}` variable, which determines the time interval for the backup. + - `.repositories[*].name` defines the `${repoName}` variable, which specifies the name of the backup `Repository`. + - `.repositories[*].directory` defines two variables, `${namespace}` and `${targetName}`, which are used to determine the path where the backup will be stored. + - `.addon.tasks[*].params.args` defines `${targetedDatabase}` variable, which identifies a single database to backup. + +Let's create the `BackupBlueprint` we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/auto-backup/examples/customize-backupblueprint.yaml +backupblueprint.core.kubestash.com/redis-customize-backup-blueprint created +``` + +Now, we are ready to backup our `Redis` 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 `Redis` CR in demo namespace. + +Below is the YAML of the `Redis` object that we are going to create, + +```yaml +apiVersion: kubedb.com/v1 +kind: Redis +metadata: + name: sample-redis-2 + namespace: demo + annotations: + blueprint.kubestash.com/name: redis-customize-backup-blueprint + blueprint.kubestash.com/namespace: demo + variables.kubestash.com/schedule: "*/10 * * * *" + variables.kubestash.com/repoName: customize-blueprint + variables.kubestash.com/namespace: demo + variables.kubestash.com/targetName: sample-redis-2 + variables.kubestash.com/targetedDatabase: redis +spec: + version: "16.1" + replicas: 3 + standbyMode: Hot + streamingMode: Synchronous + storageType: Durable + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Notice the `metadata.annotations` field, where we have defined the annotations related to the automatic backup configuration. Specifically, we've set the `BackupBlueprint` name as `redis-customize-backup-blueprint` and the namespace as `demo`. We have also provided values for the blueprint template variables, such as the backup `schedule`, `repositoryName`, `namespace`, `targetName`, and `targetedDatabase`. These annotations will be used to create a `BackupConfiguration` for this `postgreSQL` database. + +Let's create the `Redis` we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-redis-2.yaml +redis.kubedb.com/sample-redis-2 created +``` + +**Verify BackupConfiguration** + +If everything goes well, KubeStash should create a `BackupConfiguration` for our Redis in demo namespace and the phase of that `BackupConfiguration` should be `Ready`. Verify the `BackupConfiguration` object by the following command, + +```bash +$ kubectl get backupconfiguration -n demo +NAME PHASE PAUSED AGE +appbinding-sample-redis-2 Ready 2m50m +``` + +Now, let’s check the YAML of the `BackupConfiguration`. + +```bash +$ kubectl get backupconfiguration -n demo appbinding-sample-redis-2 -o yaml +``` + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + creationTimestamp: "2024-09-05T12:39:37Z" + finalizers: + - kubestash.com/cleanup + generation: 1 + labels: + app.kubernetes.io/managed-by: kubestash.com + kubestash.com/invoker-name: redis-customize-backup-blueprint + kubestash.com/invoker-namespace: demo + name: appbinding-sample-redis-2 + namespace: demo + resourceVersion: "309511" + uid: b4091166-2813-4183-acda-e2c80eaedbb5 +spec: + backends: + - name: gcs-backend + retentionPolicy: + name: demo-retention + namespace: demo + storageRef: + name: gcs-storage + namespace: demo + sessions: + - addon: + name: redis-addon + tasks: + - name: logical-backup + params: + args: redis + backupCmd: rd_dump + name: frequent-backup + repositories: + - backend: gcs-backend + directory: demo/sample-redis-2 + encryptionSecret: + name: encrypt-secret + namespace: demo + name: customize-blueprint + scheduler: + jobTemplate: + backoffLimit: 1 + template: + controller: {} + metadata: {} + spec: + resources: {} + schedule: '*/10 * * * *' + sessionHistoryLimit: 3 + target: + apiGroup: kubedb.com + kind: Redis + name: sample-redis-2 + namespace: demo +status: + backends: + - name: gcs-backend + ready: true + retentionPolicy: + found: true + ref: + name: demo-retention + namespace: demo + storage: + phase: Ready + ref: + name: gcs-storage + namespace: demo + conditions: + - lastTransitionTime: "2024-09-05T12:39:37Z" + message: Validation has been passed successfully. + reason: ResourceValidationPassed + status: "True" + type: ValidationPassed + dependencies: + - found: true + kind: Addon + name: redis-addon + phase: Ready + repositories: + - name: customize-blueprint + phase: Ready + sessions: + - conditions: + - lastTransitionTime: "2024-09-05T12:39:37Z" + message: Scheduler has been ensured successfully. + reason: SchedulerEnsured + status: "True" + type: SchedulerEnsured + - lastTransitionTime: "2024-09-05T12:39:37Z" + message: Initial backup has been triggered successfully. + reason: SuccessfullyTriggeredInitialBackup + status: "True" + type: InitialBackupTriggered + name: frequent-backup + targetFound: true +``` + +Notice the `spec.backends`, `spec.sessions` and `spec.target` sections, KubeStash automatically resolved those info from the `BackupBluePrint` and created above `BackupConfiguration`. + +**Verify BackupSession:** + +KubeStash triggers an instant backup as soon as the `BackupConfiguration` is ready. After that, backups are scheduled according to the specified schedule. + +```bash +$ kubectl get backupsession -n demo -w +NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE +appbinding-sample-redis-frequent-backup-1725597000 BackupConfiguration appbinding-sample-redis Succeeded 58s 112s +``` + +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, + +```bash +$ kubectl get repository -n demo customize-blueprint +NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE +customize-blueprint true 1 806 B Ready 8m27s 9m18s +``` + +At this moment we have one `Snapshot`. Run the following command to check the respective `Snapshot` which represents the state of a backup run for an application. + +```bash +$ kubectl get snapshots -n demo -l=kubestash.com/repo-name=customize-blueprint +NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE AGE +customize-blueprint-appbinding-ses-2-frequent-backup-1725597000 customize-blueprint frequent-backup 2024-09-06T04:30:00Z Delete Succeeded 6m19s +``` + +> Note: KubeStash creates a `Snapshot` with the following labels: +> - `kubedb.com/db-version: ` +> - `kubestash.com/app-ref-kind: ` +> - `kubestash.com/app-ref-name: ` +> - `kubestash.com/app-ref-namespace: ` +> - `kubestash.com/repo-name: ` +> +> These labels can be used to watch only the `Snapshot`s related to our target Database or `Repository`. + +If we check the YAML of the `Snapshot`, we can find the information about the backed up components of the Database. + +```bash +$ kubectl get snapshots -n demo customize-blueprint-appbinding-sql-2-frequent-backup-1725597000 -oyaml +``` + +```yaml +apiVersion: storage.kubestash.com/v1alpha1 +kind: Snapshot +metadata: + creationTimestamp: "2024-09-06T04:30:00Z" + finalizers: + - kubestash.com/cleanup + generation: 1 + labels: + kubedb.com/db-version: "16.1" + kubestash.com/app-ref-kind: Redis + kubestash.com/app-ref-name: sample-redis-2 + kubestash.com/app-ref-namespace: demo + kubestash.com/repo-name: customize-blueprint + name: customize-blueprint-appbinding-ses-2-frequent-backup-1725597000 + namespace: demo + ownerReferences: + - apiVersion: storage.kubestash.com/v1alpha1 + blockOwnerDeletion: true + controller: true + kind: Repository + name: customize-blueprint + uid: 5d4618c5-c28a-456a-9854-f6447161d3d1 + resourceVersion: "315624" + uid: 7e02a18c-c8a7-40be-bd22-e7312678d6f7 +spec: + appRef: + apiGroup: kubedb.com + kind: Redis + name: sample-redis-2 + namespace: demo + backupSession: appbinding-sample-redis-2-frequent-backup-1725597000 + deletionPolicy: Delete + repository: customize-blueprint + session: frequent-backup + snapshotID: 01J72SH8XPEHB6SYNXFE00V5PB + type: FullBackup + version: v1 +status: + components: + dump: + driver: Restic + duration: 7.060169632s + integrity: true + path: repository/v1/frequent-backup/dump + phase: Succeeded + resticStats: + - hostPath: dumpfile.sql + id: 74d82943e0d676321e989edb503f5e2d6fe5cf4f4be72d386e492ec533358c26 + size: 1.220 KiB + uploaded: 296 B + size: 1.873 KiB + conditions: + - lastTransitionTime: "2024-09-06T04:30:00Z" + message: Recent snapshot list updated successfully + reason: SuccessfullyUpdatedRecentSnapshotList + status: "True" + type: RecentSnapshotListUpdated + - lastTransitionTime: "2024-09-06T04:30:38Z" + message: Metadata uploaded to backend successfully + reason: SuccessfullyUploadedSnapshotMetadata + status: "True" + type: SnapshotMetadataUploaded + integrity: true + phase: Succeeded + size: 1.872 KiB + snapshotTime: "2024-09-06T04:30:00Z" + totalComponents: 1 +``` + + +> KubeStash uses a logical backup approach to take backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. Do the same for auto-backup, application backup and customize backup if necessary. + +Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `blueprint/demo/sample-redis-2/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `blueprint/demo/sample-redis-2/snapshots` directory. + +> Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. + +## Cleanup + +To cleanup the resources crated by this tutorial, run the following commands, + +```bash +kubectl delete backupblueprints.core.kubestash.com -n demo redis-default-backup-blueprint +kubectl delete backupblueprints.core.kubestash.com -n demo redis-customize-backup-blueprint +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 redis -n demo sample-redis +kubectl delete redis -n demo sample-redis-2 +``` \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/backup/multiple-repository.yaml b/docs/guides/redis/backup/kubestash/customization/backup/multiple-repository.yaml new file mode 100644 index 0000000000..663ca2522c --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/backup/multiple-repository.yaml @@ -0,0 +1,42 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + - name: gcs-redis-repo-2 + backend: gcs-backend + directory: /redis-copy + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/backup/passing-args.yaml b/docs/guides/redis/backup/kubestash/customization/backup/passing-args.yaml new file mode 100644 index 0000000000..a2e0e82457 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/backup/passing-args.yaml @@ -0,0 +1,38 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup + params: + args: --clean \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/backup/passing-database.yaml b/docs/guides/redis/backup/kubestash/customization/backup/passing-database.yaml new file mode 100644 index 0000000000..554ed40234 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/backup/passing-database.yaml @@ -0,0 +1,39 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup + params: + backupCmd: rd_dump + args: testdb \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/backup/resources-limit.yaml b/docs/guides/redis/backup/kubestash/customization/backup/resources-limit.yaml new file mode 100644 index 0000000000..f5b1dd64e3 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/backup/resources-limit.yaml @@ -0,0 +1,45 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + jobTemplate: + spec: + resources: + requests: + cpu: "200m" + memory: "1Gi" + limits: + cpu: "200m" + memory: "1Gi" + tasks: + - name: logical-backup \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/backup/specific-user.yaml b/docs/guides/redis/backup/kubestash/customization/backup/specific-user.yaml new file mode 100644 index 0000000000..9374d48825 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/backup/specific-user.yaml @@ -0,0 +1,41 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + jobTemplate: + spec: + securityContext: + runAsUser: 0 + runAsGroup: 0 + tasks: + - name: logical-backup \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/common/backupstorage.yaml b/docs/guides/redis/backup/kubestash/customization/common/backupstorage.yaml new file mode 100644 index 0000000000..0461b26762 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/common/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: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/common/retentionpolicy.yaml b/docs/guides/redis/backup/kubestash/customization/common/retentionpolicy.yaml new file mode 100644 index 0000000000..4591562860 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/common/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 \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/common/sample-postgres.yaml b/docs/guides/redis/backup/kubestash/customization/common/sample-postgres.yaml new file mode 100644 index 0000000000..ce97b5a41c --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/common/sample-postgres.yaml @@ -0,0 +1,18 @@ +apiVersion: kubedb.com/v1 +kind: Redis +metadata: + name: sample-redis + namespace: demo +spec: + version: "16.1" + replicas: 3 + standbyMode: Hot + streamingMode: Synchronous + storageType: Durable + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/index.md b/docs/guides/redis/backup/kubestash/customization/index.md new file mode 100644 index 0000000000..b6800eed7e --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/index.md @@ -0,0 +1,414 @@ +--- +title: Redis Backup Customization | KubeStash +description: Customizing Redis Backup and Restore process with KubeStash +menu: + docs_{{ .version }}: + identifier: guides-rd-backup-customization-stashv2 + name: Customizing Backup & Restore Process + parent: guides-rd-backup-stashv2 + weight: 50 +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, etc. + +### Passing arguments to the backup process + +KubeStash Redis addon uses the [rd_dumpall](https://www.redisql.org/docs/current/app-rd-dumpall.html) command by default for backups. However, you can change the dump command to [rd_dump](https://www.redisql.org/docs/current/app-rddump.html) by setting the `backupCmd` parameter under the `addon.tasks[*].params` section. You can pass supported options for either `rd_dumpall` or `rd_dump` through the `args` parameter in the same section. + +The below example shows how you can pass the `--clean` to include SQL commands to clean (drop) databases before recreating them. + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup + params: + args: --clean +``` + + +### Passing a target database to the backup process + +KubeStash Redis addon uses the [rd_dumpall](https://www.redisql.org/docs/current/app-rd-dumpall.html) command by default for backups. For a single database backup, you need to rewrite the dump command. You can do this by setting `backupCmd` to [rd_dump](https://www.redisql.org/docs/current/app-rddump.html) under the `addon.tasks[*].params` section and specifying the database name using the `args` parameter in the same section. + +The below example shows how you can set `rd_dump` and pass target database name during backup. + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup + params: + backupCmd: rd_dump + args: testdb +``` + +> **WARNING**: Make sure that your provided database has been created before taking backup. + +### Using multiple repositories + +You can configure multiple repositories for the same backend. For example, if you want to back up the `/redis` directory using the `gcs-redis-repo` repository, you can also back up another directory, such as `/redis-copy`, by using a different repository, like `gcs-redis-repo-2`. + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + - name: gcs-redis-repo-2 + backend: gcs-backend + directory: /redis-copy + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup +``` + +### Running backup job as a specific user + +If your cluster requires running the backup job as a specific user, you can provide `securityContext` under `addon.jobTemplate.spec.securityContext` 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: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + jobTemplate: + spec: + securityContext: + runAsUser: 0 + runAsGroup: 0 + tasks: + - name: logical-backup +``` + +### 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 `addon.jobTemplate.spec` section. + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + jobTemplate: + spec: + resources: + requests: + cpu: "200m" + memory: "1Gi" + limits: + cpu: "200m" + memory: "1Gi" + tasks: + - name: logical-backup +``` + +> You can configure additional runtime settings for backup jobs within the `addon.jobTemplate.spec` sections. For further details, please refer to the [reference](https://kubestash.com/docs/latest/concepts/crds/backupconfiguration/#podtemplate-spec). + +## Customizing Restore Process + +`KubeStash` uses [psql](https://www.redisql.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-redis-restore + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: restored-redis + dataSource: + repository: gcs-redis-repo + snapshot: latest + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup-restore + params: + args: --dbname=testdb +``` + +### Restore specific snapshot + +You can also restore a specific snapshot. At first, list the available snapshot as bellow, + +```bash +$ kubectl get snapshots.storage.kubestash.com -n demo -l=kubestash.com/repo-name=gcs-redis-repo +NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE AGE +gcs-redis-repo-sample-redis-backup-frequent-backup-1725257849 gcs-redis-repo frequent-backup 2024-09-02T06:18:01Z Delete Succeeded 15m +gcs-redis-repo-sample-redis-backup-frequent-backup-1725258000 gcs-redis-repo frequent-backup 2024-09-02T06:20:00Z Delete Succeeded 13m +gcs-redis-repo-sample-redis-backup-frequent-backup-1725258300 gcs-redis-repo frequent-backup 2024-09-02T06:25:00Z Delete Succeeded 8m34s +gcs-redis-repo-sample-redis-backup-frequent-backup-1725258600 gcs-redis-repo frequent-backup 2024-09-02T06:30:00Z Delete Succeeded 3m34s +``` + +The below example shows how you can pass a specific snapshot name in `.spec.dataSource` section. + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: RestoreSession +metadata: + name: sample-redis-restore + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: restored-redis + dataSource: + repository: gcs-redis-repo + snapshot: gcs-redis-repo-sample-redis-backup-frequent-backup-1725258000 + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - 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. + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: RestoreSession +metadata: + name: sample-redis-restore + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: restored-redis + dataSource: + repository: gcs-redis-repo + snapshot: latest + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + jobTemplate: + spec: + securityContext: + runAsUser: 0 + runAsGroup: 0 + tasks: + - name: logical-backup-restore +``` + +### Specifying Memory/CPU limit/request for the restore job + +Similar to the backup process, you can also provide `resources` field under the `addon.jobTemplate.spec.resources` section to limit the Memory/CPU for your restore job. + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: RestoreSession +metadata: + name: sample-redis-restore + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: restored-redis + dataSource: + repository: gcs-redis-repo + snapshot: latest + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + jobTemplate: + spec: + resources: + requests: + cpu: "200m" + memory: "1Gi" + limits: + cpu: "200m" + memory: "1Gi" + tasks: + - name: logical-backup-restore +``` + +> You can configure additional runtime settings for restore jobs within the `addon.jobTemplate.spec` sections. For further details, please refer to the [reference](https://kubestash.com/docs/latest/concepts/crds/restoresession/#podtemplate-spec). \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/restore/resources-limit.yaml b/docs/guides/redis/backup/kubestash/customization/restore/resources-limit.yaml new file mode 100644 index 0000000000..8b0dcad474 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/restore/resources-limit.yaml @@ -0,0 +1,30 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: RestoreSession +metadata: + name: sample-redis-restore + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: restored-redis + dataSource: + repository: gcs-redis-repo + snapshot: latest + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + jobTemplate: + spec: + resources: + requests: + cpu: "200m" + memory: "1Gi" + limits: + cpu: "200m" + memory: "1Gi" + tasks: + - name: logical-backup-restore \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/restore/specific-snapshot.yaml b/docs/guides/redis/backup/kubestash/customization/restore/specific-snapshot.yaml new file mode 100644 index 0000000000..652b5dad19 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/restore/specific-snapshot.yaml @@ -0,0 +1,21 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: RestoreSession +metadata: + name: sample-redis-restore + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: restored-redis + dataSource: + repository: gcs-redis-repo + snapshot: gcs-redis-repo-sample-redis-backup-frequent-backup-1725258000 + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup-restore \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/restore/specific-user.yaml b/docs/guides/redis/backup/kubestash/customization/restore/specific-user.yaml new file mode 100644 index 0000000000..4b87a3ff74 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/restore/specific-user.yaml @@ -0,0 +1,26 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: RestoreSession +metadata: + name: sample-redis-restore + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: restored-redis + dataSource: + repository: gcs-redis-repo + snapshot: latest + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + jobTemplate: + spec: + securityContext: + runAsUser: 0 + runAsGroup: 0 + tasks: + - name: logical-backup-restore \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/logical/examples/backupconfiguration.yaml b/docs/guides/redis/backup/kubestash/logical/examples/backupconfiguration.yaml new file mode 100644 index 0000000000..9937733aa8 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/logical/examples/backupconfiguration.yaml @@ -0,0 +1,36 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/logical/examples/backupstorage.yaml b/docs/guides/redis/backup/kubestash/logical/examples/backupstorage.yaml new file mode 100644 index 0000000000..0461b26762 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/logical/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: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/logical/examples/restored-postgres.yaml b/docs/guides/redis/backup/kubestash/logical/examples/restored-postgres.yaml new file mode 100644 index 0000000000..43616dbe51 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/logical/examples/restored-postgres.yaml @@ -0,0 +1,20 @@ +apiVersion: kubedb.com/v1 +kind: Redis +metadata: + name: restored-redis + namespace: demo +spec: + init: + waitForInitialRestore: true + version: "16.1" + replicas: 3 + standbyMode: Hot + streamingMode: Synchronous + storageType: Durable + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/logical/examples/restoresession.yaml b/docs/guides/redis/backup/kubestash/logical/examples/restoresession.yaml new file mode 100644 index 0000000000..739b076ac7 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/logical/examples/restoresession.yaml @@ -0,0 +1,21 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: RestoreSession +metadata: + name: sample-redis-restore + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: restored-redis + dataSource: + repository: gcs-redis-repo + snapshot: latest + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup-restore \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/logical/examples/retentionpolicy.yaml b/docs/guides/redis/backup/kubestash/logical/examples/retentionpolicy.yaml new file mode 100644 index 0000000000..4591562860 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/logical/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 \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/logical/examples/sample-postgres.yaml b/docs/guides/redis/backup/kubestash/logical/examples/sample-postgres.yaml new file mode 100644 index 0000000000..ce97b5a41c --- /dev/null +++ b/docs/guides/redis/backup/kubestash/logical/examples/sample-postgres.yaml @@ -0,0 +1,18 @@ +apiVersion: kubedb.com/v1 +kind: Redis +metadata: + name: sample-redis + namespace: demo +spec: + version: "16.1" + replicas: 3 + standbyMode: Hot + streamingMode: Synchronous + storageType: Durable + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/logical/index.md b/docs/guides/redis/backup/kubestash/logical/index.md new file mode 100644 index 0000000000..73f0372465 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/logical/index.md @@ -0,0 +1,780 @@ +--- +title: Backup & Restore Redis | KubeStash +description: Backup ans Restore Redis database using KubeStash +menu: + docs_{{ .version }}: + identifier: guides-rd-logical-backup-stashv2 + name: Logical Backup + parent: guides-rd-backup-stashv2 + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +# Backup and Restore Redis database using KubeStash + +KubeStash allows you to backup and restore `Redis` databases. It supports backups for `Redis` instances running in Standalone, and HA cluster configurations. KubeStash makes managing your `Redis` backups and restorations more straightforward and efficient. + +This guide will give you an overview how you can take backup and restore your `Redis` databases using `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` or `Kind`. +- Install `KubeDB` in your cluster following the steps [here](/docs/setup/README.md). +- Install `KubeStash` in your cluster following the steps [here](https://kubestash.com/docs/latest/setup/install/kubestash). +- Install KubeStash `kubectl` plugin following the steps [here](https://kubestash.com/docs/latest/setup/install/kubectl-plugin/). +- If you are not familiar with how KubeStash backup and restore Redis databases, please check the following guide [here](/docs/guides/redis/backup/kubestash/overview/index.md). + +You should be familiar with the following `KubeStash` concepts: + +- [BackupStorage](https://kubestash.com/docs/latest/concepts/crds/backupstorage/) +- [BackupConfiguration](https://kubestash.com/docs/latest/concepts/crds/backupconfiguration/) +- [BackupSession](https://kubestash.com/docs/latest/concepts/crds/backupsession/) +- [RestoreSession](https://kubestash.com/docs/latest/concepts/crds/restoresession/) +- [Addon](https://kubestash.com/docs/latest/concepts/crds/addon/) +- [Function](https://kubestash.com/docs/latest/concepts/crds/function/) +- [Task](https://kubestash.com/docs/latest/concepts/crds/addon/#task-specification) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/guides/redis/backup/kubestash/logical/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. + + +## Backup Redis + +KubeStash supports backups for `Redis` instances across different configurations, including Standalone and HA Cluster setups. In this demonstration, we'll focus on a `Redis` database using HA cluster configuration. The backup and restore process is similar for Standalone configuration. + +This section will demonstrate how to backup a `Redis` database. Here, we are going to deploy a `Redis` database using KubeDB. Then, we are going to backup this database into a `GCS` bucket. Finally, we are going to restore the backup up data into another `Redis` database. + + +### Deploy Sample Redis Database + +Let's deploy a sample `Redis` database and insert some data into it. + +**Create Redis CR:** + +Below is the YAML of a sample `Redis` CR that we are going to create for this tutorial: + +```yaml +apiVersion: kubedb.com/v1 +kind: Redis +metadata: + name: sample-redis + namespace: demo +spec: + version: "16.1" + replicas: 3 + standbyMode: Hot + streamingMode: Synchronous + storageType: Durable + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Create the above `Redis` CR, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples/sample-redis.yaml +redis.kubedb.com/sample-redis created +``` + +KubeDB will deploy a `Redis` 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, + +```bash +$ kubectl get rd -n demo sample-redis +NAME VERSION STATUS AGE +sample-redis 16.1 Ready 5m1s +``` + +The database is `Ready`. Verify that KubeDB has created a `Secret` and a `Service` for this database using the following commands, + +```bash +$ kubectl get secret -n demo +NAME TYPE DATA AGE +sample-redis-auth kubernetes.io/basic-auth 2 5m20s + +$ kubectl get service -n demo -l=app.kubernetes.io/instance=sample-redis +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +sample-redis ClusterIP 10.96.23.177 5432/TCP,2379/TCP 5m55s +sample-redis-pods ClusterIP None 5432/TCP,2380/TCP,2379/TCP 5m55s +sample-redis-standby ClusterIP 10.96.26.118 5432/TCP 5m55s +``` + +Here, we have to use service `sample-redis` and secret `sample-redis-auth` to connect with the database. `KubeDB` creates an [AppBinding](/docs/guides/redis/concepts/appbinding.md) CR that holds the necessary information to connect with the database. + + +**Verify AppBinding:** + +Verify that the `AppBinding` has been created successfully using the following command, + +```bash +$ kubectl get appbindings -n demo +NAME TYPE VERSION AGE +sample-redis kubedb.com/redis 16.1 9m30s +``` + +Let's check the YAML of the above `AppBinding`, + +```bash +$ kubectl get appbindings -n demo sample-redis -o yaml +``` + +```yaml +apiVersion: appcatalog.appscode.com/v1alpha1 +kind: AppBinding +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"kubedb.com/v1","kind":"Redis","metadata":{"annotations":{},"name":"sample-redis","namespace":"demo"},"spec":{"deletionPolicy":"DoNotTerminate","replicas":3,"standbyMode":"Hot","storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}}},"storageType":"Durable","streamingMode":"Synchronous","version":"16.1"}} + creationTimestamp: "2024-09-04T10:07:04Z" + generation: 1 + labels: + app.kubernetes.io/component: database + app.kubernetes.io/instance: sample-redis + app.kubernetes.io/managed-by: kubedb.com + app.kubernetes.io/name: redises.kubedb.com + name: sample-redis + namespace: demo + ownerReferences: + - apiVersion: kubedb.com/v1 + blockOwnerDeletion: true + controller: true + kind: Redis + name: sample-redis + uid: 0810a96c-a2b6-4e8a-a70a-51753660450c + resourceVersion: "245972" + uid: 73bdba85-c932-464b-93a8-7f1ba8dfff1b +spec: + appRef: + apiGroup: kubedb.com + kind: Redis + name: sample-redis + namespace: demo + clientConfig: + service: + name: sample-redis + path: / + port: 5432 + query: sslmode=disable + scheme: redisql + parameters: + apiVersion: appcatalog.appscode.com/v1alpha1 + kind: StashAddon + stash: + addon: + backupTask: + name: redis-backup-16.1 + restoreTask: + name: redis-restore-16.1 + secret: + name: sample-redis-auth + type: kubedb.com/redis + version: "16.1" +``` + +KubeStash uses the `AppBinding` CR to connect with the target database. It requires the following two fields to set in AppBinding's `.spec` section. + +Here, + +- `.spec.clientConfig.service.name` specifies the name of the Service that connects to the database. +- `.spec.secret` specifies the name of the Secret that holds necessary credentials to access the database. +- `.spec.type` specifies the types of the app that this AppBinding is pointing to. KubeDB generated AppBinding follows the following format: `/`. + + +**Insert Sample Data:** + +Now, we are going to exec into one of the database pod and create some sample data. At first, find out the database `Pod` using the following command, + +```bash +$ kubectl get pods -n demo --selector="app.kubernetes.io/instance=sample-redis" +NAME READY STATUS RESTARTS AGE +sample-redis-0 2/2 Running 0 16m +sample-redis-1 2/2 Running 0 13m +sample-redis-2 2/2 Running 0 13m +``` + +Now, let’s exec into the pod and create a table, + +```bash +$ kubectl exec -it -n demo sample-redis-0 -- sh + +# login as "redis" superuser. +/ $ psql -U redis +psql (16.1) +Type "help" for help. + +# list available databases +redis=# \l + List of databases + Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges +---------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- + kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis + template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis +(4 rows) + +# create a database named "demo" +redis=# create database demo; +CREATE DATABASE + +# verify that the "demo" database has been created +redis=# \l + List of databases + Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges +---------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- + demo | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis + template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis +(5 rows) + +# connect to the "demo" database +redis=# \c demo +You are now connected to database "demo" as user "redis". + +# create a sample table +demo=# CREATE TABLE COMPANY( NAME TEXT NOT NULL, EMPLOYEE INT NOT NULL); +CREATE TABLE + +# verify that the table has been created +demo=# \d + List of relations + Schema | Name | Type | Owner +--------+---------+-------+---------- + public | company | table | redis +(1 row) + +# insert multiple rows of data into the table +demo=# INSERT INTO COMPANY (NAME, EMPLOYEE) VALUES ('TechCorp', 100), ('InnovateInc', 150), ('AlphaTech', 200); +INSERT 0 3 + +# verify the data insertion +demo=# SELECT * FROM COMPANY; + name | employee +-------------+---------- + TechCorp | 100 + InnovateInc | 150 + AlphaTech | 200 +(3 rows) + +# quit from the database +demo=# \q + +# exit from the pod +/ $ exit +``` + +Now, we are ready to backup the database. + +### 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/). + +**Create Secret:** + +Let's create a secret called `gcs-secret` with access credentials to our desired GCS bucket, + +```bash +$ echo -n '' > GOOGLE_PROJECT_ID +$ cat /path/to/downloaded-sa-key.json > GOOGLE_SERVICE_ACCOUNT_JSON_KEY +$ kubectl create secret generic -n demo gcs-secret \ + --from-file=./GOOGLE_PROJECT_ID \ + --from-file=./GOOGLE_SERVICE_ACCOUNT_JSON_KEY +secret/gcs-secret created +``` + +**Create BackupStorage:** + +Now, create a `BackupStorage` using this secret. Below is the YAML of `BackupStorage` CR we are going to create, + +```yaml +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: WipeOut +``` + +Let's create the BackupStorage we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples/backupstorage.yaml +backupstorage.storage.kubestash.com/gcs-storage created +``` + +Now, we are ready to backup our database to our desired backend. + +**Create RetentionPolicy:** + +Now, let's create a `RetentionPolicy` to specify how the old Snapshots should be cleaned up. + +Below is the YAML of the `RetentionPolicy` object that we are going to create, + +```yaml +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 +``` + +Let’s create the above `RetentionPolicy`, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples/retentionpolicy.yaml +retentionpolicy.storage.kubestash.com/demo-retention created +``` + +### Backup + +We have to create a `BackupConfiguration` targeting respective `sample-redis` Redis database. Then, KubeStash will create a `CronJob` for each session to take periodic backup of that database. + +At first, we need to create a secret with a Restic password for backup data encryption. + +**Create Secret:** + +Let's create a secret called `encrypt-secret` with the Restic password, + +```bash +$ echo -n 'changeit' > RESTIC_PASSWORD +$ kubectl create secret generic -n demo encrypt-secret \ + --from-file=./RESTIC_PASSWORD \ +secret "encrypt-secret" created +``` + +Below is the YAML for `BackupConfiguration` CR to backup the `sample-redis` database that we have deployed earlier, + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: BackupConfiguration +metadata: + name: sample-redis-backup + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: sample-redis + 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-redis-repo + backend: gcs-backend + directory: /redis + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup +``` + +- `.spec.sessions[*].schedule` specifies that we want to backup the database at `5 minutes` interval. +- `.spec.target` refers to the targeted `sample-redis` Redis database that we created earlier. + +Let's create the `BackupConfiguration` CR that we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/kubestash/logical/examples/backupconfiguration.yaml +backupconfiguration.core.kubestash.com/sample-redis-backup 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, + +```bash +$ kubectl get backupconfiguration -n demo +NAME PHASE PAUSED AGE +sample-redis-backup Ready 2m50s +``` + +Additionally, we can verify that the `Repository` specified in the `BackupConfiguration` has been created using the following command, + +```bash +$ kubectl get repo -n demo +NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE +gcs-redis-repo 0 0 B Ready 3m +``` + +KubeStash keeps the backup for `Repository` YAMLs. If we navigate to the GCS bucket, we will see the `Repository` YAML stored in the `demo/redis` directory. + +**Verify CronJob:** + +It will also create a `CronJob` with the schedule specified in `spec.sessions[*].scheduler.schedule` field of `BackupConfiguration` CR. + +Verify that the `CronJob` has been created using the following command, + +```bash +$ kubectl get cronjob -n demo +NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE +trigger-sample-redis-backup-frequent-backup */5 * * * * 0 2m45s 3m25s +``` + +**Verify BackupSession:** + +KubeStash triggers an instant backup as soon as the `BackupConfiguration` is ready. After that, backups are scheduled according to the specified schedule. + +```bash +$ kubectl get backupsession -n demo -w +NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE +sample-redis-backup-frequent-backup-1725449400 BackupConfiguration sample-redis-backup Succeeded 7m22s +``` + +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 `sample-redis-backup` has been updated by the following command, + +```bash +$ kubectl get repository -n demo sample-redis-backup +NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE +sample-redis-backup true 1 806 B Ready 8m27s 9m18s +``` + +At this moment we have one `Snapshot`. Run the following command to check the respective `Snapshot` which represents the state of a backup run for an application. + +```bash +$ kubectl get snapshots -n demo -l=kubestash.com/repo-name=gcs-redis-repo +NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE AGE +gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 gcs-redis-repo frequent-backup 2024-01-23T13:10:54Z Delete Succeeded 16h +``` + +> Note: KubeStash creates a `Snapshot` with the following labels: +> - `kubestash.com/app-ref-kind: ` +> - `kubestash.com/app-ref-name: ` +> - `kubestash.com/app-ref-namespace: ` +> - `kubestash.com/repo-name: ` +> +> These labels can be used to watch only the `Snapshot`s related to our target Database or `Repository`. + +If we check the YAML of the `Snapshot`, we can find the information about the backed up components of the Database. + +```bash +$ kubectl get snapshots -n demo gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 -oyaml +``` + +```yaml +apiVersion: storage.kubestash.com/v1alpha1 +kind: Snapshot +metadata: + creationTimestamp: "2024-09-04T11:30:00Z" + finalizers: + - kubestash.com/cleanup + generation: 1 + labels: + kubestash.com/app-ref-kind: Redis + kubestash.com/app-ref-name: sample-redis + kubestash.com/app-ref-namespace: demo + kubestash.com/repo-name: gcs-redis-repo + annotations: + kubedb.com/db-version: "16.1" + name: gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 + namespace: demo + ownerReferences: + - apiVersion: storage.kubestash.com/v1alpha1 + blockOwnerDeletion: true + controller: true + kind: Repository + name: gcs-redis-repo + uid: 1009bd4a-b211-49f1-a64c-3c979c699a81 + resourceVersion: "253523" + uid: c6757c49-e13b-4a36-9f7d-64eae350423f +spec: + appRef: + apiGroup: kubedb.com + kind: Redis + name: sample-redis + namespace: demo + backupSession: sample-redis-backup-frequent-backup-1725449400 + deletionPolicy: Delete + repository: gcs-redis-repo + session: frequent-backup + snapshotID: 01J6YCRWEWAKACMGZYR2R7YJ5C + type: FullBackup + version: v1 +status: + components: + dump: + driver: Restic + duration: 11.526138009s + integrity: true + path: repository/v1/frequent-backup/dump + phase: Succeeded + resticStats: + - hostPath: dumpfile.sql + id: 008eb87193e7db112e9ad8f42c9302c851a1fbacb7165a5cb3aa2d27dd210764 + size: 3.345 KiB + uploaded: 299 B + size: 2.202 KiB + conditions: + - lastTransitionTime: "2024-09-04T11:30:00Z" + message: Recent snapshot list updated successfully + reason: SuccessfullyUpdatedRecentSnapshotList + status: "True" + type: RecentSnapshotListUpdated + - lastTransitionTime: "2024-09-04T11:30:32Z" + message: Metadata uploaded to backend successfully + reason: SuccessfullyUploadedSnapshotMetadata + status: "True" + type: SnapshotMetadataUploaded + integrity: true + phase: Succeeded + size: 2.201 KiB + snapshotTime: "2024-09-04T11:30:00Z" + totalComponents: 1 +``` + +> KubeStash uses a logical backup approach to take backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. Do the same for auto-backup, application backup and customize backup if necessary. + +Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/popstgres/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/redis/snapshots` directory. + +> 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. + +Now, we have to deploy the restored database similarly as we have deployed the original `sample-redis` database. However, this time there will be the following differences: + +- We are going to specify `.spec.init.waitForInitialRestore` field that tells KubeDB to wait for first restore to complete before marking this database is ready to use. + +Below is the YAML for `Redis` CR we are going deploy to initialize from backup, + +```yaml +apiVersion: kubedb.com/v1 +kind: Redis +metadata: + name: restored-redis + namespace: demo +spec: + init: + waitForInitialRestore: true + version: "16.1" + replicas: 3 + standbyMode: Hot + streamingMode: Synchronous + storageType: Durable + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the above database, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples/restored-redis.yaml +redis.kubedb.com/restore-redis created +``` + +If you check the database status, you will see it is stuck in **`Provisioning`** state. + +```bash +$ kubectl get redis -n demo restored-redis +NAME VERSION STATUS AGE +restored-redis 8.2.0 Provisioning 61s +``` + +#### Create RestoreSession: + +Now, we need to create a `RestoreSession` CR pointing to targeted `Redis` database. + +Below, is the contents of YAML file of the `RestoreSession` object that we are going to create to restore backed up data into the newly created `Redis` database named `restored-redis`. + +```yaml +apiVersion: core.kubestash.com/v1alpha1 +kind: RestoreSession +metadata: + name: sample-redis-restore + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: restored-redis + dataSource: + repository: gcs-redis-repo + snapshot: latest + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup-restore +``` + +Here, + +- `.spec.target` refers to the newly created `restored-redis` Redis object to where we want to restore backup data. +- `.spec.dataSource.repository` specifies the Repository object that holds the backed up data. +- `.spec.dataSource.snapshot` specifies to restore from latest `Snapshot`. + +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/redis/backup/kubestash/logical/examples/restoresession.yaml +restoresession.core.kubestash.com/sample-redis-restore created +``` + +Once, you have created the `RestoreSession` object, KubeStash will create restore Job. Run the following command to watch the phase of the `RestoreSession` object, + +```bash +$ watch kubectl get restoresession -n demo +Every 2.0s: kubectl get restores... AppsCode-PC-03: Wed Aug 21 10:44:05 2024 +NAME REPOSITORY FAILURE-POLICY PHASE DURATION AGE +sample-redis-restore gcs-redis-repo Succeeded 7s 116s +``` + +The `Succeeded` phase means that the restore process has been completed successfully. + +#### 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. + +At first, check if the database has gone into **`Ready`** state by the following command, + +```bash +$ kubectl get redis -n demo restored-redis +NAME VERSION STATUS AGE +restored-redis 16.1 Ready 6m31s +``` + +Now, find out the database `Pod` by the following command, + +```bash +$ kubectl get pods -n demo --selector="app.kubernetes.io/instance=restored-redis" +NAME READY STATUS RESTARTS AGE +restored-redis-0 2/2 Running 0 6m7s +restored-redis-1 2/2 Running 0 6m1s +restored-redis-2 2/2 Running 0 5m55s +``` + +Now, lets exec one of the `Pod` and verify restored data. + +```bash +$ kubectl exec -it -n demo restored-redis-0 -- /bin/sh +# login as "redis" superuser. +/ # psql -U redis +psql (11.11) +Type "help" for help. + +# verify that the "demo" database has been restored +redis=# \l + List of databases + Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges +---------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- + demo | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | + template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis + template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + + | | | | | | | | redis=CTc/redis +(5 rows) + +# connect to the "demo" database +redis=# \c demo +You are now connected to database "demo" as user "redis". + +# verify that the sample table has been restored +demo=# \d + List of relations + Schema | Name | Type | Owner +--------+---------+-------+---------- + public | company | table | redis +(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 + +# exit from the pod +/ # exit +``` + +So, from the above output, we can see the `demo` database we had created in the original database `sample-redis` has been restored in the `restored-redis` database. + +## Cleanup + +To cleanup the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete backupconfigurations.core.kubestash.com -n demo sample-redis-backup +kubectl delete restoresessions.core.kubestash.com -n demo restore-sample-redis +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 redis -n demo restored-redis +kubectl delete redis -n demo sample-redis +``` \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/overview/images/backup_overview.svg b/docs/guides/redis/backup/kubestash/overview/images/backup_overview.svg new file mode 100644 index 0000000000..9d245e0dcd --- /dev/null +++ b/docs/guides/redis/backup/kubestash/overview/images/backup_overview.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/overview/images/kubedb_plus_kubestash.svg b/docs/guides/redis/backup/kubestash/overview/images/kubedb_plus_kubestash.svg new file mode 100644 index 0000000000..380d92d969 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/overview/images/kubedb_plus_kubestash.svg @@ -0,0 +1,21 @@ + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/guides/redis/backup/kubestash/overview/images/restore_overview.svg b/docs/guides/redis/backup/kubestash/overview/images/restore_overview.svg new file mode 100644 index 0000000000..f2c2488962 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/overview/images/restore_overview.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/overview/index.md b/docs/guides/redis/backup/kubestash/overview/index.md new file mode 100644 index 0000000000..8fba477a88 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/overview/index.md @@ -0,0 +1,98 @@ +--- +title: Backup & Restore Redis Using KubeStash +menu: + docs_{{ .version }}: + identifier: guides-rd-backup-overview-stashv2 + name: Overview + parent: guides-rd-backup-stashv2 + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +{{< notice type="warning" message="Please install [KubeStash](https://kubestash.com/docs/latest/setup/install/kubestash/) to try this feature. Database backup with KubeStash is already included in the KubeDB license. So, you don't need a separate license for KubeStash." >}} + +# Redis Backup & Restore Overview + +KubeDB 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 and databases. 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.). + +
+  KubeDB + KubeStash +
Fig: Backup KubeDB Databases Using KubeStash
+
+ +## How Backup Works + +The following diagram shows how KubeStash takes backup of a `Redis` database. Open the image in a new tab to see the enlarged version. + +
+  Redis Backup Overview +
Fig: Redis Backup Overview
+
+ +The backup process consists of the following steps: + +1. At first, a user creates a `Secret`. This secret holds the credentials to access the backend where the backed up data will be stored. + +2. Then, she creates a `BackupStorage` custom resource that specifies the backend information, along with the `Secret` containing the credentials needed to access the backend. + +3. KubeStash operator watches for `BackupStorage` custom resources. When it finds a `BackupStorage` object, it initializes the `BackupStorage` by uploading the `metadata.yaml` file into the target storage. + +4. Then, she creates a `BackupConfiguration` custom resource that specifies the targeted the KubeDB managed `Redis` database, the `Addon` info with a specified task, etc. It also provides information about one or more repositories, each indicating a path and a `BackupStorage` for storing the backed-up data. + +5. KubeStash operator watches for `BackupConfiguration` objects. + +6. Once the KubeStash operator finds a `BackupConfiguration` object, it creates `Repository` with the information specified in the `BackupConfiguration`. + +7. KubeStash operator watches for `Repository` custom resources. When it finds the `Repository` object, it Initializes `Repository` by uploading `repository.yaml` file into the `spec.sessions[*].repositories[*].directory` path specified in `BackupConfiguration`. + +8. Then, it creates a `CronJob` for each session with the schedule specified in `BackupConfiguration` to trigger backup periodically. + +9. KubeStash operator triggers an instant backup as soon as the `BackupConfiguration` is ready. After that, backups are triggered by the `CronJob` according to the specified schedule. + +10. KubeStash operator watches for `BackupSession` custom resources. + +11. When it finds a `BackupSession` object, it creates a `Snapshot` custom resource for each `Repository` specified in the `BackupConfiguration`. + +12. Then it resolves the respective `Addon` and `Function` and prepares backup `Job` definition. + +13. Then, it creates the `Job` to backup the targeted `Redis` database. + +14. The backup `Job` reads necessary information (e.g. auth secret, port) to connect with the database from the `AppBinding` crd. It also reads backend information and access credentials from BackupStorage crd, Storage Secret and Repository path respectively. + +15. Then, the `Job` dumps the targeted `Redis` 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. + +16. After the backup process is completed, the backup `Job` updates the `status.components[dump]` field of the `Snapshot` resources with backup information of the target `Redis` database. + +## How Restore Process Works + +The following diagram shows how KubeStash restores backed up data into a `Redis` database. Open the image in a new tab to see the enlarged version. + +
+  Database Restore Overview +
Fig: Redis Restore Process Overview
+
+ +The restore process consists of the following steps: + +1. At first, a user creates a `Redis` database where the data will be restored or the user can use the same `Redis` database. + +2. Then, she creates a `RestoreSession` custom resource that specifies the target `Redis` database where the backed-up data will be restored. the `Repository` object that points to a `BackupStorage` that holds backend information, and the target `Snapshot`, which will be restored. It also specifies the `Addon` info with task to use to restore. + +3. KubeStash operator watches for `RestoreSession` custom resources. + +4. When it finds a `RestoreSession` custom resource, it resolves the respective `Addon` and `Function` and prepares a restore `Job` definition. + +5. Then, it creates the `Job` to restore the target. + +6. 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. + +7. 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. + +8. Finally, when the restore process is completed, the `Job` updates the `status.components[*]` field of the `RestoreSession` with restore information of the target database. + +## Next Steps + +- Backup a `Redis` database using KubeStash by the following guides from [here](/docs/guides/redis/backup/kubestash/logical/index.md). \ No newline at end of file From 0437266ed9c56562a4f43c9b69718f402f6e835e Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Tue, 17 Sep 2024 18:50:16 +0600 Subject: [PATCH 03/11] Add overview Signed-off-by: Neaj Morshad --- .../backup/kubestash/overview/images/backup_overview.svg | 2 +- .../backup/kubestash/overview/images/restore_overview.svg | 2 +- docs/guides/redis/backup/kubestash/overview/index.md | 8 ++++---- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/guides/redis/backup/kubestash/overview/images/backup_overview.svg b/docs/guides/redis/backup/kubestash/overview/images/backup_overview.svg index 9d245e0dcd..460ef2beea 100644 --- a/docs/guides/redis/backup/kubestash/overview/images/backup_overview.svg +++ b/docs/guides/redis/backup/kubestash/overview/images/backup_overview.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/overview/images/restore_overview.svg b/docs/guides/redis/backup/kubestash/overview/images/restore_overview.svg index f2c2488962..cb822b8c8e 100644 --- a/docs/guides/redis/backup/kubestash/overview/images/restore_overview.svg +++ b/docs/guides/redis/backup/kubestash/overview/images/restore_overview.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/overview/index.md b/docs/guides/redis/backup/kubestash/overview/index.md index 8fba477a88..e40e1a39d4 100644 --- a/docs/guides/redis/backup/kubestash/overview/index.md +++ b/docs/guides/redis/backup/kubestash/overview/index.md @@ -16,7 +16,7 @@ section_menu_id: guides # Redis Backup & Restore Overview -KubeDB 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 and databases. 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.). +KubeDB 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 and databases. 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.).
  KubeDB + KubeStash @@ -36,11 +36,11 @@ The backup process consists of the following steps: 1. At first, a user creates a `Secret`. This secret holds the credentials to access the backend where the backed up data will be stored. -2. Then, she creates a `BackupStorage` custom resource that specifies the backend information, along with the `Secret` containing the credentials needed to access the backend. +2. Then, he creates a `BackupStorage` custom resource that specifies the backend information, along with the `Secret` containing the credentials needed to access the backend. 3. KubeStash operator watches for `BackupStorage` custom resources. When it finds a `BackupStorage` object, it initializes the `BackupStorage` by uploading the `metadata.yaml` file into the target storage. -4. Then, she creates a `BackupConfiguration` custom resource that specifies the targeted the KubeDB managed `Redis` database, the `Addon` info with a specified task, etc. It also provides information about one or more repositories, each indicating a path and a `BackupStorage` for storing the backed-up data. +4. Then, he creates a `BackupConfiguration` custom resource that specifies the targeted the KubeDB managed `Redis` database, the `Addon` info with a specified task, etc. It also provides information about one or more repositories, each indicating a path and a `BackupStorage` for storing the backed-up data. 5. KubeStash operator watches for `BackupConfiguration` objects. @@ -79,7 +79,7 @@ The restore process consists of the following steps: 1. At first, a user creates a `Redis` database where the data will be restored or the user can use the same `Redis` database. -2. Then, she creates a `RestoreSession` custom resource that specifies the target `Redis` database where the backed-up data will be restored. the `Repository` object that points to a `BackupStorage` that holds backend information, and the target `Snapshot`, which will be restored. It also specifies the `Addon` info with task to use to restore. +2. Then, he creates a `RestoreSession` custom resource that specifies the target `Redis` database where the backed-up data will be restored. the `Repository` object that points to a `BackupStorage` that holds backend information, and the target `Snapshot`, which will be restored. It also specifies the `Addon` info with task to use to restore. 3. KubeStash operator watches for `RestoreSession` custom resources. From bccdde40bd2f3cf37f0222e7706a5e304826f89d Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Tue, 17 Sep 2024 20:13:38 +0600 Subject: [PATCH 04/11] add logical backup restore complete doc Signed-off-by: Neaj Morshad --- .../logical/examples/backupconfiguration.yaml | 4 +- .../logical/examples/backupstorage.yaml | 5 +- ...ample-postgres.yaml => redis-cluster.yaml} | 18 +- ...tgres.yaml => restored-redis-cluster.yaml} | 18 +- .../logical/examples/restoresession.yaml | 4 +- .../redis/backup/kubestash/logical/index.md | 489 ++++++++---------- .../redis/backup/kubestash/overview/index.md | 12 +- 7 files changed, 246 insertions(+), 304 deletions(-) rename docs/guides/redis/backup/kubestash/logical/examples/{sample-postgres.yaml => redis-cluster.yaml} (56%) rename docs/guides/redis/backup/kubestash/logical/examples/{restored-postgres.yaml => restored-redis-cluster.yaml} (59%) diff --git a/docs/guides/redis/backup/kubestash/logical/examples/backupconfiguration.yaml b/docs/guides/redis/backup/kubestash/logical/examples/backupconfiguration.yaml index 9937733aa8..e2eb85407a 100644 --- a/docs/guides/redis/backup/kubestash/logical/examples/backupconfiguration.yaml +++ b/docs/guides/redis/backup/kubestash/logical/examples/backupconfiguration.yaml @@ -1,14 +1,14 @@ apiVersion: core.kubestash.com/v1alpha1 kind: BackupConfiguration metadata: - name: sample-redis-backup + name: redis-cluster-backup namespace: demo spec: target: apiGroup: kubedb.com kind: Redis namespace: demo - name: sample-redis + name: redis-cluster backends: - name: gcs-backend storageRef: diff --git a/docs/guides/redis/backup/kubestash/logical/examples/backupstorage.yaml b/docs/guides/redis/backup/kubestash/logical/examples/backupstorage.yaml index 0461b26762..5535624773 100644 --- a/docs/guides/redis/backup/kubestash/logical/examples/backupstorage.yaml +++ b/docs/guides/redis/backup/kubestash/logical/examples/backupstorage.yaml @@ -7,11 +7,10 @@ spec: storage: provider: gcs gcs: - bucket: kubestash-qa + bucket: neaj-demo prefix: demo secretName: gcs-secret usagePolicy: allowedNamespaces: from: All - default: true - deletionPolicy: WipeOut \ No newline at end of file + deletionPolicy: Delete \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/logical/examples/sample-postgres.yaml b/docs/guides/redis/backup/kubestash/logical/examples/redis-cluster.yaml similarity index 56% rename from docs/guides/redis/backup/kubestash/logical/examples/sample-postgres.yaml rename to docs/guides/redis/backup/kubestash/logical/examples/redis-cluster.yaml index ce97b5a41c..13248126fa 100644 --- a/docs/guides/redis/backup/kubestash/logical/examples/sample-postgres.yaml +++ b/docs/guides/redis/backup/kubestash/logical/examples/redis-cluster.yaml @@ -1,18 +1,20 @@ apiVersion: kubedb.com/v1 kind: Redis metadata: - name: sample-redis + name: redis-cluster namespace: demo spec: - version: "16.1" - replicas: 3 - standbyMode: Hot - streamingMode: Synchronous + version: 7.4.0 + mode: Cluster + cluster: + shards: 3 + replicas: 2 storageType: Durable storage: - accessModes: - - ReadWriteOnce + storageClassName: "standard" resources: requests: storage: 1Gi - deletionPolicy: WipeOut \ No newline at end of file + accessModes: + - ReadWriteOnce + deletionPolicy: Delete \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/logical/examples/restored-postgres.yaml b/docs/guides/redis/backup/kubestash/logical/examples/restored-redis-cluster.yaml similarity index 59% rename from docs/guides/redis/backup/kubestash/logical/examples/restored-postgres.yaml rename to docs/guides/redis/backup/kubestash/logical/examples/restored-redis-cluster.yaml index 43616dbe51..fb8c3671d7 100644 --- a/docs/guides/redis/backup/kubestash/logical/examples/restored-postgres.yaml +++ b/docs/guides/redis/backup/kubestash/logical/examples/restored-redis-cluster.yaml @@ -1,20 +1,22 @@ apiVersion: kubedb.com/v1 kind: Redis metadata: - name: restored-redis + name: restored-redis-cluster namespace: demo spec: init: waitForInitialRestore: true - version: "16.1" - replicas: 3 - standbyMode: Hot - streamingMode: Synchronous + version: 7.4.0 + mode: Cluster + cluster: + shards: 3 + replicas: 2 storageType: Durable storage: - accessModes: - - ReadWriteOnce + storageClassName: "standard" resources: requests: storage: 1Gi - deletionPolicy: WipeOut \ No newline at end of file + accessModes: + - ReadWriteOnce + deletionPolicy: Delete \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/logical/examples/restoresession.yaml b/docs/guides/redis/backup/kubestash/logical/examples/restoresession.yaml index 739b076ac7..82336088b0 100644 --- a/docs/guides/redis/backup/kubestash/logical/examples/restoresession.yaml +++ b/docs/guides/redis/backup/kubestash/logical/examples/restoresession.yaml @@ -1,14 +1,14 @@ apiVersion: core.kubestash.com/v1alpha1 kind: RestoreSession metadata: - name: sample-redis-restore + name: redis-cluster-restore namespace: demo spec: target: apiGroup: kubedb.com kind: Redis namespace: demo - name: restored-redis + name: restored-redis-cluster dataSource: repository: gcs-redis-repo snapshot: latest diff --git a/docs/guides/redis/backup/kubestash/logical/index.md b/docs/guides/redis/backup/kubestash/logical/index.md index 73f0372465..b6b431dcb3 100644 --- a/docs/guides/redis/backup/kubestash/logical/index.md +++ b/docs/guides/redis/backup/kubestash/logical/index.md @@ -13,7 +13,7 @@ section_menu_id: guides # Backup and Restore Redis database using KubeStash -KubeStash allows you to backup and restore `Redis` databases. It supports backups for `Redis` instances running in Standalone, and HA cluster configurations. KubeStash makes managing your `Redis` backups and restorations more straightforward and efficient. +KubeStash allows you to backup and restore `Redis` databases. It supports backups for `Redis` instances running in Standalone, Cluster and Sentinel mode. KubeStash makes managing your `Redis` backups and restorations more straightforward and efficient. This guide will give you an overview how you can take backup and restore your `Redis` databases using `Kubestash`. @@ -48,7 +48,7 @@ namespace/demo created ## Backup Redis -KubeStash supports backups for `Redis` instances across different configurations, including Standalone and HA Cluster setups. In this demonstration, we'll focus on a `Redis` database using HA cluster configuration. The backup and restore process is similar for Standalone configuration. +KubeStash supports backups for `Redis` instances across different configurations, including Standalone, Cluster and Sentinel mode setups. In this demonstration, we'll focus on a `Redis` database in Cluster mode. The backup and restore process is similar for Standalone and Sentinel mode. This section will demonstrate how to backup a `Redis` database. Here, we are going to deploy a `Redis` database using KubeDB. Then, we are going to backup this database into a `GCS` bucket. Finally, we are going to restore the backup up data into another `Redis` database. @@ -65,28 +65,30 @@ Below is the YAML of a sample `Redis` CR that we are going to create for this tu apiVersion: kubedb.com/v1 kind: Redis metadata: - name: sample-redis + name: redis-cluster namespace: demo spec: - version: "16.1" - replicas: 3 - standbyMode: Hot - streamingMode: Synchronous + version: 7.4.0 + mode: Cluster + cluster: + shards: 3 + replicas: 2 storageType: Durable storage: - accessModes: - - ReadWriteOnce + storageClassName: "standard" resources: requests: storage: 1Gi - deletionPolicy: WipeOut + accessModes: + - ReadWriteOnce + deletionPolicy: Delete ``` Create the above `Redis` CR, ```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples/sample-redis.yaml -redis.kubedb.com/sample-redis created +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples/redis-cluster.yaml +redis.kubedb.com/redis-cluster created ``` KubeDB will deploy a `Redis` database according to the above specification. It will also create the necessary `Secrets` and `Services` to access the database. @@ -94,26 +96,27 @@ KubeDB will deploy a `Redis` database according to the above specification. It w Let's check if the database is ready to use, ```bash -$ kubectl get rd -n demo sample-redis -NAME VERSION STATUS AGE -sample-redis 16.1 Ready 5m1s +$ kubectl get rd -n demo redis-cluster +NAME VERSION STATUS AGE +redis-cluster 7.4.0 Ready 5m2s ``` The database is `Ready`. Verify that KubeDB has created a `Secret` and a `Service` for this database using the following commands, ```bash $ kubectl get secret -n demo -NAME TYPE DATA AGE -sample-redis-auth kubernetes.io/basic-auth 2 5m20s +NAME TYPE DATA AGE +redis-cluster-auth kubernetes.io/basic-auth 2 6m16s +redis-cluster-config Opaque 1 6m16s -$ kubectl get service -n demo -l=app.kubernetes.io/instance=sample-redis -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -sample-redis ClusterIP 10.96.23.177 5432/TCP,2379/TCP 5m55s -sample-redis-pods ClusterIP None 5432/TCP,2380/TCP,2379/TCP 5m55s -sample-redis-standby ClusterIP 10.96.26.118 5432/TCP 5m55s + +$ kubectl get service -n demo -l=app.kubernetes.io/instance=redis-cluster +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +redis-cluster ClusterIP 10.96.185.242 6379/TCP 7m25s +redis-cluster-pods ClusterIP None 6379/TCP 7m25s ``` -Here, we have to use service `sample-redis` and secret `sample-redis-auth` to connect with the database. `KubeDB` creates an [AppBinding](/docs/guides/redis/concepts/appbinding.md) CR that holds the necessary information to connect with the database. +Here, we have to use service `redis-cluster` and secret `redis-cluster-auth` to connect with the database. `KubeDB` creates an [AppBinding](/docs/guides/redis/concepts/appbinding.md) CR that holds the necessary information to connect with the database. **Verify AppBinding:** @@ -122,14 +125,14 @@ Verify that the `AppBinding` has been created successfully using the following c ```bash $ kubectl get appbindings -n demo -NAME TYPE VERSION AGE -sample-redis kubedb.com/redis 16.1 9m30s +NAME TYPE VERSION AGE +redis-cluster kubedb.com/redis 7.4.0 7m14s ``` Let's check the YAML of the above `AppBinding`, ```bash -$ kubectl get appbindings -n demo sample-redis -o yaml +$ kubectl get appbindings -n demo redis-cluster -o yaml ``` ```yaml @@ -138,51 +141,49 @@ kind: AppBinding metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"kubedb.com/v1","kind":"Redis","metadata":{"annotations":{},"name":"sample-redis","namespace":"demo"},"spec":{"deletionPolicy":"DoNotTerminate","replicas":3,"standbyMode":"Hot","storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}}},"storageType":"Durable","streamingMode":"Synchronous","version":"16.1"}} - creationTimestamp: "2024-09-04T10:07:04Z" + {"apiVersion":"kubedb.com/v1","kind":"Redis","metadata":{"annotations":{},"name":"redis-cluster","namespace":"demo"},"spec":{"cluster":{"replicas":2,"shards":3},"deletionPolicy":"Delete","mode":"Cluster","storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}},"storageClassName":"standard"},"storageType":"Durable","version":"7.4.0"}} + creationTimestamp: "2024-09-18T05:29:09Z" generation: 1 labels: app.kubernetes.io/component: database - app.kubernetes.io/instance: sample-redis + app.kubernetes.io/instance: redis-cluster app.kubernetes.io/managed-by: kubedb.com app.kubernetes.io/name: redises.kubedb.com - name: sample-redis + name: redis-cluster namespace: demo ownerReferences: - - apiVersion: kubedb.com/v1 - blockOwnerDeletion: true - controller: true - kind: Redis - name: sample-redis - uid: 0810a96c-a2b6-4e8a-a70a-51753660450c - resourceVersion: "245972" - uid: 73bdba85-c932-464b-93a8-7f1ba8dfff1b + - apiVersion: kubedb.com/v1 + blockOwnerDeletion: true + controller: true + kind: Redis + name: redis-cluster + uid: 089eff8d-81ec-4933-8121-87d5e21d137d + resourceVersion: "1139825" + uid: d985a52a-00ef-4857-b597-0ccec62cf838 spec: appRef: apiGroup: kubedb.com kind: Redis - name: sample-redis + name: redis-cluster namespace: demo clientConfig: service: - name: sample-redis - path: / - port: 5432 - query: sslmode=disable - scheme: redisql + name: redis-cluster + port: 6379 + scheme: redis parameters: - apiVersion: appcatalog.appscode.com/v1alpha1 - kind: StashAddon + apiVersion: config.kubedb.com/v1alpha1 + kind: RedisConfiguration stash: addon: backupTask: - name: redis-backup-16.1 + name: redis-backup-7.0.5 restoreTask: - name: redis-restore-16.1 + name: redis-restore-7.0.5 secret: - name: sample-redis-auth + name: redis-cluster-auth type: kubedb.com/redis - version: "16.1" + version: 7.4.0 ``` KubeStash uses the `AppBinding` CR to connect with the target database. It requires the following two fields to set in AppBinding's `.spec` section. @@ -199,88 +200,53 @@ Here, Now, we are going to exec into one of the database pod and create some sample data. At first, find out the database `Pod` using the following command, ```bash -$ kubectl get pods -n demo --selector="app.kubernetes.io/instance=sample-redis" -NAME READY STATUS RESTARTS AGE -sample-redis-0 2/2 Running 0 16m -sample-redis-1 2/2 Running 0 13m -sample-redis-2 2/2 Running 0 13m +$ kubectl get pods -n demo --selector="app.kubernetes.io/instance=redis-cluster" +NAME READY STATUS RESTARTS AGE +redis-cluster-shard0-0 1/1 Running 0 11m +redis-cluster-shard0-1 1/1 Running 0 11m +redis-cluster-shard1-0 1/1 Running 0 11m +redis-cluster-shard1-1 1/1 Running 0 11m +redis-cluster-shard2-0 1/1 Running 0 10m +redis-cluster-shard2-1 1/1 Running 0 10m ``` -Now, let’s exec into the pod and create a table, +#### Connection Information + +- Hostname/address: you can use any of these + - Service: `redis-cluster.demo` + - Pod IP: (`$ kubectl get pod -n demo -l app.kubernetes.io/name=redises.kubedb.com -o yaml | grep podIP`) +- Port: `6379` +- Username: Run following command to get _username_, + + ```bash + $ kubectl get secrets -n demo redis-cluster-auth -o jsonpath='{.data.\username}' | base64 -d + default + ``` + +- Password: Run the following command to get _password_, + + ```bash + $ kubectl get secrets -n demo redis-cluster-auth -o jsonpath='{.data.\password}' | base64 -d + 8UnSPM;(~cXWWs60 + ``` +Now, let’s exec into the pod and insert some data, ```bash -$ kubectl exec -it -n demo sample-redis-0 -- sh - -# login as "redis" superuser. -/ $ psql -U redis -psql (16.1) -Type "help" for help. - -# list available databases -redis=# \l - List of databases - Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges ----------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- - kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis - template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis -(4 rows) - -# create a database named "demo" -redis=# create database demo; -CREATE DATABASE - -# verify that the "demo" database has been created -redis=# \l - List of databases - Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges ----------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- - demo | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis - template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis -(5 rows) - -# connect to the "demo" database -redis=# \c demo -You are now connected to database "demo" as user "redis". - -# create a sample table -demo=# CREATE TABLE COMPANY( NAME TEXT NOT NULL, EMPLOYEE INT NOT NULL); -CREATE TABLE - -# verify that the table has been created -demo=# \d - List of relations - Schema | Name | Type | Owner ---------+---------+-------+---------- - public | company | table | redis -(1 row) - -# insert multiple rows of data into the table -demo=# INSERT INTO COMPANY (NAME, EMPLOYEE) VALUES ('TechCorp', 100), ('InnovateInc', 150), ('AlphaTech', 200); -INSERT 0 3 - -# verify the data insertion -demo=# SELECT * FROM COMPANY; - name | employee --------------+---------- - TechCorp | 100 - InnovateInc | 150 - AlphaTech | 200 -(3 rows) - -# quit from the database -demo=# \q - -# exit from the pod -/ $ exit +$ kubectl exec -it -n demo redis-cluster-shard0-0 -c redis -- bash +redis@redis-cluster-shard0-0:/data$ redis-cli -c +127.0.0.1:6379> auth default 8UnSPM;(~cXWWs60 +OK +127.0.0.1:6379> set db redis +OK +127.0.0.1:6379> set name neaj +-> Redirected to slot [5798] located at 10.244.0.48:6379 +OK +10.244.0.48:6379> set key value +-> Redirected to slot [12539] located at 10.244.0.52:6379 +OK +10.244.0.52:6379> exit +redis@redis-cluster-shard0-0:/data$ exit +exit ``` Now, we are ready to backup the database. @@ -316,14 +282,13 @@ spec: storage: provider: gcs gcs: - bucket: kubestash-qa + bucket: neaj-demo prefix: demo secretName: gcs-secret usagePolicy: allowedNamespaces: from: All - default: true - deletionPolicy: WipeOut + deletionPolicy: Delete ``` Let's create the BackupStorage we have shown above, @@ -368,7 +333,7 @@ retentionpolicy.storage.kubestash.com/demo-retention created ### Backup -We have to create a `BackupConfiguration` targeting respective `sample-redis` Redis database. Then, KubeStash will create a `CronJob` for each session to take periodic backup of that database. +We have to create a `BackupConfiguration` targeting respective `redis-cluster` Redis database. Then, KubeStash will create a `CronJob` for each session to take periodic backup of that database. At first, we need to create a secret with a Restic password for backup data encryption. @@ -379,24 +344,24 @@ Let's create a secret called `encrypt-secret` with the Restic password, ```bash $ echo -n 'changeit' > RESTIC_PASSWORD $ kubectl create secret generic -n demo encrypt-secret \ - --from-file=./RESTIC_PASSWORD \ + --from-file=./RESTIC_PASSWORD secret "encrypt-secret" created ``` -Below is the YAML for `BackupConfiguration` CR to backup the `sample-redis` database that we have deployed earlier, +Below is the YAML for `BackupConfiguration` CR to backup the `redis-cluster` database that we have deployed earlier, ```yaml apiVersion: core.kubestash.com/v1alpha1 kind: BackupConfiguration metadata: - name: sample-redis-backup + name: redis-cluster-backup namespace: demo spec: target: apiGroup: kubedb.com kind: Redis namespace: demo - name: sample-redis + name: redis-cluster backends: - name: gcs-backend storageRef: @@ -425,13 +390,13 @@ spec: ``` - `.spec.sessions[*].schedule` specifies that we want to backup the database at `5 minutes` interval. -- `.spec.target` refers to the targeted `sample-redis` Redis database that we created earlier. +- `.spec.target` refers to the targeted `redis-cluster` Redis database that we created earlier. Let's create the `BackupConfiguration` CR that we have shown above, ```bash $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/kubestash/logical/examples/backupconfiguration.yaml -backupconfiguration.core.kubestash.com/sample-redis-backup created +backupconfiguration.core.kubestash.com/redis-cluster-backup created ``` **Verify Backup Setup Successful** @@ -440,16 +405,16 @@ If everything goes well, the phase of the `BackupConfiguration` should be `Ready ```bash $ kubectl get backupconfiguration -n demo -NAME PHASE PAUSED AGE -sample-redis-backup Ready 2m50s +NAME PHASE PAUSED AGE +redis-cluster-backup Ready 71s ``` Additionally, we can verify that the `Repository` specified in the `BackupConfiguration` has been created using the following command, ```bash $ kubectl get repo -n demo -NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE -gcs-redis-repo 0 0 B Ready 3m +NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE +gcs-redis-repo 0 0 B Ready 2m30s ``` KubeStash keeps the backup for `Repository` YAMLs. If we navigate to the GCS bucket, we will see the `Repository` YAML stored in the `demo/redis` directory. @@ -462,8 +427,8 @@ Verify that the `CronJob` has been created using the following command, ```bash $ kubectl get cronjob -n demo -NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE -trigger-sample-redis-backup-frequent-backup */5 * * * * 0 2m45s 3m25s +NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE +trigger-redis-cluster-backup-frequent-backup */5 * * * * False 0 45s 2m38s ``` **Verify BackupSession:** @@ -472,28 +437,28 @@ KubeStash triggers an instant backup as soon as the `BackupConfiguration` is rea ```bash $ kubectl get backupsession -n demo -w -NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE -sample-redis-backup-frequent-backup-1725449400 BackupConfiguration sample-redis-backup Succeeded 7m22s +NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE +redis-cluster-backup-frequent-backup-1726651666 BackupConfiguration redis-cluster-backup Succeeded 2m25s 2m56s ``` 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 `sample-redis-backup` has been updated by the following command, +Once a backup is complete, KubeStash will update the respective `Repository` CR to reflect the backup. Check that the repository `gcs-redis-repo` has been updated by the following command, ```bash -$ kubectl get repository -n demo sample-redis-backup -NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE -sample-redis-backup true 1 806 B Ready 8m27s 9m18s +$ kubectl get repository -n demo gcs-redis-repo +NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE +gcs-redis-repo true 1 416 B Ready 4m40s 5m ``` At this moment we have one `Snapshot`. Run the following command to check the respective `Snapshot` which represents the state of a backup run for an application. ```bash $ kubectl get snapshots -n demo -l=kubestash.com/repo-name=gcs-redis-repo -NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE AGE -gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 gcs-redis-repo frequent-backup 2024-01-23T13:10:54Z Delete Succeeded 16h +NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE AGE +gcs-redis-repo-redis-cluster-backup-frequent-backup-1726651666 gcs-redis-repo frequent-backup 2024-09-18T09:28:07Z Delete Succeeded 5m14s ``` > Note: KubeStash creates a `Snapshot` with the following labels: @@ -507,83 +472,83 @@ gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 gcs-redis-repo If we check the YAML of the `Snapshot`, we can find the information about the backed up components of the Database. ```bash -$ kubectl get snapshots -n demo gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 -oyaml +$ kubectl get snapshots -n demo gcs-redis-repo-redis-cluster-backup-frequent-backup-1726651666 -oyaml ``` ```yaml apiVersion: storage.kubestash.com/v1alpha1 kind: Snapshot metadata: - creationTimestamp: "2024-09-04T11:30:00Z" + creationTimestamp: "2024-09-18T09:28:07Z" finalizers: - - kubestash.com/cleanup + - kubestash.com/cleanup generation: 1 labels: + kubedb.com/db-version: 7.4.0 kubestash.com/app-ref-kind: Redis - kubestash.com/app-ref-name: sample-redis + kubestash.com/app-ref-name: redis-cluster kubestash.com/app-ref-namespace: demo kubestash.com/repo-name: gcs-redis-repo - annotations: - kubedb.com/db-version: "16.1" - name: gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 + name: gcs-redis-repo-redis-cluster-backup-frequent-backup-1726651666 namespace: demo ownerReferences: - - apiVersion: storage.kubestash.com/v1alpha1 - blockOwnerDeletion: true - controller: true - kind: Repository - name: gcs-redis-repo - uid: 1009bd4a-b211-49f1-a64c-3c979c699a81 - resourceVersion: "253523" - uid: c6757c49-e13b-4a36-9f7d-64eae350423f + - apiVersion: storage.kubestash.com/v1alpha1 + blockOwnerDeletion: true + controller: true + kind: Repository + name: gcs-redis-repo + uid: 6b4439c8-5c79-443d-af14-a8efd47eb43c + resourceVersion: "1161141" + uid: 04110ce9-a015-4d50-a66f-dbc685a4fdff spec: appRef: apiGroup: kubedb.com kind: Redis - name: sample-redis + name: redis-cluster namespace: demo - backupSession: sample-redis-backup-frequent-backup-1725449400 + backupSession: redis-cluster-backup-frequent-backup-1726651666 deletionPolicy: Delete repository: gcs-redis-repo session: frequent-backup - snapshotID: 01J6YCRWEWAKACMGZYR2R7YJ5C + snapshotID: 01J827BRDW8PT3TS9T8QR6KS2S type: FullBackup version: v1 status: components: dump: driver: Restic - duration: 11.526138009s + duration: 30.177171779s integrity: true path: repository/v1/frequent-backup/dump phase: Succeeded resticStats: - - hostPath: dumpfile.sql - id: 008eb87193e7db112e9ad8f42c9302c851a1fbacb7165a5cb3aa2d27dd210764 - size: 3.345 KiB - uploaded: 299 B - size: 2.202 KiB + - hostPath: dumpfile.resp + id: dc0c7e16ffea238d80f2f0e23b94d5eee1a598a4b5b9bc3f9edc2e9059e1d9e2 + size: 381 B + uploaded: 680 B + size: 416 B conditions: - - lastTransitionTime: "2024-09-04T11:30:00Z" - message: Recent snapshot list updated successfully - reason: SuccessfullyUpdatedRecentSnapshotList - status: "True" - type: RecentSnapshotListUpdated - - lastTransitionTime: "2024-09-04T11:30:32Z" - message: Metadata uploaded to backend successfully - reason: SuccessfullyUploadedSnapshotMetadata - status: "True" - type: SnapshotMetadataUploaded + - lastTransitionTime: "2024-09-18T09:28:07Z" + message: Recent snapshot list updated successfully + reason: SuccessfullyUpdatedRecentSnapshotList + status: "True" + type: RecentSnapshotListUpdated + - lastTransitionTime: "2024-09-18T09:30:29Z" + message: Metadata uploaded to backend successfully + reason: SuccessfullyUploadedSnapshotMetadata + status: "True" + type: SnapshotMetadataUploaded integrity: true phase: Succeeded - size: 2.201 KiB - snapshotTime: "2024-09-04T11:30:00Z" + size: 416 B + snapshotTime: "2024-09-18T09:28:07Z" totalComponents: 1 + ``` -> KubeStash uses a logical backup approach to take backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. Do the same for auto-backup, application backup and customize backup if necessary. +> KubeStash uses [redis-dump-go](https://github.com/yannh/redis-dump-go) to perform backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. -Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/popstgres/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/redis/snapshots` directory. +Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/redis/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/redis/snapshots` directory. > Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. @@ -591,7 +556,7 @@ Now, if we navigate to the GCS bucket, we will see the backed up data stored in 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. -Now, we have to deploy the restored database similarly as we have deployed the original `sample-redis` database. However, this time there will be the following differences: +Now, we have to deploy the restored database similarly as we have deployed the original `redis-cluster` database. However, this time there will be the following differences: - We are going to specify `.spec.init.waitForInitialRestore` field that tells KubeDB to wait for first restore to complete before marking this database is ready to use. @@ -601,58 +566,60 @@ Below is the YAML for `Redis` CR we are going deploy to initialize from backup, apiVersion: kubedb.com/v1 kind: Redis metadata: - name: restored-redis + name: restored-redis-cluster namespace: demo spec: init: waitForInitialRestore: true - version: "16.1" - replicas: 3 - standbyMode: Hot - streamingMode: Synchronous + version: 7.4.0 + mode: Cluster + cluster: + shards: 3 + replicas: 2 storageType: Durable storage: - accessModes: - - ReadWriteOnce + storageClassName: "standard" resources: requests: storage: 1Gi - deletionPolicy: WipeOut + accessModes: + - ReadWriteOnce + deletionPolicy: Delete ``` Let's create the above database, ```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples/restored-redis.yaml -redis.kubedb.com/restore-redis created +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/logical/examples/restored-redis-cluster.yaml +redis.kubedb.com/restore-redis-cluster created ``` If you check the database status, you will see it is stuck in **`Provisioning`** state. ```bash -$ kubectl get redis -n demo restored-redis -NAME VERSION STATUS AGE -restored-redis 8.2.0 Provisioning 61s +$ kubectl get redis -n demo restored-redis-cluster +NAME VERSION STATUS AGE +restored-redis-cluster 7.4.0 Provisioning 2m35s ``` #### Create RestoreSession: Now, we need to create a `RestoreSession` CR pointing to targeted `Redis` database. -Below, is the contents of YAML file of the `RestoreSession` object that we are going to create to restore backed up data into the newly created `Redis` database named `restored-redis`. +Below, is the contents of YAML file of the `RestoreSession` object that we are going to create to restore backed up data into the newly created `Redis` database named `restored-redis-cluster`. ```yaml apiVersion: core.kubestash.com/v1alpha1 kind: RestoreSession metadata: - name: sample-redis-restore + name: redis-cluster-restore namespace: demo spec: target: apiGroup: kubedb.com kind: Redis namespace: demo - name: restored-redis + name: restored-redis-cluster dataSource: repository: gcs-redis-repo snapshot: latest @@ -667,7 +634,7 @@ spec: Here, -- `.spec.target` refers to the newly created `restored-redis` Redis object to where we want to restore backup data. +- `.spec.target` refers to the newly created `restored-redis-cluster` Redis object to where we want to restore backup data. - `.spec.dataSource.repository` specifies the Repository object that holds the backed up data. - `.spec.dataSource.snapshot` specifies to restore from latest `Snapshot`. @@ -675,106 +642,78 @@ 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/redis/backup/kubestash/logical/examples/restoresession.yaml -restoresession.core.kubestash.com/sample-redis-restore created +restoresession.core.kubestash.com/redis-cluster-restore created ``` Once, you have created the `RestoreSession` object, KubeStash will create restore Job. Run the following command to watch the phase of the `RestoreSession` object, ```bash $ watch kubectl get restoresession -n demo -Every 2.0s: kubectl get restores... AppsCode-PC-03: Wed Aug 21 10:44:05 2024 -NAME REPOSITORY FAILURE-POLICY PHASE DURATION AGE -sample-redis-restore gcs-redis-repo Succeeded 7s 116s +Every 2.0s: kubectl get restoresession -n demo neaj-desktop: Wed Sep 18 15:53:42 2024 +NAME REPOSITORY FAILURE-POLICY PHASE DURATION AGE +redis-cluster-restore gcs-redis-repo Succeeded 1m26s 4m49s ``` The `Succeeded` phase means that the restore process has been completed successfully. #### 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. +In this section, we are going to verify whether the desired data has been restored successfully. We are going to connect to the database and check whether the data we inserted earlier in the original database are restored. At first, check if the database has gone into **`Ready`** state by the following command, ```bash -$ kubectl get redis -n demo restored-redis -NAME VERSION STATUS AGE -restored-redis 16.1 Ready 6m31s +$ kubectl get redis -n demo restored-redis-cluster +NAME VERSION STATUS AGE +restored-redis-cluster 7.4.0 Ready 8m42s ``` -Now, find out the database `Pod` by the following command, +Now, find out the database `Pods` by the following command, ```bash -$ kubectl get pods -n demo --selector="app.kubernetes.io/instance=restored-redis" -NAME READY STATUS RESTARTS AGE -restored-redis-0 2/2 Running 0 6m7s -restored-redis-1 2/2 Running 0 6m1s -restored-redis-2 2/2 Running 0 5m55s +$ kubectl get pods -n demo --selector="app.kubernetes.io/instance=restored-redis-cluster" +NAME READY STATUS RESTARTS AGE +restored-redis-cluster-shard0-0 1/1 Running 0 5m53s +restored-redis-cluster-shard0-1 1/1 Running 0 5m47s +restored-redis-cluster-shard1-0 1/1 Running 0 5m31s +restored-redis-cluster-shard1-1 1/1 Running 0 5m24s +restored-redis-cluster-shard2-0 1/1 Running 0 5m9s +restored-redis-cluster-shard2-1 1/1 Running 0 5m2s ``` Now, lets exec one of the `Pod` and verify restored data. ```bash -$ kubectl exec -it -n demo restored-redis-0 -- /bin/sh -# login as "redis" superuser. -/ # psql -U redis -psql (11.11) -Type "help" for help. - -# verify that the "demo" database has been restored -redis=# \l - List of databases - Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges ----------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- - demo | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis - template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis -(5 rows) - -# connect to the "demo" database -redis=# \c demo -You are now connected to database "demo" as user "redis". - -# verify that the sample table has been restored -demo=# \d - List of relations - Schema | Name | Type | Owner ---------+---------+-------+---------- - public | company | table | redis -(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 - -# exit from the pod -/ # exit -``` - -So, from the above output, we can see the `demo` database we had created in the original database `sample-redis` has been restored in the `restored-redis` database. +$ kubectl exec -it -n demo restored-redis-cluster-shard0-0 -c redis -- bash +redis@restored-redis-cluster-shard0-0:/data$ redis-cli -c +127.0.0.1:6379> auth default lm~;mv7H~eahvZCc +OK +127.0.0.1:6379> get db +"redis" +127.0.0.1:6379> get name +-> Redirected to slot [5798] located at 10.244.0.66:6379 +"neaj" +10.244.0.66:6379> get key +-> Redirected to slot [12539] located at 10.244.0.70:6379 +"value" +10.244.0.70:6379> exit +redis@restored-redis-cluster-shard0-0:/data$ exit +exit +``` + +So, from the above output, we can see the `redis-cluster` database we had created earlier has been restored in the `restored-redis-cluster` database successfully. ## Cleanup To cleanup the Kubernetes resources created by this tutorial, run: ```bash -kubectl delete backupconfigurations.core.kubestash.com -n demo sample-redis-backup -kubectl delete restoresessions.core.kubestash.com -n demo restore-sample-redis +kubectl delete backupconfigurations.core.kubestash.com -n demo redis-cluster-backup +kubectl delete restoresessions.core.kubestash.com -n demo redis-cluster-restore 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 redis -n demo restored-redis -kubectl delete redis -n demo sample-redis +kubectl delete redis -n demo restored-redis-cluster +kubectl delete redis -n demo redis-cluster ``` \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/overview/index.md b/docs/guides/redis/backup/kubestash/overview/index.md index e40e1a39d4..319f7f911d 100644 --- a/docs/guides/redis/backup/kubestash/overview/index.md +++ b/docs/guides/redis/backup/kubestash/overview/index.md @@ -38,9 +38,9 @@ The backup process consists of the following steps: 2. Then, he creates a `BackupStorage` custom resource that specifies the backend information, along with the `Secret` containing the credentials needed to access the backend. -3. KubeStash operator watches for `BackupStorage` custom resources. When it finds a `BackupStorage` object, it initializes the `BackupStorage` by uploading the `metadata.yaml` file into the target storage. +3. KubeStash operator watches for `BackupStorage` custom resources. When it finds a `BackupStorage` object, it initializes the `BackupStorage` by uploading the `metadata.yaml` file to the specified backend. -4. Then, he creates a `BackupConfiguration` custom resource that specifies the targeted the KubeDB managed `Redis` database, the `Addon` info with a specified task, etc. It also provides information about one or more repositories, each indicating a path and a `BackupStorage` for storing the backed-up data. +4. Next, he creates a `BackupConfiguration` custom resource that specifies the target database, addon information (including backup tasks), backup schedules, storage backends for storing the backup data, and other additional settings. 5. KubeStash operator watches for `BackupConfiguration` objects. @@ -50,7 +50,7 @@ The backup process consists of the following steps: 8. Then, it creates a `CronJob` for each session with the schedule specified in `BackupConfiguration` to trigger backup periodically. -9. KubeStash operator triggers an instant backup as soon as the `BackupConfiguration` is ready. After that, backups are triggered by the `CronJob` according to the specified schedule. +9. KubeStash operator triggers an instant backup as soon as the `BackupConfiguration` is ready. Backups are otherwise triggered by the `CronJob` based on the specified schedule. 10. KubeStash operator watches for `BackupSession` custom resources. @@ -60,7 +60,7 @@ The backup process consists of the following steps: 13. Then, it creates the `Job` to backup the targeted `Redis` database. -14. The backup `Job` reads necessary information (e.g. auth secret, port) to connect with the database from the `AppBinding` crd. It also reads backend information and access credentials from BackupStorage crd, Storage Secret and Repository path respectively. +14. The backup `Job` reads necessary information (e.g. auth secret, port) to connect with the database from the `AppBinding` CR. It also reads backend information and access credentials from `BackupStorage` CR, Storage Secret and `Repository` path respectively. 15. Then, the `Job` dumps the targeted `Redis` 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. @@ -79,7 +79,7 @@ The restore process consists of the following steps: 1. At first, a user creates a `Redis` database where the data will be restored or the user can use the same `Redis` database. -2. Then, he creates a `RestoreSession` custom resource that specifies the target `Redis` database where the backed-up data will be restored. the `Repository` object that points to a `BackupStorage` that holds backend information, and the target `Snapshot`, which will be restored. It also specifies the `Addon` info with task to use to restore. +2. Then, he creates a `RestoreSession` custom resource that specifies the target database where the backed-up data will be restored, addon information (including restore tasks), the target snapshot to be restored, the Repository containing that snapshot, and other additional settings. 3. KubeStash operator watches for `RestoreSession` custom resources. @@ -87,7 +87,7 @@ The restore process consists of the following steps: 5. Then, it creates the `Job` to restore the target. -6. 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. The `Job` reads necessary information to connect with the database from respective `AppBinding` CR. It also reads backend information and access credentials from `Repository` CR and storage `Secret` respectively. 7. 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. From 226035df91d8bf2ea598e4612c272a8a16bd8f85 Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Wed, 18 Sep 2024 19:15:50 +0600 Subject: [PATCH 05/11] add auto backup complete doc Signed-off-by: Neaj Morshad --- .../examples/backupstorage.yaml | 2 +- .../kubestash/application-level/index.md | 51 +++-- .../auto-backup/examples/backupstorage.yaml | 4 +- .../examples/customize-backupblueprint.yaml | 7 +- .../examples/default-backupblueprint.yaml | 2 - ...ostgres-2.yaml => redis-standalone-2.yaml} | 13 +- ...le-postgres.yaml => redis-standalone.yaml} | 10 +- .../backup/kubestash/auto-backup/index.md | 212 ++++++++---------- ...repository.yaml => multiple-backends.yaml} | 11 +- ...kupstorage.yaml => gcs-backupstorage.yaml} | 2 +- .../common/s3-backupstorage.yaml | 19 ++ .../backup/kubestash/customization/index.md | 23 +- .../customization/restore/passing-args.yaml | 23 ++ 13 files changed, 202 insertions(+), 177 deletions(-) rename docs/guides/redis/backup/kubestash/auto-backup/examples/{sample-postgres-2.yaml => redis-standalone-2.yaml} (67%) rename docs/guides/redis/backup/kubestash/auto-backup/examples/{sample-postgres.yaml => redis-standalone.yaml} (71%) rename docs/guides/redis/backup/kubestash/customization/backup/{multiple-repository.yaml => multiple-backends.yaml} (80%) rename docs/guides/redis/backup/kubestash/customization/common/{backupstorage.yaml => gcs-backupstorage.yaml} (94%) create mode 100644 docs/guides/redis/backup/kubestash/customization/common/s3-backupstorage.yaml create mode 100644 docs/guides/redis/backup/kubestash/customization/restore/passing-args.yaml diff --git a/docs/guides/redis/backup/kubestash/application-level/examples/backupstorage.yaml b/docs/guides/redis/backup/kubestash/application-level/examples/backupstorage.yaml index 0461b26762..6ab3df02ac 100644 --- a/docs/guides/redis/backup/kubestash/application-level/examples/backupstorage.yaml +++ b/docs/guides/redis/backup/kubestash/application-level/examples/backupstorage.yaml @@ -14,4 +14,4 @@ spec: allowedNamespaces: from: All default: true - deletionPolicy: WipeOut \ No newline at end of file + deletionPolicy: Delete \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/application-level/index.md b/docs/guides/redis/backup/kubestash/application-level/index.md index 0ec66e51d3..8be337f2d0 100644 --- a/docs/guides/redis/backup/kubestash/application-level/index.md +++ b/docs/guides/redis/backup/kubestash/application-level/index.md @@ -1,5 +1,5 @@ --- -title: Application Level Backup & Restore Redis | KubeStash +title: Application Level Backup & Restore PostgreSQL | KubeStash description: Application Level Backup and Restore using KubeStash menu: docs_{{ .version }}: @@ -11,11 +11,11 @@ menu_name: docs_{{ .version }} section_menu_id: guides --- -# Application Level Backup and Restore Redis database using KubeStash +# Application Level Backup and Restore PostgreSQL database using KubeStash -KubeStash offers application-level backup and restore functionality for `Redis` databases. It captures both manifest and data backups of any `Redis` database in a single snapshot. During the restore process, KubeStash first applies the `Redis` manifest to the cluster and then restores the data into it. +KubeStash offers application-level backup and restore functionality for `PostgreSQL` databases. It captures both manifest and data backups of any `PostgreSQL` database in a single snapshot. During the restore process, KubeStash first applies the `PostgreSQL` manifest to the cluster and then restores the data into it. -This guide will give you an overview how you can take application-level backup and restore your `Redis` databases using `Kubestash`. +This guide will give you an overview how you can take application-level backup and restore your `PostgreSQL` databases using `Kubestash`. ## Before You Begin @@ -23,7 +23,7 @@ This guide will give you an overview how you can take application-level backup a - Install `KubeDB` in your cluster following the steps [here](/docs/setup/README.md). - Install `KubeStash` in your cluster following the steps [here](https://kubestash.com/docs/latest/setup/install/kubestash). - Install KubeStash `kubectl` plugin following the steps [here](https://kubestash.com/docs/latest/setup/install/kubectl-plugin/). -- If you are not familiar with how KubeStash backup and restore Redis databases, please check the following guide [here](/docs/guides/redis/backup/kubestash/overview/index.md). +- If you are not familiar with how KubeStash backup and restore PostgreSQL databases, please check the following guide [here](/docs/guides/redis/backup/kubestash/overview/index.md). You should be familiar with the following `KubeStash` concepts: @@ -44,19 +44,19 @@ namespace/demo created > **Note:** YAML files used in this tutorial are stored in [docs/guides/redis/backup/kubestash/application-level/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/application-level/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. -## Backup Redis +## Backup PostgreSQL -KubeStash supports backups for `Redis` instances across different configurations, including Standalone and HA Cluster setups. In this demonstration, we'll focus on a `Redis` database using HA cluster configuration. The backup and restore process is similar for Standalone configuration. +KubeStash supports backups for `PostgreSQL` instances across different configurations, including Standalone and HA Cluster setups. In this demonstration, we'll focus on a `PostgreSQL` database using HA cluster configuration. The backup and restore process is similar for Standalone configuration. -This section will demonstrate how to take application-level backup of a `Redis` database. Here, we are going to deploy a `Redis` database using KubeDB. Then, we are going to back up the database at the application level to a `GCS` bucket. Finally, we will restore the entire `Redis` database. +This section will demonstrate how to take application-level backup of a `PostgreSQL` database. Here, we are going to deploy a `PostgreSQL` database using KubeDB. Then, we are going to back up the database at the application level to a `GCS` bucket. Finally, we will restore the entire `PostgreSQL` database. -### Deploy Sample Redis Database +### Deploy Sample PostgreSQL Database -Let's deploy a sample `Redis` database and insert some data into it. +Let's deploy a sample `PostgreSQL` database and insert some data into it. -**Create Redis CR:** +**Create PostgreSQL CR:** -Below is the YAML of a sample `Redis` CR that we are going to create for this tutorial: +Below is the YAML of a sample `PostgreSQL` CR that we are going to create for this tutorial: ```yaml apiVersion: kubedb.com/v1 @@ -79,14 +79,14 @@ spec: deletionPolicy: WipeOut ``` -Create the above `Redis` CR, +Create the above `PostgreSQL` CR, ```bash $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/application-level/examples/sample-redis.yaml redis.kubedb.com/sample-redis created ``` -KubeDB will deploy a `Redis` database according to the above specification. It will also create the necessary `Secrets` and `Services` to access the database. +KubeDB will deploy a `PostgreSQL` 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, @@ -319,7 +319,7 @@ spec: allowedNamespaces: from: All default: true - deletionPolicy: WipeOut + deletionPolicy: Delete ``` Let's create the BackupStorage we have shown above, @@ -364,7 +364,7 @@ retentionpolicy.storage.kubestash.com/demo-retention created ### Backup -We have to create a `BackupConfiguration` targeting respective `sample-redis` Redis database. Then, KubeStash will create a `CronJob` for each session to take periodic backup of that database. +We have to create a `BackupConfiguration` targeting respective `sample-redis` PostgreSQL database. Then, KubeStash will create a `CronJob` for each session to take periodic backup of that database. At first, we need to create a secret with a Restic password for backup data encryption. @@ -424,9 +424,8 @@ spec: ``` - `.spec.sessions[*].schedule` specifies that we want to backup at `5 minutes` interval. -- `.spec.target` refers to the targeted `sample-redis` Redis database that we created earlier. -- `.spec.sessions[*].addon.tasks[*].name[*]` specifies that both the `manifest-backup` and `logical-backup` will be taken together. - +- `.spec.target` refers to the targeted `sample-redis` PostgreSQL database that we created earlier. +- `.spec.sessions[*].addon.tasks[*].name[*]` specifies that both the `manifest-backup` and `logical-backup` tasks will be executed. Let's create the `BackupConfiguration` CR that we have shown above, @@ -484,9 +483,9 @@ We can see from the above output that the backup session has succeeded. Now, we Once a backup is complete, KubeStash will update the respective `Repository` CR to reflect the backup. Check that the repository `sample-redis-backup` has been updated by the following command, ```bash -$ kubectl get repository -n demo sample-redis-backup +$ kubectl get repository -n demo gcs-redis-repo NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE -sample-redis-backup true 1 806 B Ready 8m27s 9m18s +gcs-redis-repo true 1 806 B Ready 8m27s 9m18s ``` At this moment we have one `Snapshot`. Run the following command to check the respective `Snapshot` which represents the state of a backup run for an application. @@ -594,9 +593,9 @@ status: totalComponents: 2 ``` -> KubeStash uses a logical backup approach to take backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. Do the same for auto-backup, application backup and customize backup if necessary. +> KubeStash uses `rd_dump` or `rd_dumpall` to perform backups of target `PostgreSQL` databases. Therefore, the component name for logical backups is set as `dump`. -> KubeStash set component name as `manifest` for the `manifest backup` of Redis databases. +> KubeStash set component name as `manifest` for the `manifest backup` of PostgreSQL databases. Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/popstgres/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/redis/snapshots` directory. @@ -671,9 +670,9 @@ restore-sample-redis gcs-redis-repo Succeeded 3s The `Succeeded` phase means that the restore process has been completed successfully. -#### Verify Restored Redis Manifest: +#### Verify Restored PostgreSQL Manifest: -In this section, we will verify whether the desired `Redis` database manifest has been successfully applied to the cluster. +In this section, we will verify whether the desired `PostgreSQL` database manifest has been successfully applied to the cluster. ```bash $ kubectl get redis -n dev @@ -681,7 +680,7 @@ NAME VERSION STATUS AGE sample-redis 16.1 Ready 9m46s ``` -The output confirms that the `Redis` database has been successfully created with the same configuration as it had at the time of backup. +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: diff --git a/docs/guides/redis/backup/kubestash/auto-backup/examples/backupstorage.yaml b/docs/guides/redis/backup/kubestash/auto-backup/examples/backupstorage.yaml index 0461b26762..d081682cfc 100644 --- a/docs/guides/redis/backup/kubestash/auto-backup/examples/backupstorage.yaml +++ b/docs/guides/redis/backup/kubestash/auto-backup/examples/backupstorage.yaml @@ -7,11 +7,11 @@ spec: storage: provider: gcs gcs: - bucket: kubestash-qa + bucket: neaj-demo prefix: demo secretName: gcs-secret usagePolicy: allowedNamespaces: from: All default: true - deletionPolicy: WipeOut \ No newline at end of file + deletionPolicy: Delete \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/auto-backup/examples/customize-backupblueprint.yaml b/docs/guides/redis/backup/kubestash/auto-backup/examples/customize-backupblueprint.yaml index 7a7634b3a5..5d9a4c8290 100644 --- a/docs/guides/redis/backup/kubestash/auto-backup/examples/customize-backupblueprint.yaml +++ b/docs/guides/redis/backup/kubestash/auto-backup/examples/customize-backupblueprint.yaml @@ -9,7 +9,6 @@ spec: from: All backupConfigurationTemplate: deletionPolicy: OnDelete - # ============== Blueprint for Backends of BackupConfiguration ================= backends: - name: gcs-backend storageRef: @@ -18,7 +17,6 @@ spec: retentionPolicy: name: demo-retention namespace: demo - # ============== Blueprint for Sessions of BackupConfiguration ================= sessions: - name: frequent-backup sessionHistoryLimit: 3 @@ -36,7 +34,4 @@ spec: addon: name: redis-addon tasks: - - name: logical-backup - params: - backupCmd: rd_dump - args: ${targetedDatabase} \ No newline at end of file + - name: logical-backup \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/auto-backup/examples/default-backupblueprint.yaml b/docs/guides/redis/backup/kubestash/auto-backup/examples/default-backupblueprint.yaml index 53745170e7..dce70c0e17 100644 --- a/docs/guides/redis/backup/kubestash/auto-backup/examples/default-backupblueprint.yaml +++ b/docs/guides/redis/backup/kubestash/auto-backup/examples/default-backupblueprint.yaml @@ -9,7 +9,6 @@ spec: from: All backupConfigurationTemplate: deletionPolicy: OnDelete - # ============== Blueprint for Backends of BackupConfiguration ================= backends: - name: gcs-backend storageRef: @@ -18,7 +17,6 @@ spec: retentionPolicy: name: demo-retention namespace: demo - # ============== Blueprint for Sessions of BackupConfiguration ================= sessions: - name: frequent-backup sessionHistoryLimit: 3 diff --git a/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres-2.yaml b/docs/guides/redis/backup/kubestash/auto-backup/examples/redis-standalone-2.yaml similarity index 67% rename from docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres-2.yaml rename to docs/guides/redis/backup/kubestash/auto-backup/examples/redis-standalone-2.yaml index 3c357e5386..614eae9980 100644 --- a/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres-2.yaml +++ b/docs/guides/redis/backup/kubestash/auto-backup/examples/redis-standalone-2.yaml @@ -1,7 +1,7 @@ apiVersion: kubedb.com/v1 kind: Redis metadata: - name: sample-redis-2 + name: redis-standalone-2 namespace: demo annotations: blueprint.kubestash.com/name: redis-customize-backup-blueprint @@ -9,18 +9,15 @@ metadata: variables.kubestash.com/schedule: "*/10 * * * *" variables.kubestash.com/repoName: customize-blueprint variables.kubestash.com/namespace: demo - variables.kubestash.com/targetName: sample-redis-2 - variables.kubestash.com/targetedDatabase: redis + variables.kubestash.com/targetName: redis-standalone-2 spec: - version: "16.1" - replicas: 3 - standbyMode: Hot - streamingMode: Synchronous + version: 7.4.0 storageType: Durable storage: + storageClassName: "standard" accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - deletionPolicy: WipeOut \ No newline at end of file + deletionPolicy: Delete \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres.yaml b/docs/guides/redis/backup/kubestash/auto-backup/examples/redis-standalone.yaml similarity index 71% rename from docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres.yaml rename to docs/guides/redis/backup/kubestash/auto-backup/examples/redis-standalone.yaml index 41f1987427..098dcb6616 100644 --- a/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-postgres.yaml +++ b/docs/guides/redis/backup/kubestash/auto-backup/examples/redis-standalone.yaml @@ -1,21 +1,19 @@ apiVersion: kubedb.com/v1 kind: Redis metadata: - name: sample-redis + name: redis-standalone namespace: demo annotations: blueprint.kubestash.com/name: redis-default-backup-blueprint blueprint.kubestash.com/namespace: demo spec: - version: "16.1" - replicas: 3 - standbyMode: Hot - streamingMode: Synchronous + version: 7.4.0 storageType: Durable storage: + storageClassName: "standard" accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - deletionPolicy: WipeOut \ No newline at end of file + deletionPolicy: Delete \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/auto-backup/index.md b/docs/guides/redis/backup/kubestash/auto-backup/index.md index 4031fc6dd6..ccedd756ad 100644 --- a/docs/guides/redis/backup/kubestash/auto-backup/index.md +++ b/docs/guides/redis/backup/kubestash/auto-backup/index.md @@ -75,14 +75,14 @@ spec: storage: provider: gcs gcs: - bucket: kubestash-qa + bucket: neaj-demo prefix: blueprint secretName: gcs-secret usagePolicy: allowedNamespaces: from: All default: true - deletionPolicy: WipeOut + deletionPolicy: Delete ``` Let's create the BackupStorage we have shown above, @@ -212,24 +212,22 @@ Below is the YAML of the `Redis` object that we are going to create, apiVersion: kubedb.com/v1 kind: Redis metadata: - name: sample-redis + name: redis-standalone namespace: demo annotations: blueprint.kubestash.com/name: redis-default-backup-blueprint blueprint.kubestash.com/namespace: demo spec: - version: "16.1" - replicas: 3 - standbyMode: Hot - streamingMode: Synchronous + version: 7.4.0 storageType: Durable storage: + storageClassName: "standard" accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - deletionPolicy: WipeOut + deletionPolicy: Delete ``` Here, @@ -240,8 +238,8 @@ Here, Let's create the `Redis` we have shown above, ```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-redis.yaml -redis.kubedb.com/sample-redis created +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/auto-backup/examples/redis-standalone.yaml +redis.kubedb.com/redis-standalone created ``` **Verify BackupConfiguration** @@ -251,20 +249,20 @@ If everything goes well, KubeStash should create a `BackupConfiguration` for our ```bash $ kubectl get backupconfiguration -n demo NAME PHASE PAUSED AGE -appbinding-sample-redis Ready 2m50m +appbinding-redis-standalone Ready 2m50m ``` Now, let’s check the YAML of the `BackupConfiguration`. ```bash -$ kubectl get backupconfiguration -n demo appbinding-sample-redis -o yaml +$ kubectl get backupconfiguration -n demo appbinding-redis-standalone -o yaml ``` ```yaml apiVersion: core.kubestash.com/v1alpha1 kind: BackupConfiguration metadata: - creationTimestamp: "2024-09-05T10:53:48Z" + creationTimestamp: "2024-09-18T12:15:07Z" finalizers: - kubestash.com/cleanup generation: 1 @@ -272,10 +270,10 @@ metadata: app.kubernetes.io/managed-by: kubestash.com kubestash.com/invoker-name: redis-default-backup-blueprint kubestash.com/invoker-namespace: demo - name: appbinding-sample-redis + name: appbinding-redis-standalone namespace: demo - resourceVersion: "298502" - uid: b6537c60-051f-4348-9ca4-c28f3880dbc1 + resourceVersion: "1176493" + uid: b7a37776-4a9b-4aaa-9e1d-15e7d6a83d56 spec: backends: - name: gcs-backend @@ -311,7 +309,7 @@ spec: target: apiGroup: kubedb.com kind: Redis - name: sample-redis + name: redis-standalone namespace: demo status: backends: @@ -328,7 +326,7 @@ status: name: gcs-storage namespace: demo conditions: - - lastTransitionTime: "2024-09-05T10:53:48Z" + - lastTransitionTime: "2024-09-18T12:15:07Z" message: Validation has been passed successfully. reason: ResourceValidationPassed status: "True" @@ -343,12 +341,12 @@ status: phase: Ready sessions: - conditions: - - lastTransitionTime: "2024-09-05T10:53:59Z" + - lastTransitionTime: "2024-09-18T12:15:37Z" message: Scheduler has been ensured successfully. reason: SchedulerEnsured status: "True" type: SchedulerEnsured - - lastTransitionTime: "2024-09-05T10:53:59Z" + - lastTransitionTime: "2024-09-18T12:15:38Z" message: Initial backup has been triggered successfully. reason: SuccessfullyTriggeredInitialBackup status: "True" @@ -357,8 +355,7 @@ status: targetFound: true ``` -Notice the `spec.backends`, `spec.sessions` and `spec.target` sections, KubeStash automatically resolved those info from the `BackupBluePrint` and created above `BackupConfiguration`. - +Notice the `spec.backends`, `spec.sessions` and `spec.target` sections, KubeStash automatically resolved those info from the `BackupBluePrint` and created the above `BackupConfiguration`. **Verify BackupSession:** @@ -366,20 +363,20 @@ KubeStash triggers an instant backup as soon as the `BackupConfiguration` is rea ```bash $ kubectl get backupsession -n demo -w -NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE -appbinding-sample-redis-frequent-backup-1725533628 BackupConfiguration appbinding-sample-redis Succeeded 23s 6m40s +NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE +appbinding-redis-standalone-frequent-backup-1726661707 BackupConfiguration appbinding-redis-standalone Succeeded 2m26s 9m56s ``` 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 `sample-redis-backup` has been updated by the following command, +Once a backup is complete, KubeStash will update the respective `Repository` CR to reflect the backup. Check that the repository `redis-standalone-backup` has been updated by the following command, ```bash $ kubectl get repository -n demo default-blueprint NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE -default-blueprint true 3 1.559 KiB Ready 80s 7m32s +default-blueprint true 1 1.111 KiB Ready 3m7s 13m ``` At this moment we have one `Snapshot`. Run the following command to check the respective `Snapshot` which represents the state of a backup run for an application. @@ -387,7 +384,7 @@ At this moment we have one `Snapshot`. Run the following command to check the re ```bash $ kubectl get snapshots -n demo -l=kubestash.com/repo-name=default-blueprint NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE AGE -default-blueprint-appbinding-samgres-frequent-backup-1725533628 default-blueprint frequent-backup 2024-09-05T10:53:59Z Delete Succeeded 7m48s + default-blueprint-appbinding-redlone-frequent-backup-1726661707 default-blueprint frequent-backup 2024-09-18T12:15:38Z Delete Succeeded 14m ``` > Note: KubeStash creates a `Snapshot` with the following labels: @@ -401,25 +398,24 @@ default-blueprint-appbinding-samgres-frequent-backup-1725533628 default-bluepr If we check the YAML of the `Snapshot`, we can find the information about the backed up components of the Database. ```bash -$ kubectl get snapshots -n demo default-blueprint-appbinding-samgres-frequent-backup-1725533628 -oyaml +$ kubectl get snapshots -n demo default-blueprint-appbinding-redlone-frequent-backup-1726661707 -oyaml ``` ```yaml apiVersion: storage.kubestash.com/v1alpha1 kind: Snapshot metadata: - creationTimestamp: "2024-09-05T10:53:59Z" + creationTimestamp: "2024-09-18T12:15:38Z" finalizers: - kubestash.com/cleanup generation: 1 labels: + kubedb.com/db-version: 7.4.0 kubestash.com/app-ref-kind: Redis - kubestash.com/app-ref-name: sample-redis + kubestash.com/app-ref-name: redis-standalone kubestash.com/app-ref-namespace: demo kubestash.com/repo-name: default-blueprint - annotations: - kubedb.com/db-version: "16.1" - name: default-blueprint-appbinding-samgres-frequent-backup-1725533628 + name: default-blueprint-appbinding-redlone-frequent-backup-1726661707 namespace: demo ownerReferences: - apiVersion: storage.kubestash.com/v1alpha1 @@ -427,61 +423,60 @@ metadata: controller: true kind: Repository name: default-blueprint - uid: 1125a82f-2bd8-4029-aae6-078ff5413383 - resourceVersion: "298559" - uid: c179b758-6ba4-4a32-81f1-fa41ba3dc527 + uid: 4d4085d1-f51d-48b2-95cb-f0e0503bb456 + resourceVersion: "1176748" + uid: 8b3e77f2-3771-497e-a92c-e43031f84031 spec: appRef: apiGroup: kubedb.com kind: Redis - name: sample-redis + name: redis-standalone namespace: demo - backupSession: appbinding-sample-redis-frequent-backup-1725533628 + backupSession: appbinding-redis-standalone-frequent-backup-1726661707 deletionPolicy: Delete repository: default-blueprint session: frequent-backup - snapshotID: 01J70X3MGSYT4TJK77R8YXEV3T + snapshotID: 01J82GYFH8RTZ2GNJT2R9FQFHA type: FullBackup version: v1 status: components: dump: driver: Restic - duration: 5.952466363s + duration: 29.616729384s integrity: true path: repository/v1/frequent-backup/dump phase: Succeeded resticStats: - - hostPath: dumpfile.sql - id: a30f8ec138e24cbdbcce088a73e5b9d73a58750c38793ef05ff7d570148ddd2c - size: 3.345 KiB - uploaded: 3.637 KiB - size: 1.132 KiB + - hostPath: dumpfile.resp + id: afce1d29a21d2b05a2aadfb5bdd08f0d5b7c2b2e70fc1d5d77843ebbbef258c1 + size: 184 B + uploaded: 483 B + size: 381 B conditions: - - lastTransitionTime: "2024-09-05T10:53:59Z" + - lastTransitionTime: "2024-09-18T12:15:38Z" message: Recent snapshot list updated successfully reason: SuccessfullyUpdatedRecentSnapshotList status: "True" type: RecentSnapshotListUpdated - - lastTransitionTime: "2024-09-05T10:54:20Z" + - lastTransitionTime: "2024-09-18T12:17:59Z" message: Metadata uploaded to backend successfully reason: SuccessfullyUploadedSnapshotMetadata status: "True" type: SnapshotMetadataUploaded integrity: true phase: Succeeded - size: 1.132 KiB - snapshotTime: "2024-09-05T10:53:59Z" + size: 381 B + snapshotTime: "2024-09-18T12:15:38Z" totalComponents: 1 ``` -> KubeStash uses a logical backup approach to take backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. Do the same for auto-backup, application backup and customize backup if necessary. +> KubeStash uses [redis-dump-go](https://github.com/yannh/redis-dump-go) to perform backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `blueprint/default-blueprint/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `blueprint/default-blueprint/snapshots` directory. > Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. - ## Auto-backup with custom configurations In this section, we are going to backup a `Redis` database of `demo` namespace. We are going to use the custom configurations which will be specified in the `BackupBlueprint` CR. @@ -504,7 +499,6 @@ spec: from: All backupConfigurationTemplate: deletionPolicy: OnDelete - # ============== Blueprint for Backends of BackupConfiguration ================= backends: - name: gcs-backend storageRef: @@ -513,7 +507,6 @@ spec: retentionPolicy: name: demo-retention namespace: demo - # ============== Blueprint for Sessions of BackupConfiguration ================= sessions: - name: frequent-backup sessionHistoryLimit: 3 @@ -532,9 +525,6 @@ spec: name: redis-addon tasks: - name: logical-backup - params: - backupCmd: rd_dump - args: ${targetedDatabase} ``` Note that we have used some variables (format: `${}`) in different fields. KubeStash will substitute these variables with values from the respective target’s annotations. You’re free to use any variables you like. @@ -546,7 +536,6 @@ Here, - `.schedule` defines `${schedule}` variable, which determines the time interval for the backup. - `.repositories[*].name` defines the `${repoName}` variable, which specifies the name of the backup `Repository`. - `.repositories[*].directory` defines two variables, `${namespace}` and `${targetName}`, which are used to determine the path where the backup will be stored. - - `.addon.tasks[*].params.args` defines `${targetedDatabase}` variable, which identifies a single database to backup. Let's create the `BackupBlueprint` we have shown above, @@ -567,7 +556,7 @@ Below is the YAML of the `Redis` object that we are going to create, apiVersion: kubedb.com/v1 kind: Redis metadata: - name: sample-redis-2 + name: redis-standalone-2 namespace: demo annotations: blueprint.kubestash.com/name: redis-customize-backup-blueprint @@ -575,53 +564,50 @@ metadata: variables.kubestash.com/schedule: "*/10 * * * *" variables.kubestash.com/repoName: customize-blueprint variables.kubestash.com/namespace: demo - variables.kubestash.com/targetName: sample-redis-2 - variables.kubestash.com/targetedDatabase: redis + variables.kubestash.com/targetName: redis-standalone-2 spec: - version: "16.1" - replicas: 3 - standbyMode: Hot - streamingMode: Synchronous + version: 7.4.0 storageType: Durable storage: + storageClassName: "standard" accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - deletionPolicy: WipeOut + deletionPolicy: Delete ``` -Notice the `metadata.annotations` field, where we have defined the annotations related to the automatic backup configuration. Specifically, we've set the `BackupBlueprint` name as `redis-customize-backup-blueprint` and the namespace as `demo`. We have also provided values for the blueprint template variables, such as the backup `schedule`, `repositoryName`, `namespace`, `targetName`, and `targetedDatabase`. These annotations will be used to create a `BackupConfiguration` for this `postgreSQL` database. +Notice the `metadata.annotations` field, where we have defined the annotations related to the automatic backup configuration. Specifically, we've set the `BackupBlueprint` name as `redis-customize-backup-blueprint` and the namespace as `demo`. We have also provided values for the blueprint template variables, such as the backup `schedule`, `repositoryName`, `namespace`, and `targetName`. These annotations will be used to create a `BackupConfiguration` for this `Redis` database. Let's create the `Redis` we have shown above, ```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/auto-backup/examples/sample-redis-2.yaml -redis.kubedb.com/sample-redis-2 created +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/auto-backup/examples/redis-standalone-2.yaml +redis.kubedb.com/redis-standalone-2 created ``` **Verify BackupConfiguration** -If everything goes well, KubeStash should create a `BackupConfiguration` for our Redis in demo namespace and the phase of that `BackupConfiguration` should be `Ready`. Verify the `BackupConfiguration` object by the following command, +If everything goes well, KubeStash should create a `BackupConfiguration` for our `Redis` in `demo` namespace and the phase of that `BackupConfiguration` should be `Ready`. Verify the `BackupConfiguration` object by the following command, ```bash $ kubectl get backupconfiguration -n demo -NAME PHASE PAUSED AGE -appbinding-sample-redis-2 Ready 2m50m +NAME PHASE PAUSED AGE +appbinding-redis-standalone-2 Ready 61s ``` Now, let’s check the YAML of the `BackupConfiguration`. ```bash -$ kubectl get backupconfiguration -n demo appbinding-sample-redis-2 -o yaml +$ kubectl get backupconfiguration -n demo appbinding-redis-standalone-2 -o yaml ``` ```yaml apiVersion: core.kubestash.com/v1alpha1 kind: BackupConfiguration metadata: - creationTimestamp: "2024-09-05T12:39:37Z" + creationTimestamp: "2024-09-18T13:04:15Z" finalizers: - kubestash.com/cleanup generation: 1 @@ -629,10 +615,10 @@ metadata: app.kubernetes.io/managed-by: kubestash.com kubestash.com/invoker-name: redis-customize-backup-blueprint kubestash.com/invoker-namespace: demo - name: appbinding-sample-redis-2 + name: appbinding-redis-standalone-2 namespace: demo - resourceVersion: "309511" - uid: b4091166-2813-4183-acda-e2c80eaedbb5 + resourceVersion: "1181988" + uid: 83f7a345-6e1b-41e3-8b6d-520e4a1852e5 spec: backends: - name: gcs-backend @@ -647,13 +633,10 @@ spec: name: redis-addon tasks: - name: logical-backup - params: - args: redis - backupCmd: rd_dump name: frequent-backup repositories: - backend: gcs-backend - directory: demo/sample-redis-2 + directory: demo/redis-standalone-2 encryptionSecret: name: encrypt-secret namespace: demo @@ -671,7 +654,7 @@ spec: target: apiGroup: kubedb.com kind: Redis - name: sample-redis-2 + name: redis-standalone-2 namespace: demo status: backends: @@ -688,7 +671,7 @@ status: name: gcs-storage namespace: demo conditions: - - lastTransitionTime: "2024-09-05T12:39:37Z" + - lastTransitionTime: "2024-09-18T13:04:15Z" message: Validation has been passed successfully. reason: ResourceValidationPassed status: "True" @@ -703,12 +686,12 @@ status: phase: Ready sessions: - conditions: - - lastTransitionTime: "2024-09-05T12:39:37Z" + - lastTransitionTime: "2024-09-18T13:04:35Z" message: Scheduler has been ensured successfully. reason: SchedulerEnsured status: "True" type: SchedulerEnsured - - lastTransitionTime: "2024-09-05T12:39:37Z" + - lastTransitionTime: "2024-09-18T13:04:35Z" message: Initial backup has been triggered successfully. reason: SuccessfullyTriggeredInitialBackup status: "True" @@ -725,8 +708,8 @@ KubeStash triggers an instant backup as soon as the `BackupConfiguration` is rea ```bash $ kubectl get backupsession -n demo -w -NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE -appbinding-sample-redis-frequent-backup-1725597000 BackupConfiguration appbinding-sample-redis Succeeded 58s 112s +NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE +appbinding-redis-standalone-2-frequent-backup-1726664655 BackupConfiguration appbinding-redis-standalone-2 Succeeded 2m33s 4m16s ``` 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. @@ -737,8 +720,8 @@ Once a backup is complete, KubeStash will update the respective `Repository` CR ```bash $ kubectl get repository -n demo customize-blueprint -NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE -customize-blueprint true 1 806 B Ready 8m27s 9m18s +NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE +customize-blueprint true 1 380 B Ready 5m44s 6m4s ``` At this moment we have one `Snapshot`. Run the following command to check the respective `Snapshot` which represents the state of a backup run for an application. @@ -746,7 +729,7 @@ At this moment we have one `Snapshot`. Run the following command to check the re ```bash $ kubectl get snapshots -n demo -l=kubestash.com/repo-name=customize-blueprint NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE AGE -customize-blueprint-appbinding-ses-2-frequent-backup-1725597000 customize-blueprint frequent-backup 2024-09-06T04:30:00Z Delete Succeeded 6m19s +customize-blueprint-appbinding-rne-2-frequent-backup-1726664655 customize-blueprint frequent-backup 2024-09-18T13:04:35Z Delete Succeeded 6m7s ``` > Note: KubeStash creates a `Snapshot` with the following labels: @@ -761,24 +744,24 @@ customize-blueprint-appbinding-ses-2-frequent-backup-1725597000 customize-blue If we check the YAML of the `Snapshot`, we can find the information about the backed up components of the Database. ```bash -$ kubectl get snapshots -n demo customize-blueprint-appbinding-sql-2-frequent-backup-1725597000 -oyaml +$ kubectl get snapshots -n demo customize-blueprint-appbinding-rne-2-frequent-backup-1726664655 -oyaml ``` ```yaml apiVersion: storage.kubestash.com/v1alpha1 kind: Snapshot metadata: - creationTimestamp: "2024-09-06T04:30:00Z" + creationTimestamp: "2024-09-18T13:04:35Z" finalizers: - kubestash.com/cleanup generation: 1 labels: - kubedb.com/db-version: "16.1" + kubedb.com/db-version: 7.4.0 kubestash.com/app-ref-kind: Redis - kubestash.com/app-ref-name: sample-redis-2 + kubestash.com/app-ref-name: redis-standalone-2 kubestash.com/app-ref-namespace: demo kubestash.com/repo-name: customize-blueprint - name: customize-blueprint-appbinding-ses-2-frequent-backup-1725597000 + name: customize-blueprint-appbinding-rne-2-frequent-backup-1726664655 namespace: demo ownerReferences: - apiVersion: storage.kubestash.com/v1alpha1 @@ -786,58 +769,57 @@ metadata: controller: true kind: Repository name: customize-blueprint - uid: 5d4618c5-c28a-456a-9854-f6447161d3d1 - resourceVersion: "315624" - uid: 7e02a18c-c8a7-40be-bd22-e7312678d6f7 + uid: c107da60-af66-4ad6-83cc-d80053a11de3 + resourceVersion: "1182349" + uid: 93b20b59-abce-41a5-88da-f2ce6e98713d spec: appRef: apiGroup: kubedb.com kind: Redis - name: sample-redis-2 + name: redis-standalone-2 namespace: demo - backupSession: appbinding-sample-redis-2-frequent-backup-1725597000 + backupSession: appbinding-redis-standalone-2-frequent-backup-1726664655 deletionPolicy: Delete repository: customize-blueprint session: frequent-backup - snapshotID: 01J72SH8XPEHB6SYNXFE00V5PB + snapshotID: 01J82KR4C7ZER9ZM0W52TVBEET type: FullBackup version: v1 status: components: dump: driver: Restic - duration: 7.060169632s + duration: 29.378445351s integrity: true path: repository/v1/frequent-backup/dump phase: Succeeded resticStats: - - hostPath: dumpfile.sql - id: 74d82943e0d676321e989edb503f5e2d6fe5cf4f4be72d386e492ec533358c26 - size: 1.220 KiB - uploaded: 296 B - size: 1.873 KiB + - hostPath: dumpfile.resp + id: 73cf596a525bcdb439e87812045e7a25c6bd82574513351ab434793c134fc817 + size: 184 B + uploaded: 483 B + size: 380 B conditions: - - lastTransitionTime: "2024-09-06T04:30:00Z" + - lastTransitionTime: "2024-09-18T13:04:35Z" message: Recent snapshot list updated successfully reason: SuccessfullyUpdatedRecentSnapshotList status: "True" type: RecentSnapshotListUpdated - - lastTransitionTime: "2024-09-06T04:30:38Z" + - lastTransitionTime: "2024-09-18T13:07:06Z" message: Metadata uploaded to backend successfully reason: SuccessfullyUploadedSnapshotMetadata status: "True" type: SnapshotMetadataUploaded integrity: true phase: Succeeded - size: 1.872 KiB - snapshotTime: "2024-09-06T04:30:00Z" + size: 380 B + snapshotTime: "2024-09-18T13:04:35Z" totalComponents: 1 ``` +> KubeStash uses [redis-dump-go](https://github.com/yannh/redis-dump-go) to perform backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. -> KubeStash uses a logical backup approach to take backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. Do the same for auto-backup, application backup and customize backup if necessary. - -Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `blueprint/demo/sample-redis-2/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `blueprint/demo/sample-redis-2/snapshots` directory. +Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `blueprint/demo/redis-standalone-2/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `blueprint/demo/redis-standalone-2/snapshots` directory. > Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. @@ -852,6 +834,6 @@ 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 redis -n demo sample-redis -kubectl delete redis -n demo sample-redis-2 +kubectl delete redis -n demo redis-standalone +kubectl delete redis -n demo redis-standalone-2 ``` \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/backup/multiple-repository.yaml b/docs/guides/redis/backup/kubestash/customization/backup/multiple-backends.yaml similarity index 80% rename from docs/guides/redis/backup/kubestash/customization/backup/multiple-repository.yaml rename to docs/guides/redis/backup/kubestash/customization/backup/multiple-backends.yaml index 663ca2522c..bdfd180747 100644 --- a/docs/guides/redis/backup/kubestash/customization/backup/multiple-repository.yaml +++ b/docs/guides/redis/backup/kubestash/customization/backup/multiple-backends.yaml @@ -17,6 +17,13 @@ spec: retentionPolicy: name: demo-retention namespace: demo + - name: s3-backend + storageRef: + namespace: demo + name: s3-storage + retentionPolicy: + name: demo-retention + namespace: demo sessions: - name: frequent-backup scheduler: @@ -30,8 +37,8 @@ spec: encryptionSecret: name: encrypt-secret namespace: demo - - name: gcs-redis-repo-2 - backend: gcs-backend + - name: s3-redis-repo + backend: s3-backend directory: /redis-copy encryptionSecret: name: encrypt-secret diff --git a/docs/guides/redis/backup/kubestash/customization/common/backupstorage.yaml b/docs/guides/redis/backup/kubestash/customization/common/gcs-backupstorage.yaml similarity index 94% rename from docs/guides/redis/backup/kubestash/customization/common/backupstorage.yaml rename to docs/guides/redis/backup/kubestash/customization/common/gcs-backupstorage.yaml index 0461b26762..5972fd3a31 100644 --- a/docs/guides/redis/backup/kubestash/customization/common/backupstorage.yaml +++ b/docs/guides/redis/backup/kubestash/customization/common/gcs-backupstorage.yaml @@ -13,5 +13,5 @@ spec: usagePolicy: allowedNamespaces: from: All - default: true + default: false deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/common/s3-backupstorage.yaml b/docs/guides/redis/backup/kubestash/customization/common/s3-backupstorage.yaml new file mode 100644 index 0000000000..c87d26f7ec --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/common/s3-backupstorage.yaml @@ -0,0 +1,19 @@ +apiVersion: storage.kubestash.com/v1alpha1 +kind: BackupStorage +metadata: + name: s3-storage + namespace: demo +spec: + storage: + provider: s3 + s3: + bucket: kubestash + region: us-east-1 + endpoint: us-east-1.linodeobjects.com + secretName: s3-secret + prefix: sunny + usagePolicy: + allowedNamespaces: + from: All + default: false + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/index.md b/docs/guides/redis/backup/kubestash/customization/index.md index b6800eed7e..4ac8142209 100644 --- a/docs/guides/redis/backup/kubestash/customization/index.md +++ b/docs/guides/redis/backup/kubestash/customization/index.md @@ -1,6 +1,6 @@ --- -title: Redis Backup Customization | KubeStash -description: Customizing Redis Backup and Restore process with KubeStash +title: PostgreSQL Backup Customization | KubeStash +description: Customizing PostgreSQL Backup and Restore process with KubeStash menu: docs_{{ .version }}: identifier: guides-rd-backup-customization-stashv2 @@ -21,7 +21,7 @@ In this section, we are going to show you how to customize the backup process. H ### Passing arguments to the backup process -KubeStash Redis addon uses the [rd_dumpall](https://www.redisql.org/docs/current/app-rd-dumpall.html) command by default for backups. However, you can change the dump command to [rd_dump](https://www.redisql.org/docs/current/app-rddump.html) by setting the `backupCmd` parameter under the `addon.tasks[*].params` section. You can pass supported options for either `rd_dumpall` or `rd_dump` through the `args` parameter in the same section. +KubeStash PostgreSQL addon uses the [rd_dumpall](https://www.redisql.org/docs/current/app-rd-dumpall.html) command by default for backups. However, you can change the dump command to [rd_dump](https://www.redisql.org/docs/current/app-rddump.html) by setting the `backupCmd` parameter under the `addon.tasks[*].params` section. You can pass supported options for either `rd_dumpall` or `rd_dump` through the `args` parameter in the same section. The below example shows how you can pass the `--clean` to include SQL commands to clean (drop) databases before recreating them. @@ -69,7 +69,7 @@ spec: ### Passing a target database to the backup process -KubeStash Redis addon uses the [rd_dumpall](https://www.redisql.org/docs/current/app-rd-dumpall.html) command by default for backups. For a single database backup, you need to rewrite the dump command. You can do this by setting `backupCmd` to [rd_dump](https://www.redisql.org/docs/current/app-rddump.html) under the `addon.tasks[*].params` section and specifying the database name using the `args` parameter in the same section. +KubeStash PostgreSQL addon uses the [rd_dumpall](https://www.redisql.org/docs/current/app-rd-dumpall.html) command by default for backups. If you want to back up a single database, you’ll need to switch the command to [rd_dump](https://www.redisql.org/docs/current/app-rddump.html). You can do this by setting `backupCmd` to `rd_dump` under the `addon.tasks[*].params` section and specifying the database name using the `args` parameter in the same section. The below example shows how you can set `rd_dump` and pass target database name during backup. @@ -117,9 +117,9 @@ spec: > **WARNING**: Make sure that your provided database has been created before taking backup. -### Using multiple repositories +### Using multiple backends -You can configure multiple repositories for the same backend. For example, if you want to back up the `/redis` directory using the `gcs-redis-repo` repository, you can also back up another directory, such as `/redis-copy`, by using a different repository, like `gcs-redis-repo-2`. +You can configure multiple backends within a single `backupConfiguration`. To back up the same data to different backends, such as S3 and GCS, declare each backend in the `.spe.backends` section. Then, reference these backends in the `.spec.sessions[*].repositories` section. ```yaml apiVersion: core.kubestash.com/v1alpha1 @@ -141,6 +141,13 @@ spec: retentionPolicy: name: demo-retention namespace: demo + - name: s3-backend + storageRef: + namespace: demo + name: s3-storage + retentionPolicy: + name: demo-retention + namespace: demo sessions: - name: frequent-backup scheduler: @@ -154,8 +161,8 @@ spec: encryptionSecret: name: encrypt-secret namespace: demo - - name: gcs-redis-repo-2 - backend: gcs-backend + - name: s3-redis-repo + backend: s3-backend directory: /redis-copy encryptionSecret: name: encrypt-secret diff --git a/docs/guides/redis/backup/kubestash/customization/restore/passing-args.yaml b/docs/guides/redis/backup/kubestash/customization/restore/passing-args.yaml new file mode 100644 index 0000000000..d8193107f4 --- /dev/null +++ b/docs/guides/redis/backup/kubestash/customization/restore/passing-args.yaml @@ -0,0 +1,23 @@ +apiVersion: core.kubestash.com/v1alpha1 +kind: RestoreSession +metadata: + name: sample-redis-restore + namespace: demo +spec: + target: + apiGroup: kubedb.com + kind: Redis + namespace: demo + name: restored-redis + dataSource: + repository: gcs-redis-repo + snapshot: latest + encryptionSecret: + name: encrypt-secret + namespace: demo + addon: + name: redis-addon + tasks: + - name: logical-backup-restore + params: + args: --dbname=testdb \ No newline at end of file From 5084122345a2a22b4c2d0110b2c82542a7d4ad96 Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Thu, 19 Sep 2024 18:13:21 +0600 Subject: [PATCH 06/11] application backup complete doc Signed-off-by: Neaj Morshad --- .../examples/backupstorage.yaml | 2 +- ...sample-postgres.yaml => sample-redis.yaml} | 8 +- .../kubestash/application-level/index.md | 375 ++++++------------ 3 files changed, 133 insertions(+), 252 deletions(-) rename docs/guides/redis/backup/kubestash/application-level/examples/{sample-postgres.yaml => sample-redis.yaml} (67%) diff --git a/docs/guides/redis/backup/kubestash/application-level/examples/backupstorage.yaml b/docs/guides/redis/backup/kubestash/application-level/examples/backupstorage.yaml index 6ab3df02ac..d081682cfc 100644 --- a/docs/guides/redis/backup/kubestash/application-level/examples/backupstorage.yaml +++ b/docs/guides/redis/backup/kubestash/application-level/examples/backupstorage.yaml @@ -7,7 +7,7 @@ spec: storage: provider: gcs gcs: - bucket: kubestash-qa + bucket: neaj-demo prefix: demo secretName: gcs-secret usagePolicy: diff --git a/docs/guides/redis/backup/kubestash/application-level/examples/sample-postgres.yaml b/docs/guides/redis/backup/kubestash/application-level/examples/sample-redis.yaml similarity index 67% rename from docs/guides/redis/backup/kubestash/application-level/examples/sample-postgres.yaml rename to docs/guides/redis/backup/kubestash/application-level/examples/sample-redis.yaml index ce97b5a41c..891f433061 100644 --- a/docs/guides/redis/backup/kubestash/application-level/examples/sample-postgres.yaml +++ b/docs/guides/redis/backup/kubestash/application-level/examples/sample-redis.yaml @@ -4,15 +4,13 @@ metadata: name: sample-redis namespace: demo spec: - version: "16.1" - replicas: 3 - standbyMode: Hot - streamingMode: Synchronous + version: 7.4.0 storageType: Durable storage: + storageClassName: "standard" accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - deletionPolicy: WipeOut \ No newline at end of file + deletionPolicy: Delete \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/application-level/index.md b/docs/guides/redis/backup/kubestash/application-level/index.md index 8be337f2d0..875275cd7b 100644 --- a/docs/guides/redis/backup/kubestash/application-level/index.md +++ b/docs/guides/redis/backup/kubestash/application-level/index.md @@ -1,5 +1,5 @@ --- -title: Application Level Backup & Restore PostgreSQL | KubeStash +title: Application Level Backup & Restore Redis | KubeStash description: Application Level Backup and Restore using KubeStash menu: docs_{{ .version }}: @@ -11,11 +11,11 @@ menu_name: docs_{{ .version }} section_menu_id: guides --- -# Application Level Backup and Restore PostgreSQL database using KubeStash +# Application Level Backup and Restore Redis database using KubeStash -KubeStash offers application-level backup and restore functionality for `PostgreSQL` databases. It captures both manifest and data backups of any `PostgreSQL` database in a single snapshot. During the restore process, KubeStash first applies the `PostgreSQL` manifest to the cluster and then restores the data into it. +KubeStash offers application-level backup and restore functionality for `Redis` databases. It captures both manifest and data backups of any `Redis` database in a single snapshot. During the restore process, KubeStash first applies the `Redis` manifest to the cluster and then restores the data into it. -This guide will give you an overview how you can take application-level backup and restore your `PostgreSQL` databases using `Kubestash`. +This guide will give you an overview how you can take application-level backup and restore your `Redis` databases using `Kubestash`. ## Before You Begin @@ -23,7 +23,7 @@ This guide will give you an overview how you can take application-level backup a - Install `KubeDB` in your cluster following the steps [here](/docs/setup/README.md). - Install `KubeStash` in your cluster following the steps [here](https://kubestash.com/docs/latest/setup/install/kubestash). - Install KubeStash `kubectl` plugin following the steps [here](https://kubestash.com/docs/latest/setup/install/kubectl-plugin/). -- If you are not familiar with how KubeStash backup and restore PostgreSQL databases, please check the following guide [here](/docs/guides/redis/backup/kubestash/overview/index.md). +- If you are not familiar with how KubeStash backup and restore Redis databases, please check the following guide [here](/docs/guides/redis/backup/kubestash/overview/index.md). You should be familiar with the following `KubeStash` concepts: @@ -44,19 +44,19 @@ namespace/demo created > **Note:** YAML files used in this tutorial are stored in [docs/guides/redis/backup/kubestash/application-level/examples](https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/application-level/examples) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. -## Backup PostgreSQL +## Backup Redis -KubeStash supports backups for `PostgreSQL` instances across different configurations, including Standalone and HA Cluster setups. In this demonstration, we'll focus on a `PostgreSQL` database using HA cluster configuration. The backup and restore process is similar for Standalone configuration. +KubeStash supports backups for `Redis` instances across different configurations, including Standalone, Cluster and Sentinel modes. In this demonstration, we'll focus on a `Redis` database of Standalone mode. The backup and restore process is similar for Sentinel and Cluster configuration. -This section will demonstrate how to take application-level backup of a `PostgreSQL` database. Here, we are going to deploy a `PostgreSQL` database using KubeDB. Then, we are going to back up the database at the application level to a `GCS` bucket. Finally, we will restore the entire `PostgreSQL` database. +This section will demonstrate how to take application-level backup of a `Redis` database. Here, we are going to deploy a `Redis` database using KubeDB. Then, we are going to back up the database at the application level to a `GCS` bucket. Finally, we will restore the entire `Redis` database. -### Deploy Sample PostgreSQL Database +### Deploy Sample Redis Database -Let's deploy a sample `PostgreSQL` database and insert some data into it. +Let's deploy a sample `Redis` database and insert some data into it. -**Create PostgreSQL CR:** +**Create Redis CR:** -Below is the YAML of a sample `PostgreSQL` CR that we are going to create for this tutorial: +Below is the YAML of a sample `Redis` CR that we are going to create for this tutorial: ```yaml apiVersion: kubedb.com/v1 @@ -65,49 +65,47 @@ metadata: name: sample-redis namespace: demo spec: - version: "16.1" - replicas: 3 - standbyMode: Hot - streamingMode: Synchronous + version: 7.4.0 storageType: Durable storage: + storageClassName: "standard" accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - deletionPolicy: WipeOut + deletionPolicy: Delete ``` -Create the above `PostgreSQL` CR, +Create the above `Redis` CR, ```bash $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/redis/backup/kubestash/application-level/examples/sample-redis.yaml redis.kubedb.com/sample-redis created ``` -KubeDB will deploy a `PostgreSQL` database according to the above specification. It will also create the necessary `Secrets` and `Services` to access the database. +KubeDB will deploy a `Redis` 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, ```bash $ kubectl get rd -n demo sample-redis -NAME VERSION STATUS AGE -sample-redis 16.1 Ready 5m1s +NAME VERSION STATUS AGE +sample-redis 7.4.0 Ready 2m ``` The database is `Ready`. Verify that KubeDB has created a `Secret` and a `Service` for this database using the following commands, ```bash $ kubectl get secret -n demo -NAME TYPE DATA AGE -sample-redis-auth kubernetes.io/basic-auth 2 5m20s +NAME TYPE DATA AGE +sample-redis-auth kubernetes.io/basic-auth 2 3m5s +sample-redis-config Opaque 1 2m14s $ kubectl get service -n demo -l=app.kubernetes.io/instance=sample-redis -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -sample-redis ClusterIP 10.96.23.177 5432/TCP,2379/TCP 5m55s -sample-redis-pods ClusterIP None 5432/TCP,2380/TCP,2379/TCP 5m55s -sample-redis-standby ClusterIP 10.96.26.118 5432/TCP 5m55s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +sample-redis ClusterIP 10.96.131.142 6379/TCP 2m53s +sample-redis-pods ClusterIP None 6379/TCP 2m53s ``` Here, we have to use service `sample-redis` and secret `sample-redis-auth` to connect with the database. `KubeDB` creates an [AppBinding](/docs/guides/redis/concepts/appbinding.md) CR that holds the necessary information to connect with the database. @@ -119,8 +117,8 @@ Verify that the `AppBinding` has been created successfully using the following c ```bash $ kubectl get appbindings -n demo -NAME TYPE VERSION AGE -sample-redis kubedb.com/redis 16.1 9m30s +NAME TYPE VERSION AGE +sample-redis kubedb.com/redis 7.4.0 2m53s ``` Let's check the YAML of the above `AppBinding`, @@ -135,8 +133,8 @@ kind: AppBinding metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"kubedb.com/v1","kind":"Redis","metadata":{"annotations":{},"name":"sample-redis","namespace":"demo"},"spec":{"deletionPolicy":"DoNotTerminate","replicas":3,"standbyMode":"Hot","storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}}},"storageType":"Durable","streamingMode":"Synchronous","version":"16.1"}} - creationTimestamp: "2024-09-04T10:07:04Z" + {"apiVersion":"kubedb.com/v1","kind":"Redis","metadata":{"annotations":{},"name":"sample-redis","namespace":"demo"},"spec":{"deletionPolicy":"Delete","storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}},"storageClassName":"standard"},"storageType":"Durable","version":"7.4.0"}} + creationTimestamp: "2024-09-19T11:33:26Z" generation: 1 labels: app.kubernetes.io/component: database @@ -146,14 +144,14 @@ metadata: name: sample-redis namespace: demo ownerReferences: - - apiVersion: kubedb.com/v1 - blockOwnerDeletion: true - controller: true - kind: Redis - name: sample-redis - uid: 0810a96c-a2b6-4e8a-a70a-51753660450c - resourceVersion: "245972" - uid: 73bdba85-c932-464b-93a8-7f1ba8dfff1b + - apiVersion: kubedb.com/v1 + blockOwnerDeletion: true + controller: true + kind: Redis + name: sample-redis + uid: bb6cb9d1-6350-4d32-b0ff-309585075e85 + resourceVersion: "1221288" + uid: 57fe3454-2498-45f0-9254-6aeba5f87818 spec: appRef: apiGroup: kubedb.com @@ -163,23 +161,21 @@ spec: clientConfig: service: name: sample-redis - path: / - port: 5432 - query: sslmode=disable - scheme: redisql + port: 6379 + scheme: redis parameters: - apiVersion: appcatalog.appscode.com/v1alpha1 - kind: StashAddon + apiVersion: config.kubedb.com/v1alpha1 + kind: RedisConfiguration stash: addon: backupTask: - name: redis-backup-16.1 + name: redis-backup-7.0.5 restoreTask: - name: redis-restore-16.1 + name: redis-restore-7.0.5 secret: name: sample-redis-auth type: kubedb.com/redis - version: "16.1" + version: 7.4.0 ``` KubeStash uses the `AppBinding` CR to connect with the target database. It requires the following two fields to set in AppBinding's `.spec` section. @@ -192,91 +188,28 @@ Here, **Insert Sample Data:** -Now, we are going to exec into one of the database pod and create some sample data. At first, find out the database `Pod` using the following command, +Now, 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, ```bash $ kubectl get pods -n demo --selector="app.kubernetes.io/instance=sample-redis" -NAME READY STATUS RESTARTS AGE -sample-redis-0 2/2 Running 0 16m -sample-redis-1 2/2 Running 0 13m -sample-redis-2 2/2 Running 0 13m +NAME READY STATUS RESTARTS AGE +sample-redis-0 1/1 Running 0 5m39s ``` -Now, let’s exec into the pod and create a table, +Now, let’s exec into the pod and insert some data, ```bash -$ kubectl exec -it -n demo sample-redis-0 -- sh - -# login as "redis" superuser. -/ $ psql -U redis -psql (16.1) -Type "help" for help. - -# list available databases -redis=# \l - List of databases - Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges ----------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- - kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis - template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis -(4 rows) - -# create a database named "demo" -redis=# create database demo; -CREATE DATABASE - -# verify that the "demo" database has been created -redis=# \l - List of databases - Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges ----------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- - demo | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis - template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis -(5 rows) - -# connect to the "demo" database -redis=# \c demo -You are now connected to database "demo" as user "redis". - -# create a sample table -demo=# CREATE TABLE COMPANY( NAME TEXT NOT NULL, EMPLOYEE INT NOT NULL); -CREATE TABLE - -# verify that the table has been created -demo=# \d - List of relations - Schema | Name | Type | Owner ---------+---------+-------+---------- - public | company | table | redis -(1 row) - -# insert multiple rows of data into the table -demo=# INSERT INTO COMPANY (NAME, EMPLOYEE) VALUES ('TechCorp', 100), ('InnovateInc', 150), ('AlphaTech', 200); -INSERT 0 3 - -# verify the data insertion -demo=# SELECT * FROM COMPANY; - name | employee --------------+---------- - TechCorp | 100 - InnovateInc | 150 - AlphaTech | 200 -(3 rows) - -# quit from the database -demo=# \q - -# exit from the pod -/ $ exit +$ kubectl exec -it -n demo sample-redis-0 -c redis -- bash +redis@sample-redis-0:/data$ redis-cli +127.0.0.1:6379> set db redis +OK +127.0.0.1:6379> set name neaj +OK +127.0.0.1:6379> set key value +OK +127.0.0.1:6379> exit +redis@sample-redis-0:/data$ exit +exit ``` Now, we are ready to backup the database. @@ -312,7 +245,7 @@ spec: storage: provider: gcs gcs: - bucket: kubestash-qa + bucket: neaj-demo prefix: demo secretName: gcs-secret usagePolicy: @@ -364,7 +297,7 @@ retentionpolicy.storage.kubestash.com/demo-retention created ### Backup -We have to create a `BackupConfiguration` targeting respective `sample-redis` PostgreSQL database. Then, KubeStash will create a `CronJob` for each session to take periodic backup of that database. +We have to create a `BackupConfiguration` targeting respective `sample-redis` Redis database. Then, KubeStash will create a `CronJob` for each session to take periodic backup of that database. At first, we need to create a secret with a Restic password for backup data encryption. @@ -424,7 +357,7 @@ spec: ``` - `.spec.sessions[*].schedule` specifies that we want to backup at `5 minutes` interval. -- `.spec.target` refers to the targeted `sample-redis` PostgreSQL database that we created earlier. +- `.spec.target` refers to the targeted `sample-redis` Redis database that we created earlier. - `.spec.sessions[*].addon.tasks[*].name[*]` specifies that both the `manifest-backup` and `logical-backup` tasks will be executed. Let's create the `BackupConfiguration` CR that we have shown above, @@ -441,7 +374,7 @@ If everything goes well, the phase of the `BackupConfiguration` should be `Ready ```bash $ kubectl get backupconfiguration -n demo NAME PHASE PAUSED AGE -sample-redis-backup Ready 2m50s +sample-redis-backup Ready 2m50s ``` Additionally, we can verify that the `Repository` specified in the `BackupConfiguration` has been created using the following command, @@ -449,7 +382,7 @@ Additionally, we can verify that the `Repository` specified in the `BackupConfig ```bash $ kubectl get repo -n demo NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE -gcs-redis-repo 0 0 B Ready 3m +gcs-redis-repo 0 0 B Ready 3m ``` KubeStash keeps the backup for `Repository` YAMLs. If we navigate to the GCS bucket, we will see the `Repository` YAML stored in the `demo/redis` directory. @@ -463,7 +396,7 @@ Verify that the `CronJob` has been created using the following command, ```bash $ kubectl get cronjob -n demo NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE -trigger-sample-redis-backup-frequent-backup */5 * * * * 0 2m45s 3m25s +trigger-sample-redis-backup-frequent-backup */5 * * * * 0 2m45s 3m25s ``` **Verify BackupSession:** @@ -473,19 +406,19 @@ KubeStash triggers an instant backup as soon as the `BackupConfiguration` is rea ```bash $ kubectl get backupsession -n demo -w NAME INVOKER-TYPE INVOKER-NAME PHASE DURATION AGE -sample-redis-backup-frequent-backup-1725449400 BackupConfiguration sample-redis-backup Succeeded 7m22s +sample-redis-backup-frequent-backup-1725449400 BackupConfiguration sample-redis-backup Succeeded 7m22s ``` 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 `sample-redis-backup` has been updated by the following command, +Once a backup is complete, KubeStash will update the respective `Repository` CR to reflect the backup. Check that the repository `gcs-redis-repo` has been updated by the following command, ```bash $ kubectl get repository -n demo gcs-redis-repo NAME INTEGRITY SNAPSHOT-COUNT SIZE PHASE LAST-SUCCESSFUL-BACKUP AGE -gcs-redis-repo true 1 806 B Ready 8m27s 9m18s +gcs-redis-repo true 1 806 B Ready 8m27s 9m18s ``` At this moment we have one `Snapshot`. Run the following command to check the respective `Snapshot` which represents the state of a backup run for an application. @@ -493,7 +426,7 @@ At this moment we have one `Snapshot`. Run the following command to check the re ```bash $ kubectl get snapshots -n demo -l=kubestash.com/repo-name=gcs-redis-repo NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE AGE -gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 gcs-redis-repo frequent-backup 2024-01-23T13:10:54Z Delete Succeeded 16h +gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 gcs-redis-repo frequent-backup 2024-01-23T13:10:54Z Delete Succeeded 16h ``` > Note: KubeStash creates a `Snapshot` with the following labels: @@ -514,90 +447,77 @@ $ kubectl get snapshots -n demo gcs-redis-repo-sample-redis-backup-frequent-back apiVersion: storage.kubestash.com/v1alpha1 kind: Snapshot metadata: - creationTimestamp: "2024-09-05T09:08:03Z" + creationTimestamp: "2024-09-18T13:04:35Z" finalizers: - - kubestash.com/cleanup + - kubestash.com/cleanup generation: 1 labels: + kubedb.com/db-version: 7.4.0 kubestash.com/app-ref-kind: Redis - kubestash.com/app-ref-name: sample-redis + kubestash.com/app-ref-name: redis-standalone-2 kubestash.com/app-ref-namespace: demo - kubestash.com/repo-name: gcs-redis-repo - annotations: - kubedb.com/db-version: "16.1" - name: gcs-redis-repo-sample-redis-backup-frequent-backup-1725449400 + kubestash.com/repo-name: customize-blueprint + name: customize-blueprint-appbinding-rne-2-frequent-backup-1726664655 namespace: demo ownerReferences: - - apiVersion: storage.kubestash.com/v1alpha1 - blockOwnerDeletion: true - controller: true - kind: Repository - name: gcs-redis-repo - uid: fa9086e5-285a-4b4a-9096-072bf7dbe2f7 - resourceVersion: "289843" - uid: 43f17a3f-4ac7-443c-a139-151f2e5bf462 + - apiVersion: storage.kubestash.com/v1alpha1 + blockOwnerDeletion: true + controller: true + kind: Repository + name: customize-blueprint + uid: c107da60-af66-4ad6-83cc-d80053a11de3 + resourceVersion: "1182349" + uid: 93b20b59-abce-41a5-88da-f2ce6e98713d spec: appRef: apiGroup: kubedb.com kind: Redis - name: sample-redis + name: redis-standalone-2 namespace: demo - backupSession: sample-redis-backup-frequent-backup-1725527283 + backupSession: appbinding-redis-standalone-2-frequent-backup-1726664655 deletionPolicy: Delete - repository: gcs-redis-repo + repository: customize-blueprint session: frequent-backup - snapshotID: 01J70Q1NT6FW11YBBARRFJ6SYB + snapshotID: 01J82KR4C7ZER9ZM0W52TVBEET type: FullBackup version: v1 status: components: dump: driver: Restic - duration: 6.684476865s + duration: 29.378445351s integrity: true path: repository/v1/frequent-backup/dump phase: Succeeded resticStats: - - hostPath: dumpfile.sql - id: 4b820700710f9f7b6a8d5b052367b51875e68dcd9052c749a686506db6a66374 - size: 3.345 KiB - uploaded: 3.634 KiB - size: 1.135 KiB - manifest: - driver: Restic - duration: 7.477728298s - integrity: true - path: repository/v1/frequent-backup/manifest - phase: Succeeded - resticStats: - - hostPath: /kubestash-tmp/manifest - id: 9da4d1b7df6dd946e15a8a0d2a2a3c14776351e27926156770530ca03f6f8002 - size: 3.064 KiB - uploaded: 1.443 KiB - size: 2.972 KiB + - hostPath: dumpfile.resp + id: 73cf596a525bcdb439e87812045e7a25c6bd82574513351ab434793c134fc817 + size: 184 B + uploaded: 483 B + size: 380 B conditions: - - lastTransitionTime: "2024-09-05T09:08:03Z" - message: Recent snapshot list updated successfully - reason: SuccessfullyUpdatedRecentSnapshotList - status: "True" - type: RecentSnapshotListUpdated - - lastTransitionTime: "2024-09-05T09:08:49Z" - message: Metadata uploaded to backend successfully - reason: SuccessfullyUploadedSnapshotMetadata - status: "True" - type: SnapshotMetadataUploaded + - lastTransitionTime: "2024-09-18T13:04:35Z" + message: Recent snapshot list updated successfully + reason: SuccessfullyUpdatedRecentSnapshotList + status: "True" + type: RecentSnapshotListUpdated + - lastTransitionTime: "2024-09-18T13:07:06Z" + message: Metadata uploaded to backend successfully + reason: SuccessfullyUploadedSnapshotMetadata + status: "True" + type: SnapshotMetadataUploaded integrity: true phase: Succeeded - size: 4.106 KiB - snapshotTime: "2024-09-05T09:08:03Z" - totalComponents: 2 + size: 380 B + snapshotTime: "2024-09-18T13:04:35Z" + totalComponents: 1 ``` -> KubeStash uses `rd_dump` or `rd_dumpall` to perform backups of target `PostgreSQL` databases. Therefore, the component name for logical backups is set as `dump`. - -> KubeStash set component name as `manifest` for the `manifest backup` of PostgreSQL databases. +> KubeStash uses [redis-dump-go](https://github.com/yannh/redis-dump-go) to perform backups of target `Redis` databases. Therefore, the component name for logical backups is set as `dump`. +> +> KubeStash set component name as `manifest` for the `manifest backup` of Redis databases. -Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/popstgres/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/redis/snapshots` directory. +Now, if we navigate to the GCS bucket, we will see the backed up data stored in the `demo/redis/repository/v1/frequent-backup/dump` directory. KubeStash also keeps the backup for `Snapshot` YAMLs, which can be found in the `demo/redis/snapshots` directory. > Note: KubeStash stores all dumped data encrypted in the backup directory, meaning it remains unreadable until decrypted. @@ -664,15 +584,15 @@ Once, you have created the `RestoreSession` object, KubeStash will create restor $ watch kubectl get restoresession -n demo Every 2.0s: kubectl get restores... AppsCode-PC-03: Wed Aug 21 10:44:05 2024 NAME REPOSITORY FAILURE-POLICY PHASE DURATION AGE -restore-sample-redis gcs-redis-repo Succeeded 3s 53s +restore-sample-redis gcs-redis-repo Succeeded 3s 53s ``` The `Succeeded` phase means that the restore process has been completed successfully. -#### Verify Restored PostgreSQL Manifest: +#### Verify Restored Redis Manifest: -In this section, we will verify whether the desired `PostgreSQL` database manifest has been successfully applied to the cluster. +In this section, we will verify whether the desired `Redis` database manifest has been successfully applied to the cluster. ```bash $ kubectl get redis -n dev @@ -680,81 +600,44 @@ NAME VERSION STATUS AGE sample-redis 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. +The output confirms that the `Redis` 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. +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 data we inserted earlier in the original database are restored. At first, check if the database has gone into **`Ready`** state by the following command, ```bash $ kubectl get redis -n dev sample-redis NAME VERSION STATUS AGE -sample-redis 16.1 Ready 9m46s +sample-redis 7.4.0 Ready 9m46s ``` Now, find out the database `Pod` by the following command, ```bash $ kubectl get pods -n dev --selector="app.kubernetes.io/instance=sample-redis" -NAME READY STATUS RESTARTS AGE -sample-redis-0 2/2 Running 0 12m -sample-redis-1 2/2 Running 0 12m -sample-redis-2 2/2 Running 0 12m +NAME READY STATUS RESTARTS AGE +sample-redis-0 1/1 Running 0 12m ``` Now, lets exec one of the Pod and verify restored data. ```bash -$ kubectl exec -it -n dev sample-redis-0 -- /bin/sh -# login as "redis" superuser. -/ # psql -U redis -psql (11.11) -Type "help" for help. - -# verify that the "demo" database has been restored -redis=# \l - List of databases - Name | Owner | Encoding | Locale Provider | Collate | Ctype | ICU Locale | ICU Rules | Access privileges ----------------+----------+----------+-----------------+------------+------------+------------+-----------+----------------------- - demo | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - kubedb_system | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - redis | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | - template0 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis - template1 | redis | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/redis + - | | | | | | | | redis=CTc/redis -(5 rows) - -# connect to the "demo" database -redis=# \c demo -You are now connected to database "demo" as user "redis". - -# verify that the sample table has been restored -demo=# \d - List of relations - Schema | Name | Type | Owner ---------+---------+-------+---------- - public | company | table | redis -(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 - -# exit from the pod -/ # exit +$ kubectl exec -it -n dev sample-redis-0 -c redis -- bash +redis@sample-redis-0:/data$ redis-cli +127.0.0.1:6379> get db +"redis" +127.0.0.1:6379> get name +"neaj" +127.0.0.1:6379> get key +"value" +127.0.0.1:6379> exit +redis@sample-redis-0:/data$ exit +exit ``` So, from the above output, we can see the `demo` database we had created in the original database `sample-redis` has been restored successfully. From 36cdc691f509860599399c2455f97f8d00b32f39 Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Fri, 20 Sep 2024 15:43:13 +0600 Subject: [PATCH 07/11] customize backup restore job complete doc Signed-off-by: Neaj Morshad --- .../customization/backup/passing-args.yaml | 2 +- .../backup/passing-database.yaml | 39 ---------- .../common/gcs-backupstorage.yaml | 5 +- .../common/s3-backupstorage.yaml | 8 +- ...sample-postgres.yaml => sample-redis.yaml} | 8 +- .../backup/kubestash/customization/index.md | 75 +++---------------- .../customization/restore/passing-args.yaml | 2 +- 7 files changed, 23 insertions(+), 116 deletions(-) delete mode 100644 docs/guides/redis/backup/kubestash/customization/backup/passing-database.yaml rename docs/guides/redis/backup/kubestash/customization/common/{sample-postgres.yaml => sample-redis.yaml} (67%) diff --git a/docs/guides/redis/backup/kubestash/customization/backup/passing-args.yaml b/docs/guides/redis/backup/kubestash/customization/backup/passing-args.yaml index a2e0e82457..baa6711425 100644 --- a/docs/guides/redis/backup/kubestash/customization/backup/passing-args.yaml +++ b/docs/guides/redis/backup/kubestash/customization/backup/passing-args.yaml @@ -35,4 +35,4 @@ spec: tasks: - name: logical-backup params: - args: --clean \ No newline at end of file + args: "-db 1" \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/backup/passing-database.yaml b/docs/guides/redis/backup/kubestash/customization/backup/passing-database.yaml deleted file mode 100644 index 554ed40234..0000000000 --- a/docs/guides/redis/backup/kubestash/customization/backup/passing-database.yaml +++ /dev/null @@ -1,39 +0,0 @@ -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: sample-redis-backup - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: Redis - namespace: demo - name: sample-redis - 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-redis-repo - backend: gcs-backend - directory: /redis - encryptionSecret: - name: encrypt-secret - namespace: demo - addon: - name: redis-addon - tasks: - - name: logical-backup - params: - backupCmd: rd_dump - args: testdb \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/common/gcs-backupstorage.yaml b/docs/guides/redis/backup/kubestash/customization/common/gcs-backupstorage.yaml index 5972fd3a31..5535624773 100644 --- a/docs/guides/redis/backup/kubestash/customization/common/gcs-backupstorage.yaml +++ b/docs/guides/redis/backup/kubestash/customization/common/gcs-backupstorage.yaml @@ -7,11 +7,10 @@ spec: storage: provider: gcs gcs: - bucket: kubestash-qa + bucket: neaj-demo prefix: demo secretName: gcs-secret usagePolicy: allowedNamespaces: from: All - default: false - deletionPolicy: WipeOut \ No newline at end of file + deletionPolicy: Delete \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/common/s3-backupstorage.yaml b/docs/guides/redis/backup/kubestash/customization/common/s3-backupstorage.yaml index c87d26f7ec..ac6ca82712 100644 --- a/docs/guides/redis/backup/kubestash/customization/common/s3-backupstorage.yaml +++ b/docs/guides/redis/backup/kubestash/customization/common/s3-backupstorage.yaml @@ -7,11 +7,11 @@ spec: storage: provider: s3 s3: - bucket: kubestash - region: us-east-1 - endpoint: us-east-1.linodeobjects.com + bucket: neaj-new + region: ap-south-1 + endpoint: ap-south-1.linodeobjects.com secretName: s3-secret - prefix: sunny + prefix: backup usagePolicy: allowedNamespaces: from: All diff --git a/docs/guides/redis/backup/kubestash/customization/common/sample-postgres.yaml b/docs/guides/redis/backup/kubestash/customization/common/sample-redis.yaml similarity index 67% rename from docs/guides/redis/backup/kubestash/customization/common/sample-postgres.yaml rename to docs/guides/redis/backup/kubestash/customization/common/sample-redis.yaml index ce97b5a41c..891f433061 100644 --- a/docs/guides/redis/backup/kubestash/customization/common/sample-postgres.yaml +++ b/docs/guides/redis/backup/kubestash/customization/common/sample-redis.yaml @@ -4,15 +4,13 @@ metadata: name: sample-redis namespace: demo spec: - version: "16.1" - replicas: 3 - standbyMode: Hot - streamingMode: Synchronous + version: 7.4.0 storageType: Durable storage: + storageClassName: "standard" accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - deletionPolicy: WipeOut \ No newline at end of file + deletionPolicy: Delete \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/customization/index.md b/docs/guides/redis/backup/kubestash/customization/index.md index 4ac8142209..314c75bbc9 100644 --- a/docs/guides/redis/backup/kubestash/customization/index.md +++ b/docs/guides/redis/backup/kubestash/customization/index.md @@ -1,6 +1,6 @@ --- -title: PostgreSQL Backup Customization | KubeStash -description: Customizing PostgreSQL Backup and Restore process with KubeStash +title: Redis Backup Customization | KubeStash +description: Customizing Redis Backup and Restore process with KubeStash menu: docs_{{ .version }}: identifier: guides-rd-backup-customization-stashv2 @@ -21,9 +21,9 @@ In this section, we are going to show you how to customize the backup process. H ### Passing arguments to the backup process -KubeStash PostgreSQL addon uses the [rd_dumpall](https://www.redisql.org/docs/current/app-rd-dumpall.html) command by default for backups. However, you can change the dump command to [rd_dump](https://www.redisql.org/docs/current/app-rddump.html) by setting the `backupCmd` parameter under the `addon.tasks[*].params` section. You can pass supported options for either `rd_dumpall` or `rd_dump` through the `args` parameter in the same section. +KubeStash Redis addon uses [redis-dump-go](https://github.com/yannh/redis-dump-go) for backup. You can pass arguments to the redis-dump-go through args parameter under `addon.tasks[*].params` section. -The below example shows how you can pass the `--clean` to include SQL commands to clean (drop) databases before recreating them. +The below example shows how you can pass the `-db 1` to take backup only the database with index 1. ```yaml apiVersion: core.kubestash.com/v1alpha1 @@ -63,60 +63,9 @@ spec: tasks: - name: logical-backup params: - args: --clean + args: "-db 1" ``` - -### Passing a target database to the backup process - -KubeStash PostgreSQL addon uses the [rd_dumpall](https://www.redisql.org/docs/current/app-rd-dumpall.html) command by default for backups. If you want to back up a single database, you’ll need to switch the command to [rd_dump](https://www.redisql.org/docs/current/app-rddump.html). You can do this by setting `backupCmd` to `rd_dump` under the `addon.tasks[*].params` section and specifying the database name using the `args` parameter in the same section. - -The below example shows how you can set `rd_dump` and pass target database name during backup. - -```yaml -apiVersion: core.kubestash.com/v1alpha1 -kind: BackupConfiguration -metadata: - name: sample-redis-backup - namespace: demo -spec: - target: - apiGroup: kubedb.com - kind: Redis - namespace: demo - name: sample-redis - 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-redis-repo - backend: gcs-backend - directory: /redis - encryptionSecret: - name: encrypt-secret - namespace: demo - addon: - name: redis-addon - tasks: - - name: logical-backup - params: - backupCmd: rd_dump - args: testdb -``` - -> **WARNING**: Make sure that your provided database has been created before taking backup. - ### Using multiple backends You can configure multiple backends within a single `backupConfiguration`. To back up the same data to different backends, such as S3 and GCS, declare each backend in the `.spe.backends` section. Then, reference these backends in the `.spec.sessions[*].repositories` section. @@ -277,11 +226,11 @@ spec: ## Customizing Restore Process -`KubeStash` uses [psql](https://www.redisql.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. +`KubeStash` uses `redis-cli` 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. +Similar to the backup process, you can pass arguments to the restore process through the `args` field within the `addon.tasks[*].params` section. Here, we have passed --pipe-timeout argument to the redis-cli. ```yaml apiVersion: core.kubestash.com/v1alpha1 @@ -306,7 +255,7 @@ spec: tasks: - name: logical-backup-restore params: - args: --dbname=testdb + args: "--pipe-timeout 300" ``` ### Restore specific snapshot @@ -316,10 +265,10 @@ You can also restore a specific snapshot. At first, list the available snapshot ```bash $ kubectl get snapshots.storage.kubestash.com -n demo -l=kubestash.com/repo-name=gcs-redis-repo NAME REPOSITORY SESSION SNAPSHOT-TIME DELETION-POLICY PHASE AGE -gcs-redis-repo-sample-redis-backup-frequent-backup-1725257849 gcs-redis-repo frequent-backup 2024-09-02T06:18:01Z Delete Succeeded 15m -gcs-redis-repo-sample-redis-backup-frequent-backup-1725258000 gcs-redis-repo frequent-backup 2024-09-02T06:20:00Z Delete Succeeded 13m -gcs-redis-repo-sample-redis-backup-frequent-backup-1725258300 gcs-redis-repo frequent-backup 2024-09-02T06:25:00Z Delete Succeeded 8m34s -gcs-redis-repo-sample-redis-backup-frequent-backup-1725258600 gcs-redis-repo frequent-backup 2024-09-02T06:30:00Z Delete Succeeded 3m34s +gcs-redis-repo-sample-redis-backup-frequent-backup-1725257849 gcs-redis-repo frequent-backup 2024-09-02T06:18:01Z Delete Succeeded 15m +gcs-redis-repo-sample-redis-backup-frequent-backup-1725258000 gcs-redis-repo frequent-backup 2024-09-02T06:20:00Z Delete Succeeded 13m +gcs-redis-repo-sample-redis-backup-frequent-backup-1725258300 gcs-redis-repo frequent-backup 2024-09-02T06:25:00Z Delete Succeeded 8m34s +gcs-redis-repo-sample-redis-backup-frequent-backup-1725258600 gcs-redis-repo frequent-backup 2024-09-02T06:30:00Z Delete Succeeded 3m34s ``` The below example shows how you can pass a specific snapshot name in `.spec.dataSource` section. diff --git a/docs/guides/redis/backup/kubestash/customization/restore/passing-args.yaml b/docs/guides/redis/backup/kubestash/customization/restore/passing-args.yaml index d8193107f4..a829fe3d34 100644 --- a/docs/guides/redis/backup/kubestash/customization/restore/passing-args.yaml +++ b/docs/guides/redis/backup/kubestash/customization/restore/passing-args.yaml @@ -20,4 +20,4 @@ spec: tasks: - name: logical-backup-restore params: - args: --dbname=testdb \ No newline at end of file + args: "--pipe-timeout 300" \ No newline at end of file From 993587e875f8610fe9a7dcaa8da571d5f209f8e3 Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Fri, 20 Sep 2024 16:51:29 +0600 Subject: [PATCH 08/11] make build pass Signed-off-by: Neaj Morshad --- .../application-level/examples/restoresession.yaml | 6 +++--- .../redis/backup/kubestash/application-level/index.md | 6 +++--- docs/guides/redis/backup/stash/auto-backup/index.md | 6 +++--- docs/guides/redis/backup/stash/overview/index.md | 4 ++-- docs/guides/redis/backup/stash/standalone/index.md | 2 +- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/guides/redis/backup/kubestash/application-level/examples/restoresession.yaml b/docs/guides/redis/backup/kubestash/application-level/examples/restoresession.yaml index 0c02e2989c..4d7db7205c 100644 --- a/docs/guides/redis/backup/kubestash/application-level/examples/restoresession.yaml +++ b/docs/guides/redis/backup/kubestash/application-level/examples/restoresession.yaml @@ -6,8 +6,8 @@ metadata: spec: manifestOptions: restoreNamespace: dev - redis: - db: true +# redis: +# db: true dataSource: repository: gcs-redis-repo snapshot: latest @@ -18,4 +18,4 @@ spec: name: redis-addon tasks: - name: logical-backup-restore - - name: manifest-restore \ No newline at end of file +# - name: manifest-restore \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/application-level/index.md b/docs/guides/redis/backup/kubestash/application-level/index.md index 875275cd7b..e19d443d72 100644 --- a/docs/guides/redis/backup/kubestash/application-level/index.md +++ b/docs/guides/redis/backup/kubestash/application-level/index.md @@ -549,8 +549,8 @@ metadata: spec: manifestOptions: restoreNamespace: dev - redis: - db: true +# redis: +# db: true dataSource: repository: gcs-redis-repo snapshot: latest @@ -561,7 +561,7 @@ spec: name: redis-addon tasks: - name: logical-backup-restore - - name: manifest-restore +# - name: manifest-restore ``` Here, diff --git a/docs/guides/redis/backup/stash/auto-backup/index.md b/docs/guides/redis/backup/stash/auto-backup/index.md index a5b78b49b5..566cedc34e 100644 --- a/docs/guides/redis/backup/stash/auto-backup/index.md +++ b/docs/guides/redis/backup/stash/auto-backup/index.md @@ -280,7 +280,7 @@ app-sample-redis-1-1627567808 BackupConfiguration app-sample-redis-1 Succe 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 `prefix` field of the `Repository`.
- Backup data in GCS Bucket + Backup data in GCS Bucket
Fig: Backup data in GCS Bucket
@@ -462,7 +462,7 @@ app-sample-redis-2-1627568283 BackupConfiguration app-sample-redis-2 Succe Once the backup has been completed successfully, you should see that Stash has created a new directory as pointed by the `prefix` field of the new `Repository` and stored the backed up data there.
- Backup data in GCS Bucket + Backup data in GCS Bucket
Fig: Backup data in GCS Bucket
@@ -643,7 +643,7 @@ app-sample-redis-3-1627568709 BackupConfiguration app-sample-redis-3 Succe Once the backup has been completed successfully, you should see that Stash has created a new directory as pointed by the `prefix` field of the new `Repository` and stored the backed up data there.
- Backup data in GCS Bucket + Backup data in GCS Bucket
Fig: Backup data in GCS Bucket
diff --git a/docs/guides/redis/backup/stash/overview/index.md b/docs/guides/redis/backup/stash/overview/index.md index 2ee01a4a96..233e586380 100644 --- a/docs/guides/redis/backup/stash/overview/index.md +++ b/docs/guides/redis/backup/stash/overview/index.md @@ -36,7 +36,7 @@ Stash supports taking logical backup of Redis databases using [redis-dump-go](ht The following diagram shows how Stash takes logical backup of a Redis database. Open the image in a new tab to see the enlarged version.
-  Redis Backup Overview +  Redis Backup Overview
Fig: Redis Logical Backup Overview
@@ -71,7 +71,7 @@ The backup process consists of the following steps: The following diagram shows how Stash restores a Redis database from a logical backup. Open the image in a new tab to see the enlarged version.
-  Database Restore Overview +  Database Restore Overview
Fig: Redis Logical Restore Process Overview
diff --git a/docs/guides/redis/backup/stash/standalone/index.md b/docs/guides/redis/backup/stash/standalone/index.md index 8d126b344f..56fe0fa51b 100644 --- a/docs/guides/redis/backup/stash/standalone/index.md +++ b/docs/guides/redis/backup/stash/standalone/index.md @@ -369,7 +369,7 @@ gcs-repo true 1.327 MiB 1 60s 8m Now, if we navigate to the GCS bucket, we will see the backed up data has been stored in `demo/redis/sample-redis` directory as specified by `.spec.backend.gcs.prefix` field of the `Repository` object.
- Backup data in GCS Bucket + Backup data in GCS Bucket
Fig: Backup data in GCS Bucket
From 760154e49e3284fdf7a81b030bd0c7b5d9af92fa Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Fri, 20 Sep 2024 17:39:30 +0600 Subject: [PATCH 09/11] review changes Signed-off-by: Neaj Morshad --- docs/guides/redis/backup/kubestash/_index.md | 2 +- docs/guides/redis/backup/kubestash/application-level/index.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/guides/redis/backup/kubestash/_index.md b/docs/guides/redis/backup/kubestash/_index.md index 51888b1792..17513ac187 100644 --- a/docs/guides/redis/backup/kubestash/_index.md +++ b/docs/guides/redis/backup/kubestash/_index.md @@ -7,4 +7,4 @@  parent: guides-rd-backup  weight: 50 menu_name: docs_{{ .version }} ---- \ No newline at end of file +--- \ No newline at end of file diff --git a/docs/guides/redis/backup/kubestash/application-level/index.md b/docs/guides/redis/backup/kubestash/application-level/index.md index e19d443d72..0b396d00ce 100644 --- a/docs/guides/redis/backup/kubestash/application-level/index.md +++ b/docs/guides/redis/backup/kubestash/application-level/index.md @@ -597,7 +597,7 @@ In this section, we will verify whether the desired `Redis` database manifest ha ```bash $ kubectl get redis -n dev NAME VERSION STATUS AGE -sample-redis 16.1 Ready 9m46s +sample-redis 7.4.0 Ready 9m46s ``` The output confirms that the `Redis` database has been successfully created with the same configuration as it had at the time of backup. From d6306ce4acfbd9d4f129c99eb1ca9cd7e106c45e Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Fri, 20 Sep 2024 18:46:03 +0600 Subject: [PATCH 10/11] fix index Signed-off-by: Neaj Morshad --- docs/guides/redis/backup/_index.md | 10 ++++++++++ docs/guides/redis/backup/kubestash/_index.md | 16 ++++++++-------- docs/guides/redis/backup/stash/_index.md | 12 ++++++------ .../redis/backup/stash/auto-backup/index.md | 2 +- .../redis/backup/stash/customization/index.md | 2 +- docs/guides/redis/backup/stash/overview/index.md | 2 +- .../redis/backup/stash/standalone/index.md | 2 +- 7 files changed, 28 insertions(+), 18 deletions(-) create mode 100644 docs/guides/redis/backup/_index.md diff --git a/docs/guides/redis/backup/_index.md b/docs/guides/redis/backup/_index.md new file mode 100644 index 0000000000..2b500db3a7 --- /dev/null +++ b/docs/guides/redis/backup/_index.md @@ -0,0 +1,10 @@ +--- +title: Backup and Restore Redis +menu: + docs_{{ .version }}: + identifier: rd-guides-redis-backup + name: Backup & Restore + parent: rd-redis-guides + weight: 50 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/redis/backup/kubestash/_index.md b/docs/guides/redis/backup/kubestash/_index.md index 17513ac187..8104f984ad 100644 --- a/docs/guides/redis/backup/kubestash/_index.md +++ b/docs/guides/redis/backup/kubestash/_index.md @@ -1,10 +1,10 @@ --- -title: Backup & Restore Redis | KubeStash -menu: - docs_{{ .version }}: - identifier: guides-rd-backup-stashv2 - name: KubeStash (aka Stash 2.0) - parent: guides-rd-backup - weight: 50 -menu_name: docs_{{ .version }} +title: Backup & Restore Redis | KubeStash +menu: + docs_{{ .version }}: + identifier: guides-rd-backup-stashv2 + name: KubeStash (aka Stash 2.0) + parent: rd-guides-redis-backup + weight: 20 +menu_name: docs_{{ .version }} --- \ No newline at end of file diff --git a/docs/guides/redis/backup/stash/_index.md b/docs/guides/redis/backup/stash/_index.md index 4b2b5cdf85..364aca95a9 100644 --- a/docs/guides/redis/backup/stash/_index.md +++ b/docs/guides/redis/backup/stash/_index.md @@ -1,10 +1,10 @@ --- -title: Backup and Restore Redis +title: Backup & Restore Redis | Stash menu: docs_{{ .version }}: - identifier: rd-guides-redis-backup - name: Backup - parent: rd-redis-guides - weight: 50 + identifier: guides-rd-backup-stashv1 + name: Stash + parent: rd-guides-redis-backup + weight: 10 menu_name: docs_{{ .version }} ---- +--- \ No newline at end of file diff --git a/docs/guides/redis/backup/stash/auto-backup/index.md b/docs/guides/redis/backup/stash/auto-backup/index.md index 566cedc34e..bb2c6b6dbd 100644 --- a/docs/guides/redis/backup/stash/auto-backup/index.md +++ b/docs/guides/redis/backup/stash/auto-backup/index.md @@ -5,7 +5,7 @@ menu: docs_{{ .version }}: identifier: rd-auto-backup-kubedb name: Auto-Backup - parent: rd-guides-redis-backup + parent: guides-rd-backup-stashv1 weight: 30 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/redis/backup/stash/customization/index.md b/docs/guides/redis/backup/stash/customization/index.md index 1c48da9a38..207078fb60 100644 --- a/docs/guides/redis/backup/stash/customization/index.md +++ b/docs/guides/redis/backup/stash/customization/index.md @@ -5,7 +5,7 @@ menu: docs_{{ .version }}: identifier: rd-backup-customization-kubedb name: Customizing Backup & Restore Process - parent: rd-guides-redis-backup + parent: guides-rd-backup-stashv1 weight: 40 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/redis/backup/stash/overview/index.md b/docs/guides/redis/backup/stash/overview/index.md index 233e586380..90251de15a 100644 --- a/docs/guides/redis/backup/stash/overview/index.md +++ b/docs/guides/redis/backup/stash/overview/index.md @@ -4,7 +4,7 @@ menu: docs_{{ .version }}: identifier: rd-backup-overview name: Overview - parent: rd-guides-redis-backup + parent: guides-rd-backup-stashv1 weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/redis/backup/stash/standalone/index.md b/docs/guides/redis/backup/stash/standalone/index.md index 56fe0fa51b..ae55db1445 100644 --- a/docs/guides/redis/backup/stash/standalone/index.md +++ b/docs/guides/redis/backup/stash/standalone/index.md @@ -5,7 +5,7 @@ menu: docs_{{ .version }}: identifier: rd-backup-standalone name: Standalone - parent: rd-guides-redis-backup + parent: guides-rd-backup-stashv1 weight: 20 menu_name: docs_{{ .version }} section_menu_id: guides From c21fd637b95b343628fa646efc4475e08e797c2c Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Tue, 24 Sep 2024 11:05:50 +0600 Subject: [PATCH 11/11] stash link -> kubestash link Signed-off-by: Neaj Morshad --- docs/guides/redis/initialization/using-script.md | 2 +- docs/guides/redis/reconfigure-tls/sentinel.md | 2 +- docs/guides/redis/reconfigure-tls/standalone.md | 2 +- docs/guides/redis/tls/cluster.md | 2 +- docs/guides/redis/tls/sentinel.md | 2 +- docs/guides/redis/tls/standalone.md | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/guides/redis/initialization/using-script.md b/docs/guides/redis/initialization/using-script.md index 113829bc56..3be23d17ac 100644 --- a/docs/guides/redis/initialization/using-script.md +++ b/docs/guides/redis/initialization/using-script.md @@ -428,7 +428,7 @@ kubectl delete ns demo ## Next Steps -- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. +- [Backup and Restore](/docs/guides/redis/backup/kubestash/overview/index.md) Redis databases using KubeStash. - Initialize [Redis with Script](/docs/guides/redis/initialization/using-script.md). - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). diff --git a/docs/guides/redis/reconfigure-tls/sentinel.md b/docs/guides/redis/reconfigure-tls/sentinel.md index d4e31ccb9b..832265ff38 100644 --- a/docs/guides/redis/reconfigure-tls/sentinel.md +++ b/docs/guides/redis/reconfigure-tls/sentinel.md @@ -517,6 +517,6 @@ redissentinelopsrequest.ops.kubedb.com "sen-ops-rotate" deleted ## Next Steps - Detail concepts of [Redis object](/docs/guides/redis/concepts/redis.md). -- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. . +- [Backup and Restore](/docs/guides/redis/backup/kubestash/overview/index.md) Redis databases using KubeStash. . - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). diff --git a/docs/guides/redis/reconfigure-tls/standalone.md b/docs/guides/redis/reconfigure-tls/standalone.md index 927efa8519..d67247f2a3 100644 --- a/docs/guides/redis/reconfigure-tls/standalone.md +++ b/docs/guides/redis/reconfigure-tls/standalone.md @@ -483,6 +483,6 @@ redisopsrequest.ops.kubedb.com "rd-change-issuer" deleted ## Next Steps - Detail concepts of [Redis object](/docs/guides/redis/concepts/redis.md). -- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. . +- [Backup and Restore](/docs/guides/redis/backup/kubestash/overview/index.md) Redis databases using KubeStash. . - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). diff --git a/docs/guides/redis/tls/cluster.md b/docs/guides/redis/tls/cluster.md index e0475ec7ef..d4b78c349f 100644 --- a/docs/guides/redis/tls/cluster.md +++ b/docs/guides/redis/tls/cluster.md @@ -197,7 +197,7 @@ issuer.cert-manager.io "redis-ca-issuer" deleted ## Next Steps - Detail concepts of [Redis object](/docs/guides/redis/concepts/redis.md). -- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. . +- [Backup and Restore](/docs/guides/redis/backup/kubestash/overview/index.md) Redis databases using KubeStash. . - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). diff --git a/docs/guides/redis/tls/sentinel.md b/docs/guides/redis/tls/sentinel.md index 30df02eaa0..93213805bd 100644 --- a/docs/guides/redis/tls/sentinel.md +++ b/docs/guides/redis/tls/sentinel.md @@ -281,6 +281,6 @@ clusterissuer.cert-manager.io "redis-ca-issuer" deleted ## Next Steps - Detail concepts of [Redis object](/docs/guides/redis/concepts/redis.md). -- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. . +- [Backup and Restore](/docs/guides/redis/backup/kubestash/overview/index.md) Redis databases using KubeStash. . - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md). diff --git a/docs/guides/redis/tls/standalone.md b/docs/guides/redis/tls/standalone.md index 378f412617..11ffad2fe0 100644 --- a/docs/guides/redis/tls/standalone.md +++ b/docs/guides/redis/tls/standalone.md @@ -193,6 +193,6 @@ issuer.cert-manager.io "redis-ca-issuer" deleted ## Next Steps - Detail concepts of [Redis object](/docs/guides/redis/concepts/redis.md). -- [Backup and Restore](/docs/guides/redis/backup/stash/overview/index.md) Redis databases using Stash. . +- [Backup and Restore](/docs/guides/redis/backup/kubestash/overview/index.md) Redis databases using KubeStash. . - Monitor your Redis database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/redis/monitoring/using-prometheus-operator.md). - Monitor your Redis database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/redis/monitoring/using-builtin-prometheus.md).