[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-25。"],[[["\u003cp\u003eAlloyDB offers two primary methods for data protection: continuous backup and recovery, which enables restoring a cluster to any point in its recent history, and discrete file-based backups, which provide complete copies of a cluster's databases.\u003c/p\u003e\n"],["\u003cp\u003eContinuous backup and recovery is enabled by default, allowing restoration to any point within a defined time window (default of 14 days, configurable from 1 to 35 days), facilitating a recovery point objective (RPO) of zero.\u003c/p\u003e\n"],["\u003cp\u003eDiscrete backups can be created on-demand as full backups or through an automated schedule as incremental backups, with configurable retention periods up to one year, and are independent of the original cluster.\u003c/p\u003e\n"],["\u003cp\u003eBackups in AlloyDB, managed by its storage layer, do not impact the read and write performance of clusters, and can be stored in the same region as the cluster by default or in a specified cross-region location.\u003c/p\u003e\n"],["\u003cp\u003eRestoring clusters in AlloyDB can be done either by specifying a source cluster and a timestamp for a point-in-time recovery, or by specifying a backup file.\u003c/p\u003e\n"]]],[],null,["# Data backup and recovery overview\n\nThis page describes the backup and recovery features that\nyou can use to protect your data in AlloyDB for PostgreSQL databases.\n\nAlloyDB provides two ways to back up and recover your data:\n\n- *Continuous backup and recovery*, enabled on all clusters by default,\n is an AlloyDB feature that lets you create a new a cluster\n based on any recent state of another cluster in the same project and\n region.\n\n- Discrete *backups* are file-based resources that contain complete\n copies of your cluster's databases. AlloyDB\n creates them on-demand, or according to a regular schedule that you\n define. You can restore any of these backups into new clusters.\n\nContinuous backup and recovery\n------------------------------\n\nAlloyDB lets you restore an existing cluster to any\nmoment from its recent history, with microsecond granularity. By\ndefault, AlloyDB lets you choose any point in time up to\n14 days into the past. You can [configure your\ncluster](/alloydb/docs/backup/configure#continuous) to resize this\nwindow to as long as 35 days, or as short as one day.\n\nContinuous backup and recovery is especially useful for restoring a\ncluster after an accidental large-scale data deletion, or any other\nsituation where you need to rapidly recreate a cluster's state based on\nsome point in the recent past.\n\nIn disaster-recovery terms, continuous backup and recovery lets\nAlloyDB have a [recovery point objective\n(RPO)](/architecture/dr-scenarios-planning-guide#basics_of_dr_planning)\nof zero. In other words, you can restore your cluster to the state that it held\nmoments before a catastrophic incident, without the permanent loss of any data.\n\nYou can also use continuous backup and recovery to [make an independent clone of\na healthy cluster](/alloydb/docs/cluster-create#clone),\nwith all its data copied over from the present moment.\n\nOn-demand or automated backups\n------------------------------\n\nIn AlloyDB, a backup is a file-based resource\ncontaining a copy of a cluster's data from a particular moment in time.\n\nAlloyDB has three ways of creating backups:\n\n- AlloyDB always creates one backup every\n day as part of its continuous backup\n and recovery system, unless you disable this feature.\n\n Continuous backups are *incremental backups*:\n AlloyDB stores only the data that changed relative to\n previous backups. This approach keeps the backup files as small as possible,\n which helps to reduce your backup storage costs. These backups vary in size,\n depending on factors such as how much data is written since the last\n backup. Full continuous backups are also taken periodically; the backup size is\n similar to the cluster size.\n- You can create an [on-demand\n backup](/alloydb/docs/backup/create-on-demand) at any time using the\n Google Cloud CLI, the Google Cloud console, or the API.\n\n On-demand backups are *full backups*: each backup includes all\n the data that was in its cluster's databases when the backup operation\n began.\n- If you enable an [automated backup](/alloydb/docs/backup/configure)\n schedule, then AlloyDB creates additional backups\n regularly, according to your preferences.\n\n Automated backups are incremental, similar to continuous backups. If\n you configure automated backups to use a retention window longer\n than 35 days, then AlloyDB might store multiple\n chains of incremental backups to cover the necessary time span.\n\nAs with your cluster's databases, AlloyDB encrypts\nbackup data through either the default Google-managed encryption or\n[customer-managed encryption keys](/alloydb/docs/cmek).\n\n### Backup creation requirements\n\nAlloyDB\nprepares to create a new backup by checking the following about the\ncluster to back up:\n\n- The cluster's [state](/alloydb/docs/reference/rest/v1/projects.locations.clusters#state) is `Ready`.\n- The cluster has a primary instance.\n- The primary instance's [state](/alloydb/docs/reference/rest/v1/projects.locations.clusters.instances#state) is `Ready`.\n\nIf all of these checks pass, then AlloyDB starts a long-running\noperation to create the backup.\n\n### Backups are efficient and independent\n\nBackups you create from your AlloyDB data are managed\nentirely by AlloyDB's storage layer. This means that\nbackup and restore operations have no impact on the read and write\nperformance of your AlloyDB cluster, as they are\nperformed by separate resources from those that store and query that\ncluster's data.\n\nThis separation of storage resources also means a backup exists\nindependently from its original cluster. You can restore from that backup\neven if its source cluster has been deleted.\n\nTo learn more about how AlloyDB's storage layer enables this, see [AlloyDB for\nPostgreSQL under the hood: Intelligent, database-aware storage](https://cloud.google.com/blog/products/databases/alloydb-for-postgresql-intelligent-scalable-storage).\n\nOn-demand backups locations\n---------------------------\n\nFor [on-demand backups](/alloydb/docs/backup/overview#automated), AlloyDB backup locations include:\n\n- [Default location](#default-backup-location) that AlloyDB selects, based on the location of the original cluster.\n- [Cross-region location](#cross-region-backup-location) that you specify when you don't want to use the default location.\n\n### Default backup location\n\nIf you don't specify a storage location, your backups are stored in the location of your AlloyDB cluster. For example, if your AlloyDB instance is in `us-central1 (Iowa)`, your backups are stored in the `us-central1 (Iowa)` location by default.\n\n### Cross-region backup location\n\nAlloyDB lets you select a custom cross-region location for your backup data, which expands the set of regions where you can store your backups. This is useful for retaining the ability to restore if your cluster region becomes unavailable.\n\nWhen selecting a cross-region location for a backup, consider the following:\n\n- **Cost:** pricing may differ between the regions.\n- **Proximity to your application server:** you might want to store the backup as close to your serving application as possible.\n\n| **Note:** If you change the location where backups are stored, existing backups remain in their original location.\n\nCluster restoration\n-------------------\n\nYou can restore a cluster in AlloyDB by creating a new\ncluster that contains all of the original cluster's data from some point in\nthe past. The two ways that you can specify this point correspond to the\ntwo general kinds of backups that AlloyDB supports:\n\n- To perform a point-in-time restore of a cluster's recent state, specify both a\n source cluster and a timestamp when creating a new cluster. The new cluster must\n be in the same region as the source cluster, but can be in a different\n Google Cloud project.\n\n- To restore a cluster from a backup, specify that backup when creating a new\n cluster. The new cluster must be in the same region as the backup, but can be\n in a different Google Cloud project.\n\nIn both cases, AlloyDB creates\na new cluster and then initiates a long-running operation to load the\nbacked-up data into that cluster's storage. After this operation\ncompletes, you create a primary instance in that cluster to\naccess the data.\n\nCluster restores occur in the same region, but on-demand backups can be stored cross-region.\nBackups and restores are supported across different Google Cloud projects and organizations.\n\nTo learn more, see [Restore from a backup](/alloydb/docs/backup/restore).\n\nBackup retention and deletion\n-----------------------------\n\nThe files that AlloyDB creates to enable continuous\nbackup and recovery have a default retention period of 14 days. You can\nadjust this period to any number of days between 1 and 35, or you can\ndisable continuous backup to prevent AlloyDB from\nretaining these files at all.\n\nOn-demand and automated backups have a retention period of up to one\nyear. If you enable automated backups on your cluster, you can either set\na retention period, or use the default period of 14 days.\n\nBackups older than their retention period might still appear when you\n[view your project's backups](/alloydb/docs/backup/list). Expired\nbackups don't incur storage costs, but they are subject to automated\ndeletion. If you need to delete backups before the system deletes them,\nyou can [manually delete your backups](/alloydb/docs/backup/delete).\n\nWhat's next\n-----------\n\n- Learn how to [restore a cluster](/alloydb/docs/backup/restore).\n\n- Learn how to [manually create an on-demand\n backup](/alloydb/docs/backup/create-on-demand).\n\n- Learn how to [configure backup plans](/alloydb/docs/backup/configure),\n including automated backups and continuous backup.\n\n- Learn more about [backups in AlloyDB](/alloydb/docs/backup/overview)."]]
