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'
[[["์ดํดํ๊ธฐ ์ฌ์","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-08-17(UTC)"],[[["\u003cp\u003eThis guide demonstrates how to clone a database cluster on a single server by restoring from a Cloud Storage backup using \u003ccode\u003epgBackRest\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eThe process begins by configuring the \u003ccode\u003epgbackrest.conf\u003c/code\u003e file on the target server to grant access to the Cloud Storage bucket containing the source database cluster's backups.\u003c/p\u003e\n"],["\u003cp\u003eYou can verify the availability of the source backups in the target server using \u003ccode\u003epgBackRest\u003c/code\u003e commands, ensuring they can be accessed before the restoration.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003epgBackRest\u003c/code\u003e commands are used to restore the backup to the target server, allowing you to restore from a specific backup set or to a point-in-time.\u003c/p\u003e\n"],["\u003cp\u003eAfter the backup is restored to a temporary directory, you will replace the original data directory with the restored one and then restart the database to complete the process.\u003c/p\u003e\n"]]],[],null,["# Clone a database cluster in a single server using a Cloud Storage backup\n\nSelect a documentation version: Current (16.8.0)keyboard_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/current/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/current/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/current/docs/kubernetes-dr-backup-singleserver-local)"]]
