[[["容易理解","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-07-22 (世界標準時間)。"],[],[],null,["| **Preview**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nThis document describes how to back up and restore Google Distributed Cloud version\n1.32 and higher admin and user clusters that have\n[advanced cluster](/kubernetes-engine/distributed-cloud/vmware/docs/concepts/advanced-clusters) enabled.\n| **Warning:** Using a backup file to restore your cluster is a last resort. The restore process resets the existing cluster and overwrites the cluster information. We don't recommend restoring from a backup file unless the cluster has failed catastrophically. Contact Cloud Customer Care for help in deciding the best course of action.\n\nThe `gkectl` backup and restore process does not include persistent volumes. Any\nvolumes created by the local volume provisioner (LVP) are left unaltered.\n\nBack up a cluster\n\nThe `gkectl backup cluster` command adds the cluster information from the etcd\nstore and the PKI certificates for the specified cluster to a tar file. The etcd\nstore is the Kubernetes backing store for all cluster data and contains all the\nKubernetes objects and custom objects required to manage cluster state. The PKI\ncertificates are used for authentication over Transport Layer Security (TLS).\nThis data is backed up from the cluster's control plane or from one of the\ncontrol planes for a high-availability (HA) deployment.\n\nThe backup tar file contains sensitive credentials, including your service\naccount keys and the SSH key. Store backup files in a secure location. To\nprevent unintended file exposure, the backup process uses in-memory files only.\n\nBack up your clusters regularly to ensure your snapshot data is relatively\ncurrent. Adjust the rate of backups to reflect the frequency of significant\nchanges to your clusters.\n\nBefore you begin, ensure your cluster is operating properly, with working\ncredentials and SSH connectivity to all nodes. The intent of the backup process\nis to capture your cluster in a known good state so that you can restore\noperation if a catastrophic failure occurs.\n\nTo back up a cluster:\n\n1. Run the following command to check your\n cluster:\n\n gkectl diagnose cluster --cluster-name \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --kubeconfig \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster you plan to back\n up.\n\n - \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e: the path of the kubeconfig file for\n the admin cluster.\n\n2. Run the applicable command to back up the cluster:\n\n Admin cluster \n\n gkectl backup admin --kubeconfig \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e\n\n User cluster \n\n gkectl backup cluster --cluster-name \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --kubeconfig \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e\n\nBy default, the backup tar file is saved to the directory\n`gkectl-workspace/backups` on your admin workstation. The tar file is named\n\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`_backup_`\u003cvar translate=\"no\"\u003eTIMESTAMP\u003c/var\u003e`.tar.gz`,\nwhere \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e is the name of the\ncluster being backed up and \u003cvar translate=\"no\"\u003eTIMESTAMP\u003c/var\u003e is the date and time\nthe backup was made. For example, if the cluster name is `testuser`, the backup\nfile has a name like `testuser_backup_2006-01-02T150405Z0700.tar.gz`.\nTo specify a different name and location for your backup file, use the\n`--backup-file` flag.\n\nThe backup file expires after a year and the cluster restore process doesn't\nwork with expired backup files.\n\nThe backup file can also be uploaded to your vCenter Server, if the following\nsection is configured to the [admin cluster configuration file:\nclusterBackup](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/admin-cluster-configuration-file-latest): \n\n datastore: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eDATASTORE\u003c/span\u003e\u003c/var\u003e\n\nReplace \u003cvar translate=\"no\"\u003eDATASTORE\u003c/var\u003e with the datastore where you want to\nstore the backup. The datastore must be in the same datacenter as the admin\ncluster. The backups are located in the\n`anthos/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`/backup` directory of the specified\ndatastore.\n\nRestore a cluster\n\nRestoring a cluster from a backup is a last resort and should only be used when a\ncluster has failed catastrophically and can't be returned to service any other\nway. For example, the etcd data is corrupted or the etcd Pod is in a crash loop.\n| **Note:** To improve cluster performance, Google Distributed Cloud uses a separate etcd instance to store Event objects. These Event objects have a time to live (TTL) of one hour. The cluster restore operation creates a new, empty etcd-events instance, so you lose existing Event objects. However, the loss of Event objects has no impact on cluster operation. Events should be treated as informative, best-effort, supplemental data only.\n\nThe backup tar file contains sensitive credentials, including your service\naccount keys and the SSH key. To prevent unintended file exposure, the\nGoogle Distributed Cloud restore process uses in-memory files only.\n\nBefore you restore a cluster, make sure that the following conditions are met:\n\n- Ensure all control-plane node machines that were available for the cluster at the time of the backup are operating properly and reachable.\n- Ensure that SSH connectivity between nodes works with the SSH keys that were used at the time of the backup. These SSH keys are reinstated as part of the restore process.\n- Ensure that the service-account keys that were used at the time of the backup are still active. These service-account keys are reinstated for the restored cluster.\n\nTo restore a cluster:\n\n1. Run the applicable command to restore the cluster:\n\n Admin cluster \n\n gkectl restore admin --backup-file \u003cvar translate=\"no\"\u003eBACKUP_FILE\u003c/var\u003e \\\n --config \u003cvar translate=\"no\"\u003eADMIN_CONFIG\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eBACKUP_FILE\u003c/var\u003e: the path and name of the backup file you\n are using.\n\n - \u003cvar translate=\"no\"\u003eADMIN_CONFIG\u003c/var\u003e: the path to the admin cluster config\n file.\n\n User cluster \n\n gkectl restore cluster --cluster-name \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --backup-file \u003cvar translate=\"no\"\u003eBACKUP_FILE\u003c/var\u003e \\\n --kubeconfig \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster you are\n restoring.\n\n - \u003cvar translate=\"no\"\u003eBACKUP_FILE\u003c/var\u003e: the path and name of the backup file you\n are using.\n\n - \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e: the path to the admin cluster\n kubeconfig file.\n\n At the end of the restore process, a new kubeconfig file is generated for the\n restored cluster at the workspace directory `gkectl-workspace`.\n2. When the restore finishes, run the following command to verify that it was\n successful:\n\n gkectl diagnose cluster --cluster-name \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --kubeconfig \u003cvar translate=\"no\"\u003eGENERATED_KUBECONFIG\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eGENERATED_KUBECONFIG\u003c/var\u003e with the generated kubeconfig\n file.\n\nTroubleshoot\n\nIf you have problems with the backup or restore process, the following sections\nmight help you to troubleshoot the issue.\n\nIf you need additional assistance, reach out to the Cloud Customer Care team.\n\nRunning out of memory during a backup or restore\n\nIf the workstation where you run the `gkectl` command doesn't have a lot of RAM,\nyou might have insufficient memory to perform the backup or restore process. If\nneeded, create and use a temporary scratch disk to process the backup or restore\noperations by using the `--use-disk` parameter in the backup command. To\npreserve the file permissions, this parameter modifies permissions of the files,\nso it requires that you run the command as a root user (or use `sudo`).\n\nRefresh of SSH key after a backup breaks the restore process\n\nSSH-related operations during the restore process might fail if the SSH key is\nrefreshed after a backup was performed. In this case, the new SSH key becomes\ninvalid for the restore process. To resolve this issue, you can temporarily add\nthe original SSH key back, then perform the restore. After the restore process\nis complete, you can rotate the SSH key."]]