The following workflow explains the cloning steps:
Configure thepgbackrest.conffile to access the Cloud Storage backup.
UsepgBackRestcommands to verify source backups can be accessed.
UsepgBackRestcommands to restore the backup to the target server.
Before you begin
Access to the full path of the Cloud Storage bucket where your source database cluster backup resides. This is the same path you used when you created theBackupPlanresource for your source database cluster.
A single server target AlloyDB Omni database cluster is created. For more information about installing AlloyDB Omni on Kubernetes, seeInstall AlloyDB Omni.
Ensure you are logged in to the database as thepostgresuser.
Configure thepgBackRestfile on the target server
Configure thepgBackRestfile to enable the target database cluster to access the Cloud Storage bucket where source backups reside.
In the target server, navigate to thealloydb-datadirectory.
Create apgBackRestconfiguration file to access backups stored in Cloud Storage:
GCS_SOURCE_BACKUP_BUCKET_NAME: the name of the Cloud StoragepgBackRestbucket you created in the source database cluster. This is
not the full URL to the bucket; don't prefix the bucket name withgs://.
GCS_SOURCE_BACKUP_BUCKET_PATH: the path of the directory that the
AlloyDB Omni operator writes backups into, within the
Cloud Storage bucket for the source database cluster. The path
must be absolute, beginning with/.
Therepo1-gcs-key-typeis set toautoto use the instance's service account. For more information about other options, seeGCS Repository Key Type Option.
Verify source backups in target server
Sign in to the target server and runpgBackRestcommands to verify that the source database cluster backups are accessible on the target server:
The timestamps in the response are used either to restore the full backup or to restore
from a point in time from the recovery window.
Restore the backup in the target server
After you identify the backup or a point in time you want to restore to, runpgBackRestcommands in your target server. For more information
about these commands, seeRestore
Command.
The following are some samplepgBackRestrestore commands:
After the restore command completes successfully, you can copy the data from the/mnt/disks/pgsql/data-restoredtemporary directory to the current/alloydb-data/datadirectory.
In the target server, stop the database service:
Docker
dockerstopCONTAINER_NAME
Podman
podmanstopCONTAINER_NAME
Rename the current data directory to another name as a best practice:
mv~/alloydb-data/data~/alloydb-data/data-old
Rename thedata-restoredtemporary directory to the current data directory:
mv~/alloydb-data/data-restored~/alloydb-data/data
Updatepg1-pathvalue in thepostgresql.auto.conffile to load the restored data:
vim~/alloydb-data/data/postgresql.auto.conf# Verify postgresql.auto.conf.# Do not edit this file manually!# It will be overwritten by the ALTER SYSTEM command.# Recovery settings generated by pgBackRest restore on 2024-03-13 20:47:11restore_command='pgbackrest --config-path=/mnt/disks/pgsql --pg1-path=/mnt/disks/pgsql/data --repo=1 --stanza=db archive-get %f "%p"'recovery_target='immediate'recovery_target_action='promote'recovery_target_timeline='current'
In the target server, start the database service:
Docker
dockerstartCONTAINER_NAME
Podman
podmanstartCONTAINER_NAME
After the database service starts, you can connect to the primary instance and run queries to verify that the data is restored from the backup. For more information, seeConnect to AlloyDB Omni on a single server.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eThis guide demonstrates how to clone a database cluster on a single server by using a backup stored in Cloud Storage.\u003c/p\u003e\n"],["\u003cp\u003eThe process requires configuring the \u003ccode\u003epgBackRest\u003c/code\u003e file on the target server to enable access to the Cloud Storage bucket containing the source database backups.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003epgBackRest\u003c/code\u003e commands are used to verify the source backups are accessible and to restore the chosen backup to the target server, either from a full backup or from a specific point in time.\u003c/p\u003e\n"],["\u003cp\u003eAfter the restore is completed, the backed up data must be copied to the current database directory and then a service restart is required for the changes to be applied and the data to be accessible.\u003c/p\u003e\n"],["\u003cp\u003eTo confirm that the restore was completed correctly, one can connect to the primary instance and run queries to verify data integrity.\u003c/p\u003e\n"]]],[],null,["# Clone a database cluster in a single server using a Cloud Storage backup\n\nSelect a documentation version: 15.7.0keyboard_arrow_down\n\n- [Current (16.8.0)](/alloydb/omni/current/docs/kubernetes-dr-backup-singleserver-gcs)\n- [16.8.0](/alloydb/omni/16.8.0/docs/kubernetes-dr-backup-singleserver-gcs)\n- [16.3.0](/alloydb/omni/16.3.0/docs/kubernetes-dr-backup-singleserver-gcs)\n- [15.12.0](/alloydb/omni/15.12.0/docs/kubernetes-dr-backup-singleserver-gcs)\n- [15.7.1](/alloydb/omni/15.7.1/docs/kubernetes-dr-backup-singleserver-gcs)\n- [15.7.0](/alloydb/omni/15.7.0/docs/kubernetes-dr-backup-singleserver-gcs)\n- [15.5.5](/alloydb/omni/15.5.5/docs/kubernetes-dr-backup-singleserver-gcs)\n- [15.5.4](/alloydb/omni/15.5.4/docs/kubernetes-dr-backup-singleserver-gcs)\n- [15.5.2](/alloydb/omni/15.5.2/docs/kubernetes-dr-backup-singleserver-gcs)\n\n\u003cbr /\u003e\n\nThis page show you how to clone a database cluster in a single server using a Cloud Storage backup.\n\n\u003cbr /\u003e\n\nThe following workflow explains the cloning steps:\n\n1. Configure the `pgbackrest.conf` file to access the Cloud Storage backup.\n2. Use `pgBackRest` commands to verify source backups can be accessed.\n3. Use `pgBackRest` commands to restore the backup to the target server.\n\nBefore you begin\n----------------\n\n- Access to the full path of the Cloud Storage bucket where your source database cluster backup resides. This is the same path you used when you created the `BackupPlan` resource for your source database cluster.\n- A single server target AlloyDB Omni database cluster is created. For more information about installing AlloyDB Omni on Kubernetes, see [Install AlloyDB Omni](/alloydb/omni/15.7.0/docs/quickstart).\n- Ensure you are logged in to the database as the `postgres` user.\n\nConfigure the `pgBackRest` file on the target server\n----------------------------------------------------\n\nConfigure the `pgBackRest` file to enable the target database cluster to access the Cloud Storage bucket where source backups reside.\n\n1. In the target server, navigate to the `alloydb-data` directory.\n\n2. Create a `pgBackRest` configuration file to access backups stored in Cloud Storage:\n\n $ cat \u003c\u003c EOF \u003e /backup/pgbackrest.conf\n [db]\n pg1-path=/mnt/disks/pgsql/data-restored\n pg1-socket-path=/tmp\n pg1-user=pgbackrest\n [global]\n log-path=/obs/pgbackrest\n log-level-file=info\n repo1-type=gcs\n repo1-gcs-bucket=\u003cvar translate=\"no\"\u003eGCS_SOURCE_BACKUP_BUCKET_NAME\u003c/var\u003e\n repo1-path=\u003cvar translate=\"no\"\u003eGCS_SOURCE_BACKUP_BUCKET_PATH\u003c/var\u003e\n repo1-storage-ca-file=/etc/ssl/certs/ca-certificates.crt\n repo1-retention-full=9999999\n repo1-gcs-key-type=auto\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eGCS_SOURCE_BACKUP_BUCKET_NAME\u003c/var\u003e: the name of the Cloud Storage `pgBackRest` bucket you created in the source database cluster. This is not the full URL to the bucket; don't prefix the bucket name with `gs://`.\n - \u003cvar translate=\"no\"\u003eGCS_SOURCE_BACKUP_BUCKET_PATH\u003c/var\u003e: the path of the directory that the AlloyDB Omni operator writes backups into, within the Cloud Storage bucket for the source database cluster. The path must be absolute, beginning with `/`.\n\n The `repo1-gcs-key-type` is set to `auto` to use the instance's service account. For more information about other options, see [GCS Repository Key Type Option](https://pgbackrest.org/configuration.html#section-repository/option-repo-gcs-key-type).\n\nVerify source backups in target server\n--------------------------------------\n\nSign in to the target server and run `pgBackRest` commands to verify that the source database cluster backups are accessible on the target server: \n\n### Docker\n\n sudo docker exec \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e pgbackrest --config-path=/mnt/disks/pgsql --stanza=db --repo=1 info\n\n### Podman\n\n sudo podman exec \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e pgbackrest --config-path=/mnt/disks/pgsql --stanza=db --repo=1 info\n\nReplace \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e with the name of a new AlloyDB Omni container---for example, `my-omni-1`.\n\nThe following is a sample response: \n\n stanza: db\n status: ok\n cipher: none\n db (current)\n wal archive min/max (15): 000000010000000000000002/00000001000000000000000D\n full backup: 20240213-231400F\n timestamp start/stop: 2024-02-13 23:14:00+00 / 2024-02-13 23:17:14+00\n wal start/stop: 000000010000000000000003 / 000000010000000000000003\n database size: 38.7MB, database backup size: 38.7MB\n repo1: backup set size: 4.6MB, backup size: 4.6MB\n incr backup: 20240213-231400F_20240214-000001I\n timestamp start/stop: 2024-02-14 00:00:01+00 / 2024-02-14 00:00:05+00\n wal start/stop: 00000001000000000000000D / 00000001000000000000000D\n database size: 38.7MB, database backup size: 488.3KB\n repo1: backup set size: 4.6MB, backup size: 84.2KB\n backup reference list: 20240213-231400F\n\nThe timestamps in the response are used either to restore the full backup or to restore\nfrom a point in time from the recovery window.\n\nRestore the backup in the target server\n---------------------------------------\n\nAfter you identify the backup or a point in time you want to restore to, run\n`pgBackRest` commands in your target server. For more information\nabout these commands, see [Restore\nCommand](https://pgbackrest.org/command.html#command-restore).\n\nThe following are some sample `pgBackRest` restore commands:\n\n- Restore from a backup\n\n pgbackrest --config-path=/mnt/disks/pgsql --stanza=db --repo=1 restore --set=20240213-231400F --type=immediate --target-action=promote --delta --link-all --log-level-console=info\n\n- Restore from a point in time\n\n pgbackrest --config-path=/mnt/disks/pgsql --stanza=db --repo=1 restore --target=\"2024-01-22 11:27:22\" --type=time --target-action=promote --delta --link-all --log-level-console=info\n\nCopy data to the target server\n------------------------------\n\nAfter the restore command completes successfully, you can copy the data from the `/mnt/disks/pgsql/data-restored` temporary directory to the current `/alloydb-data/data` directory.\n\n1. In the target server, stop the database service:\n\n### Docker\n\n docker stop \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e\n\n### Podman\n\n podman stop \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e\n\n1. Rename the current data directory to another name as a best practice:\n\n mv ~/alloydb-data/data ~/alloydb-data/data-old\n\n2. Rename the `data-restored` temporary directory to the current data directory:\n\n mv ~/alloydb-data/data-restored ~/alloydb-data/data\n\n3. Update `pg1-path` value in the `postgresql.auto.conf` file to load the restored data:\n\n vim ~/alloydb-data/data/postgresql.auto.conf\n # Verify postgresql.auto.conf.\n # Do not edit this file manually!\n # It will be overwritten by the ALTER SYSTEM command.\n # Recovery settings generated by pgBackRest restore on 2024-03-13 20:47:11\n restore_command = 'pgbackrest --config-path=/mnt/disks/pgsql --pg1-path=/mnt/disks/pgsql/data --repo=1 --stanza=db archive-get %f \"%p\"'\n recovery_target = 'immediate'\n recovery_target_action = 'promote'\n recovery_target_timeline = 'current'\n\n1. In the target server, start the database service:\n\n ### Docker\n\n docker start \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e\n\n ### Podman\n\n podman start \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e\n\nAfter the database service starts, you can connect to the primary instance and run queries to verify that the data is restored from the backup. For more information, see [Connect to AlloyDB Omni on a single server](/alloydb/omni/15.7.0/docs/run-connect#connect).\n\nWhat's next\n-----------\n\n- [Clone a database cluster in a single server using a local backup](/alloydb/omni/15.7.0/docs/kubernetes-dr-backup-singleserver-local)"]]
