手動復元を作成するには、復元する既存のバックアップが必要です。GDC コンソールまたは API を使用して手動復元を作成します。この API を使用すると、ManualRestoreRequest リソースを作成して、バックアップからのデータ復元をリクエストできます。このリソースは、復元の名前、使用する復元プラン、復元元のバックアップを指定します。
復元プランとバックアップは、リクエストと同じ Namespace に存在している必要があります。この API は、復元プロセスのステータス更新を提供し、すべての復元リクエストを一覧表示できます。詳細については、復元を作成するをご覧ください。
[[["わかりやすい","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\u003eManual restores in Google Distributed Cloud (GDC) air-gapped allow you to recover data from a backup at any time, recreating Kubernetes resources in the target cluster.\u003c/p\u003e\n"],["\u003cp\u003eRestores can be performed from imported backups originating from different clusters, requiring the creation of a backup repository in the target cluster that points to the source cluster's storage location.\u003c/p\u003e\n"],["\u003cp\u003eFine-grained restores provide control over which resources are restored from a backup, enabling the restoration of a subset of resources based on inclusion and exclusion filters.\u003c/p\u003e\n"],["\u003cp\u003eFine-grained restore plans are limited to \u003ccode\u003eMergeSkipOnConflict\u003c/code\u003e or \u003ccode\u003eMergeReplaceOnConflict\u003c/code\u003e conflict-handling modes, and they support filtering by GroupKind, Namespace, Name, and Labels, following an order of inclusion then exclusion.\u003c/p\u003e\n"]]],[],null,["# Manual restore overview\n\nThis page provides an overview of the manual restore creation options in Google Distributed Cloud (GDC) air-gapped.\n\nCreate a manual restore of a backup to recover your data at any time.\n\nWhen a backup is restored, the Kubernetes resources are recreated in the target\ncluster. After the resources are created, actual restoration of workload\nfunctionality is subject to the regular cluster reconciliation process. For example, pods are scheduled to nodes and then started on those nodes.\n\nRestore from an imported backup\n-------------------------------\n\nYou can restore a backup from another backup that was completed in a different\ncluster. For example, restore a backup from an imported backup if the original\ncluster is inactive or you want to clone an existing cluster.\n\nFirst, create a backup repository in the target cluster that points to the\nstorage location used by the source cluster. If the repository is\nactively being used by the source cluster in `ReadWrite` mode, you must specify the `ImportPolicy` as `ReadOnly`. For more information, see\n[Backup repository import policies](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/add-backup-repository#backup-repo-import-policies).\n\nAfter creating the backup repository and successfully importing the backups, the repository backup resources are present in the target cluster.\nYou can then schedule a restore in the target cluster by referencing an imported\nbackup.\n\nManual restore overview\n-----------------------\n\nTo create a manual restore, you must have an existing backup to restore. Create\na manual restore in the GDC console or using the API. The API lets you\nrequest data restoration from a backup by creating a `ManualRestoreRequest`\nresource. This resource specifies the name of the restore, the restore plan to use,\nand the backup to restore from.\n\nThe restore plan and backup must exist in the same\nnamespace as the request. The API provides status updates on the restore process\nand lets you list all restore requests. For more information, see [Create a\nrestore](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/cluster-backup/restore-backup#create-a-restore).\n\nIf you want more control over the resources that are restored, see [Fine-grained restore overview](#fine-grained-restore-overview).\n\nFine-grained restore overview\n-----------------------------\n\nThe fine-grained restore feature lets you restore a subset of resources from a\nbackup. This feature provides the flexibility\nto refine the restore scope defined in the restore plan. If the fine-grained\nrestore scope has no overlap with the original scope defined in the restore\nplan, no resources are restored.\n\nYou can enable the fine-grained restore feature for restore plans with these\nindividual resource level conflict handling modes:\n\n- `MergeSkipOnConflict`: conflicting resources that are encountered during the restore are skipped.\n- `MergeReplaceOnConflict`: conflicting resources that are encountered during the restore process are replaced by the resources in the backup you are restoring.\n\nTo use fine-grained restores, create a restore plan\nor update the `namespacedResourceRestoreMode` field of an existing\nrestore plan to a value of `MergeSkipOnConflict` or\n`MergeReplaceOnConflict`. The namespace conflict handling modes of `FailOnConflict` or `DeleteAndRestore` are not supported.\nFor more information about the restore modes, see\nthe `namespacedResourceRestoreMode` field in [Create a restore plan](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/cluster-backup/plan-restores#create-restore-plan).\n\n### Inclusion and exclusion filters\n\nWhen you create a fine-grained restore, you define one or more filter\nconditions under the inclusion and exclusion filters. These filters let you\nselect or exclude a subset of resources from the backup for restoration. You can\ndefine inclusion and exclusion filters simultaneously. When both are specified,\nthe following order is followed:\n\n- If inclusion filters are used, the restore only includes resources matching those filters.\n- If exclusion filters are used, the restore excludes matching resources from the restore process.\n- When both inclusion and exclusion filters are specified, the restore applies inclusion filters first, followed by exclusion filters.\n- If no filters are specified, the restore is performed on the entire scope defined in the parent restore plan.\n\nYou can include four optional attributes when constructing a filter condition:\n\n- `GroupKind`: the Kubernetes API group and kind for the resource.\n- `Namespace`: the namespace for namespace scoped resources.\n- `Name`: the name of the resource.\n- `Labels`: the key-value pairs to select resources based on Kubernetes. For more information on labels, see \u003chttps://kubernetes.io/docs/concepts/overview/working-with-objects/labels/\u003e.\n\nYou can use a combination of the preceding four attributes to define a filter\ncondition. If more than one attribute is specified, the relationship between\nattributes is considered as `AND`. A resource is selected if it matches all\nattributes defined in the filter condition.\n\nYou can also provide multiple filter conditions at the same time. The\nrelationship between the different filter conditions is `OR`. A resource is\nselected if it matches any filter condition. A maximum of 50 filters are allowed, and\neach filter can have 50 label key-value pairs.\n\nWhat's next\n-----------\n\n- [Create a restore](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/cluster-backup/restore-backup)\n- [Create a fine-grained restore](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/cluster-backup/fine-grained-restore)"]]