[[["容易理解","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 (世界標準時間)。"],[],[],null,["# Data protection with multi-zone storage\n\nThis document provides information for protecting your application data in a\nGoogle Distributed Cloud (GDC) air-gapped multi-zone universe. To maintain highly available\napplications, you can implement a data protection strategy that is resilient to\nlocal outages or failures. GDC provides data replication\nstrategies for\n[object storage](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/storage#object_storage) and\n[block storage](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/storage#block_storage) so you can\nmaintain failover procedures for primary and secondary zones in your universe.\n\nThis document is for IT administrators within the platform administrator group\nwho are responsible for developing disaster recovery workflows, and application\ndevelopers within the application operator group who are responsible for\ndeveloping and maintaining applications in a GDC\nuniverse.\n\nFor more information, see\n[Audiences for GDC air-gapped documentation](/distributed-cloud/hosted/docs/latest/gdch/resources/audiences).\n\nStorage replication for disaster recovery\n-----------------------------------------\n\nYou can set up robust data protection for your application storage in a\nmulti-zone universe using *asynchronous data replication* for disaster recovery.\nThis approach involves copying data from a primary zone to a secondary zone at\nperiodic intervals. This mechanism keeps your data protected and accessible if\nthe primary zone experiences an outage.\n\nData replication for object storage uses dual zone buckets to automatically\nreplicate your data, and doesn't require manual intervention. For more\ninformation about creating a dual zone bucket, see\n[Create storage buckets](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/create-storage-buckets#cli).\n\nData replication for block storage uses dual zone persistent volumes to\nreplicate your data, and requires a volume failover procedure. For more\ninformation, see\n[Replicate volumes asynchronously](/distributed-cloud/hosted/docs/latest/gdch/application/ao-user/async-block-replication).\n\nAfter you configure data replication, your data follows a *failover procedure*\nwhen the primary zone is offline. The failover procedures are distinct for block\nand object storage replication. However, both data replication strategies use\nthe following critical steps:\n\n1. Verify the primary zone outage.\n2. Stop the replication from the primary zone.\n3. Promote the backup secondary zone to assume the role of the primary zone with manual intervention or a pre-configured failover.\n4. Verify the operational status of the new primary zone.\n\nReach out to a member of the infrastructure operator group to confirm your two\nzones are configured for asynchronous data replication.\n\nThe inherent delay that comes with asynchronous data replication means that this\nsetup is most useful for systems that require a low, but non-zero recovery point\nobjective (RPO). If your system requires minimal data loss, but can tolerate a\nsmall predefined maximum amount of data loss measured in time, usually related\nto data generated just immediately before a disaster event that could be\npotentially unrecoverable, then asynchronous data replication is a valuable\nfeature to implement for your applications.\n| **Important:** Synchronous data replication is not supported. Synchronous data replication maintains strict consistency between data in two zones by immediately duplicating all data written from a primary zone to the secondary zone, which provides zero RPO in disaster scenarios.\n\nAn example of a low non-zero RPO might be a financial trading platform with an\nRPO of five minutes, where asynchronous data replication is set to copy trade\ndata to a secondary disaster recovery zone every two minutes:\n\n- This is a *low RPO* scenario because the five minutes represents the minimum acceptable data loss window for the high-volume system.\n- It's a *non-zero RPO* scenario because the inherent delay in asynchronous replication of two minute intervals means that there is a small window of time where data has not yet been copied, resulting in potential loss.\n\nYou must work with your infrastructure operator group to define your dual zone\nasynchronous storage replication workflow, and verify the infrastructure's data\nreplication capabilities support your RPO requirements.\n\nWhat's next\n-----------\n\n- [High availability for your apps](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/ha-apps/overview)\n- [Deploy a highly available VM application](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/ha-apps/deploy-ha-vm-app)\n- [Deploy a highly available container application](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/ha-apps/deploy-ha-container-app)"]]