Apigee Hybrid 백업 및 복원 기능을 사용하면 하이브리드 데이터 백업을 만들고 재해 발생 시 데이터를 이전 작업 스냅샷으로 복원할 수 있습니다. 백업 가용성과 보관은 개발자가 제공하는 백업 인프라를 기반으로 합니다.
Apigee Hybrid의 일반적인 설치는 다음 구성요소로 구성됩니다.
MART(관리자 서비스)
컨트롤러 및 감시자(Kubernetes 객체 관리)
Istio(인그레스 관리)
런타임, 동기화, UDCA(환경당 하나)
원격 분석(모니터링 및 로깅)
인증서 관리자(인증서 관리)
Datastore(Cassandra 및 Redis 데이터베이스)
Cassandra를 제외한 모든 구성요소는 스테이트리스(Stateless)이며 어떠한 데이터도 유지되지 않습니다.
이러한 구성요소에는 백업 및 복원이 필요하지 않습니다. 복구 중에는 기존 재정의를 사용하여 구성요소를 다시 설치하는 것으로 충분합니다.
Cassandra를 백업하는 이유
백업은 재해 시나리오에 대비할 수 있는 중요한 보호 수단입니다. 각 백업은 백업이 생성될 때 존재하는 Cassandra 데이터의 일관된 스냅샷 역할을 합니다. Cassandra 데이터 외에도 이 스냅샷에는 Cassandra 클러스터 내의 스키마와 메타데이터가 포함됩니다. 재해가 발생할 경우 백업을 사용하면 하이브리드 인스턴스를 이전 작동 상태로 복원할 수 있습니다. 하이브리드 인스턴스의 크기에 따라 단일 백업 세트에 하나 이상의 백업 파일이 포함될 수 있습니다.
Cassandra 백업에 대해 알아야 할 사항
Cassandra는 각 리전 또는 데이터 센터에 데이터 복사본이 최소 3개 이상 있도록 구성된 복제된 데이터베이스입니다. Cassandra는 스트리밍 복제 및 읽기 복구를 사용하여 특정 시점에 각 리전 또는 데이터 센터의 데이터 복제본을 유지합니다.
하이브리드에서 Cassandra 백업은 기본적으로 사용 설정되지 않습니다. 치명적인 오류로 인해 데이터가 손실된 경우에 대비하여 Cassandra 백업을 사용 설정하는 것이 좋습니다. Cassandra 백업은 재해 복구 시 사용하기 위한 것이며 실수로 삭제하여 손실된 데이터를 복원하기 위한 것이 아닙니다.
백업은 overrides.yaml 파일에 설정된 일정에 따라 생성됩니다. 백업 일정이 하이브리드 클러스터에 적용되면 일정에 따라 Kubernetes 백업 작업이 실행됩니다.
이 작업은 하이브리드 클러스터의 각 Cassandra 노드에서 노드의 모든 데이터를 수집하고, 데이터의 보관 파일을 만들고, Cloud Storage 또는 원격 서버의 디렉터리로 보관 파일을 보내는 백업 스크립트를 트리거합니다.
백업되는 항목
하이브리드 예약 백업은 백업 시 Apigee의 Cassandra에 저장된 지속 런타임 데이터의 전체 백업입니다. 백업 시간 이후에는 백업에서 데이터를 수정할 수 없습니다. 예약 백업은 다음 항목으로 구성됩니다.
사용자 스키마를 포함한 Cassandra 스키마(Apigee 키스페이스 정의)
클러스터의 Cassandra 노드당 Cassandra 파티션 토큰 정보입니다.
Cassandra 데이터의 스냅샷
백업 데이터가 저장되는 위치
백업 데이터 위치는 백업 방법에 따라 다릅니다. Apigee Hybrid에서는 다음과 같은 백업 방법을 지원합니다.
[[["이해하기 쉬움","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-09-04(UTC)"],[[["\u003cp\u003eApigee hybrid's backup and restore feature creates backups of hybrid data, allowing restoration to previous snapshots in disaster scenarios, with backup availability and retention dependent on the user's infrastructure.\u003c/p\u003e\n"],["\u003cp\u003eWhile most Apigee hybrid components are stateless and do not require backups, Cassandra is the main exception, as it stores persistent data and requires backups for disaster recovery.\u003c/p\u003e\n"],["\u003cp\u003eCassandra backups are not enabled by default, but are crucial for disaster recovery, providing a consistent snapshot of Cassandra data, schema, and metadata at the time of the backup.\u003c/p\u003e\n"],["\u003cp\u003eBackups are created on a schedule defined in the \u003ccode\u003eoverrides.yaml\u003c/code\u003e file, which triggers a Kubernetes job to archive data from each Cassandra node and store it either in Cloud Storage or on a designated remote server.\u003c/p\u003e\n"],["\u003cp\u003eThe hybrid backup process focuses on the Cassandra data, and it is recommended that Kubernetes entities (such as secrets, certificates, and ConfigMaps) be backed up separately using a Kubernetes vendor-specific procedure, alongside backing up the overrides.yaml file.\u003c/p\u003e\n"]]],[],null,["# Cassandra backup overview\n\n| You are currently viewing version 1.14 of the Apigee hybrid documentation. 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\n| **Note:** Timestamps included in the names of files and snapshots are in UTC.\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.14/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.14/schedule-cassandra-backup-gcs)\n - [Scheduling backups in a remote server](/apigee/docs/hybrid/v1.14/schedule-cassandra-backup-non-gcs)"]]
