[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-08-19 (世界標準時間)。"],[[["\u003cp\u003eApigee hybrid's backup and restore feature creates backups of hybrid data, allowing restoration to previous states in disaster scenarios, with backup availability and retention dependent on the user's infrastructure.\u003c/p\u003e\n"],["\u003cp\u003eOnly Cassandra data requires backing up, as other Apigee hybrid components are stateless and can be reinstalled using existing overrides during recovery, and data backups should not be stored within Kubernetes nodes of the hybrid cluster.\u003c/p\u003e\n"],["\u003cp\u003eCassandra backups are crucial for disaster recovery, creating snapshots of data, schema, and metadata, and they are not enabled by default but should be for protection against data loss from catastrophic failures.\u003c/p\u003e\n"],["\u003cp\u003eBackups are created based on a schedule defined in the \u003ccode\u003eoverrides.yaml\u003c/code\u003e file, which then triggers a backup script on each Cassandra node, archiving data and sending it to Cloud Storage or a remote server.\u003c/p\u003e\n"],["\u003cp\u003eApigee hybrid supports two backup methods: one using Kubernetes CSI snapshots (recommended for Google Cloud, AWS, or Azure) and another non-CSI method for on-prem installations, and in both the user configures backup in the \u003ccode\u003eoverrides.yaml\u003c/code\u003e file.\u003c/p\u003e\n"]]],[],null,["# Cassandra backup overview\n\n| You are currently viewing version 1.9 of the Apigee hybrid documentation. **This version is end of life.** You should upgrade to a newer version. For more information, see [Supported versions](/apigee/docs/hybrid/supported-platforms#supported-versions).\n\nApigee hybrid backup and restore feature lets you create backups of the hybrid data\nand, in case of disaster scenarios, restore the data to previous working snapshots. Backup\navailability and retention is based on the backup infrastructure provided by you.\n\nA typical installation of Apigee hybrid consists of the following components:\n\n- MART (admin service)\n- Controller and Watcher (manage Kubernetes objects)\n- Istio (manages Ingress)\n- Runtime, Sync, and UDCA (one per environment)\n- Telemetry (monitoring and logging)\n- Cert manager (manages certificates)\n- Datastores (Cassandra and Redis databases)\n\nAll the components except for Cassandra are stateless and do not persist any data.\nBackup and restoration is not necessary for those components. During recovery, reinstallation of those\ncomponents using the existing overrides is sufficient.\n| **Note:**We recommend that you do not store your backup in a Kubernetes node inside your Apigee hybrid cluster. If you do so, Kubernetes nodes can be autoscaled, the host filesystem can be deleted, and instances can be terminated. You should store your backup in a network volume mount. Generally, a server used for storing backups should have high availability so that backups can be recovered from different locations.\n\nWhy take backups of Cassandra?\n------------------------------\n\n\nBackups are an important measure of protection against disaster scenarios. Each backup acts as a\nconsistent snapshot of the Cassandra data existing at the time the backup is\ncreated. In addition to Cassandra data, this snapshot includes schema and metadata within the Cassandra\ncluster. In the event of a disaster, backups enable you to restore your hybrid instance to a\npreviously operational state. Depending on the size of the hybrid instance, a single backup set may contain\none or more backup files.\n\nWhat you need to know about Cassandra backups?\n----------------------------------------------\n\nCassandra is a replicated database that is configured to have at least three copies of your data\nin each region or data center. Cassandra uses streaming replication and read repairs to maintain\nthe data replicas in each region or data center at any given point.\n\nIn hybrid, Cassandra backups are **not** enabled by default. It's a good practice to\nenable Cassandra backups in the event your data is lost to a catastrophic failure. Cassandra\nbackups are intended for use in cases of disaster recovery and not for restoring data loss caused\nby accidental deletion.\n\nBackups are created according to the schedule set in your `overrides.yaml` file. Once\na backup schedule is applied to your hybrid cluster, a Kubernetes backup job is executed according to the schedule.\nThe job triggers a backup script on each Cassandra node in your hybrid cluster that collects all the data on the\nnode, creates an archive file of the data, and sends the archive to Cloud Storage or a directory on a\nremote server.\n| **Note:**\n|\n| - Take a backup of the overrides.yaml files(s).\n| - Backup of Kubernetes entities like Secrets, Certificates, and ConfigMaps are out of scope of this document. Please consult your Kubernetes vendor for the backup procedure of such Kubernetes entities.\n\nWhat is backed up?\n------------------\n\n\nThe hybrid scheduled backup is a complete backup of the persisted runtime data\nstored in Apigee's Cassandra at the time of backup. Any data modifications after the backup\ntime will not be available in the backup. The scheduled\nbackup consist of the following entities:\n\n- Cassandra schema, including the user schema (Apigee keyspace definitions).\n- Cassandra partition token information per Cassandra node in a cluster.\n- A snapshot of the Cassandra data.\n\nWhere is backup data stored?\n----------------------------\n\nThe location of the backup data depends on your backup method. Apigee hybrid supports the following\nmethods for taking backups:\n\n- **Backup in Cloud Storage** : Backup is stored in the configured Cloud Storage\n buckets in your Google Cloud Project.\n- **Backup in a remote server**: Backup is stored in a directory on a remote server specified by you.\n\nHow the data is secured?\n------------------------\n\nIf you are using Cloud Storage for backup, the backup data is encrypted by default.\nIn case of backups not on Cloud Storage, backup data is encrypted during the transfer to the remote\nserver. But after the transfer, you must ensure that the backup data is encrypted in the remote server.\n\nHow to take backups?\n--------------------\n\nUse one of these two methods to configure backups. For both methods, you'll\nconfigure backup in your `overrides.yaml` file. Apigee recommends you make a\ncopy of the `overrides.yaml` file, so that you can reuse it during the recovery process.\n\n- Use [Apigee hybrid CSI backup and restore](/apigee/docs/hybrid/v1.9/cassandra-csi-backup-restore), which uses Kubernetes CSI (Container Storage Interface) snapshots. This method is recommended for hybrid instances hosted in Google Cloud, AWS, or Azure.\n- Use non-CSI hybrid backup and restore, which copies schema and other data to backup files. This is the recommended method for on-prem installations. The following sections describe in detail how to schedule backups in Cloud Storage and\n in a remote server.\n\n - [Scheduling backups in Cloud Storage](/apigee/docs/hybrid/v1.9/schedule-cassandra-backup-gcs)\n - [Scheduling backups in a remote server](/apigee/docs/hybrid/v1.9/schedule-cassandra-backup-non-gcs)"]]
