이 전략은 선택한 포드의 사본 하나를 백업합니다. 이 단일 사본이 복원 중 모든 포드를 복원하기 위한 소스입니다. 이 메서드는 스토리지 비용 및 백업 시간을 줄이는 데 도움이 됩니다. 이 전략은 구성요소가 하나의 기본 PersistentVolumeClaim과 여러 개의 보조 PersistentVolumeClaims로 배포되는 고가용성 구성에서 사용됩니다.
하나만 백업하여 모두 복원 전략의 경우 리소스 정의에 다음 정보를 포함해야 합니다.
백업 대상: 데이터 백업에 사용할 Deployment 또는 StatefulSet를 지정합니다. 최상의 백업 포드가 자동으로 선택됩니다. 고가용성 구성에서는 보조 PersistentVolumeClaim에서 백업하는 것이 좋습니다.
후크: 애플리케이션 정지 및 정지 해제 단계와 같이 볼륨 백업 수행 전후에 실행되는 명령어를 정의합니다. 이러한 명령어는 선택된 백업 포드에서만 실행됩니다.
볼륨 선택: 구성요소 내에서 백업 및 복원되는 볼륨을 더 세밀하게 제어할 수 있습니다.
구성요소가 여러 개의 Deployment 또는 StatefulSet 리소스로 구성된 경우 모든 리소스의 PersistentVolume 구조가 동일해야 하며 다음 규칙을 따라야 합니다.
모든 Deployment 또는 StatefulSet 리소스에 사용되는 PersistentVolumeClaim 리소스 수가 동일해야 합니다.
동일한 색인에 있는 PersistentVolumeClaim 리소스의 목적이 동일해야 합니다. StatefulSet 리소스의 경우 색인이 volumeClaimTemplate에 정의됩니다. Deployment 리소스의 경우 색인이 Volume 리소스에 정의되고 모든 비영구 볼륨을 건너뜁니다.
이러한 조건들을 고려하면 백업에 여러 개의 볼륨 집합을 선택할 수 있지만 각 볼륨 집합에서 하나의 볼륨만 선택됩니다.
이 예시에서는 기본 StatefulSet 하나와 보조 StatefulSet 하나로 이뤄진 구조를 가정해서 보조 StatefulSet에 있는 단일 포드 내 볼륨의 백업과 다른 모든 볼륨에 대한 복원을 보여줍니다.
[[["이해하기 쉬움","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\u003eGoogle Distributed Cloud (GDC) air-gapped offers protected application strategies to manage backup and restore processes, including pre- and post-execution hooks for custom behaviors.\u003c/p\u003e\n"],["\u003cp\u003eThere are three primary backup and restore strategies for \u003ccode\u003eProtectedApplication\u003c/code\u003e resources: backing up and restoring all, backing up one and restoring all, and a dump-and-load method.\u003c/p\u003e\n"],["\u003cp\u003eThe "backup all and restore all" strategy is ideal for standalone applications, backing up and restoring every resource within the application component.\u003c/p\u003e\n"],["\u003cp\u003eThe "backup one and restore all" strategy is designed for high-availability setups, backing up a single pod's data and using it to restore all other pods.\u003c/p\u003e\n"],["\u003cp\u003eThe "dump and load" strategy employs a dedicated volume for backup and restore operations, suitable for scenarios requiring specific data handling, using dump and load hooks.\u003c/p\u003e\n"]]],[],null,["# Protected application strategies\n\nThis page describes the different protected application strategies available in Google Distributed Cloud (GDC) air-gapped.\n\nProtected application strategies lets you run specific pre-execution and post-execution hooks\nand define custom behavior for quiescing, backing up, or restoring a stateful\nworkload.\n\nThere are three backup and restore strategies that you can use when\ndefining a `ProtectedApplication` resource:\n\n- [Back up all and restore all](#backup-all-restore-all)\n- [Back up one and restore all](#backup-one-restore-all)\n- [Dump and load](#dump-load)\n\nStrategy definitions can include the following values:\n\nBack up all and restore all\n---------------------------\n\nThis strategy backs up all of the application resources\nduring the backup, and restores all of those resources during the restore. This\nstrategy works best for standalone applications, where applications have no\nreplication between pods.\n\nFor a backup all and restore all strategy, include the following information in\nthe resource definition:\n\n- **Hooks**: define commands that are executed before and after taking volume\n backups, such as application quiesce and unquiesce steps. These commands are\n executed on all pods within a component.\n\n- **Volume selection**: provides finer granularity on which volumes are backed up\n and restored within the component. Any volumes not selected are not backed up.\n During a restore, any volumes skipped during backup are restored as empty\n volumes.\n\nThis example creates a `ProtectedApplication` resource that quiesces the file\nsystem before backing up the logs volume and unquiesces after the backup: \n\n kind: ProtectedApplication\n apiVersion: gkebackup.gke.io/v1\n metadata:\n name: nginx\n namespace: sales\n spec:\n resourceSelection:\n type: Selector\n selector:\n matchLabels:\n app: nginx\n components:\n - name: nginx-app\n resourceKind: Deployment\n resourceNames: [\"nginx\"]\n strategy:\n type: BackupAllRestoreAll\n backupAllRestoreAll:\n backupPreHooks:\n - name: fsfreeze\n container: nginx\n Commands: [ /sbin/fsfreeze, -f, /var/log/nginx ]\n backupPostHooks:\n - name: fsunfreeze\n container: nginx\n commands: [ /sbin/fsfreeze, -u, /var/log/nginx ]\n\nBack up one and restore all\n---------------------------\n\nThis strategy backs up one copy of a selected pod. This single copy is the\nsource for restoring all pods during a restore. This method can help reduce\nstorage cost and backup time. This strategy works in a high availability\nconfiguration when a component is deployed with one primary\n`PersistentVolumeClaim` and multiple secondary `PersistentVolumeClaims`.\n\nFor a back up one and restore all strategy, you must include the following\ninformation in the resource definition:\n\n- **Backup target** : specifies which `Deployment` or `StatefulSet` to use to back up the data. The best pod to back up is automatically selected. In a high availability configuration, Google recommends to back up from a secondary `PersistentVolumeClaim`.\n- **Hooks**: defines commands that are executed before and after taking volume backups, such as application quiesce and unquiesce steps. These commands are only executed on the selected backup pod.\n- **Volume selection**: provides finer granularity on which volumes are backed up and restored within the component.\n\nIf a component is configured with multiple `Deployment` or `StatefulSet`\nresources, all resources must have the same `PersistentVolume` structure,\nand follow these rules:\n\n- The number of `PersistentVolumeClaim` resources used by all `Deployment` or `StatefulSet` resources must be the same.\n- The purpose of `PersistentVolumeClaim` resources in the same index must be the same. For `StatefulSet` resources, the index is defined in the `volumeClaimTemplate`. For `Deployment` resources, the index is defined in `Volume` resources and any non-persistent volumes are skipped.\n\nGiven these considerations, multiple volume sets can be selected for backup, but\nonly one volume from each volume set is selected.\n\nThis example, assuming an architecture of one primary `StatefulSet` and a\nsecondary `StatefulSet`, shows a backup of the volumes within a single pod in a secondary\n`StatefulSet`, and then a restore to all other volumes: \n\n kind: ProtectedApplication\n apiVersion: gkebackup.gke.io/v1\n metadata:\n name: mariadb\n namespace: mariadb\n spec:\n resourceSelection:\n type: Selector\n selector:\n matchLabels:\n app: mariadb\n components:\n - name: mariadb\n resourceKind: StatefulSet\n resourceNames: [\"mariadb-primary\", \"mariadb-secondary\"]\n strategy:\n type: BackupOneRestoreAll\n backupOneRestoreAll:\n backupTargetName: mariadb-secondary\n backupPreHooks:\n - name: quiesce\n container: mariadb\n command: [...]\n backupPostHooks:\n - name: unquiesce\n container: mariadb\n command: [...]\n\nDump and load\n-------------\n\nThis strategy uses a dedicated volume for backup and restore processes and\nrequires a dedicated `PersistentVolumeClaim` attached to a component that stores\ndump data. For a dump and load strategy, include the following information in\nthe resource definition:\n\n- **Dump target:** specifies which `Deployment` or `StatefulSet` should be used to dump the data. The best pod to back up is automatically selected. In a high availability configuration, it is recommended to back up from a secondary `PersistentVolumeClaim`.\n- **Load target:** specifies which `Deployment` or `StatefulSet` should be used to load the data. The best pod to back up is automatically selected. The load target does not have to be the same as the dump target.\n- **Hooks:** defines the commands that are executed before and after taking volume backups. There are specific hooks you must define for dump and load strategies:\n - **Dump hooks:** defines the hooks that dump the data into the dedicated volume before back up. This hook is executed only on the selected dump pod.\n - **Load hooks:** defines the hooks that load the data after the application starts. This hook is executed only on the selected load pod.\n - **Optional - Post-backup hooks:** defines the hooks that are executed after the dedicated volumes are backed up, such as cleanup steps. This hook is executed only on the selected dump pod.\n- **Volume selection:** specifies all of the dedicated volumes that store the dump data. You must select only one volume for each dump and load pod.\n\nIf the application consists of `Deployments`, each `Deployment` must have\nexactly one replica.\n\nThis example, assuming an architecture of one primary `StatefulSet` and a\nsecondary `StatefulSet` with dedicated `PersistentVolumeClaims` for both primary\nand secondary `StatefulSets`, shows a dump and load strategy: \n\n kind: ProtectedApplication\n apiVersion: gkebackup.gke.io/v1\n metadata:\n name: mariadb\n namespace: mariadb\n spec:\n resourceSelection:\n type: Selector\n selector:\n matchLabels:\n app: mariadb\n components:\n - name: mariadb-dump\n resourceKind: StatefulSet\n resourceNames: [\"mariadb-primary\", \"mariadb-secondary\"]\n backupStrategy:\n type: DumpAndLoad\n DumpAndLoad:\n loadTarget: mariadb-primary\n dumpTarget: mariadb-secondary\n dumpHooks:\n - name: db_dump\n container: mariadb\n commands:\n - bash\n - \"-c\"\n - |\n mysqldump -u root --all-databases \u003e /backup/mysql_backup.dump\n loadHooks:\n - name: db_load\n container: mariadb\n commands:\n - bash\n - \"-c\"\n - |\n mysql -u root \u003c /backup/mysql_backup.sql\n volumeSelector:\n matchLabels:\n gkebackup.gke.io/backup: dedicated-volume\n\nWhat's next\n-----------\n\n- [Plan a set of backups](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/cluster-backup/plan-backups)"]]
