Alur kerja berikut menjelaskan langkah-langkah cloning:
Konfigurasi file pgbackrest.conf untuk mengakses cadangan Cloud Storage.
Gunakan perintah pgBackRest untuk memverifikasi bahwa cadangan sumber dapat diakses.
Gunakan perintah pgBackRest untuk memulihkan cadangan ke server target.
Sebelum memulai
Akses ke jalur lengkap bucket Cloud Storage tempat backup cluster database sumber Anda berada. Ini adalah jalur yang sama dengan yang Anda gunakan saat membuat resource BackupPlan untuk cluster database sumber.
Cluster database AlloyDB Omni target server tunggal dibuat. Untuk mengetahui informasi selengkapnya tentang cara menginstal AlloyDB Omni di Kubernetes, lihat Menginstal AlloyDB Omni.
Pastikan Anda login ke database sebagai pengguna postgres.
Mengonfigurasi file pgBackRest di server target
Konfigurasi file pgBackRest untuk memungkinkan cluster database target mengakses bucket Cloud Storage tempat cadangan sumber berada.
Di server target, buka direktori alloydb-data.
Buat file konfigurasi pgBackRest untuk mengakses cadangan yang disimpan di Cloud Storage:
GCS_SOURCE_BACKUP_BUCKET_NAME: nama bucket Cloud Storage pgBackRest yang Anda buat di cluster database sumber. Ini bukan URL lengkap ke bucket; jangan menambahkan awalan gs:// ke nama bucket.
GCS_SOURCE_BACKUP_BUCKET_PATH: jalur direktori tempat operator
AlloyDB Omni menulis cadangan, dalam bucket
Cloud Storage untuk cluster database sumber. Jalur harus absolut, dimulai dengan /.
repo1-gcs-key-type ditetapkan ke auto untuk menggunakan akun layanan instance. Untuk mengetahui informasi selengkapnya tentang opsi lainnya, lihat Opsi Jenis Kunci Repositori GCS.
Memverifikasi cadangan sumber di server target
Login ke server target dan jalankan perintah pgBackRest untuk memverifikasi bahwa cadangan cluster database sumber dapat diakses di server target:
Stempel waktu dalam respons digunakan untuk memulihkan cadangan penuh atau memulihkan dari titik waktu dalam periode pemulihan.
Pulihkan cadangan di server target
Setelah Anda mengidentifikasi cadangan atau titik waktu yang ingin dipulihkan, jalankan perintah pgBackRest di server target Anda. Untuk mengetahui informasi selengkapnya
tentang perintah ini, lihat Perintah
Restore.
Berikut beberapa contoh perintah pemulihan pgBackRest:
Setelah perintah pemulihan berhasil diselesaikan, Anda dapat menyalin data dari direktori sementara /mnt/disks/pgsql/data-restored ke direktori /alloydb-data/data saat ini.
Di server target, hentikan layanan database:
Docker
dockerstopCONTAINER_NAME
Podman
podmanstopCONTAINER_NAME
Ganti nama direktori data saat ini menjadi nama lain sebagai praktik terbaik:
mv~/alloydb-data/data~/alloydb-data/data-old
Ganti nama direktori sementara data-restored menjadi direktori data saat ini:
mv~/alloydb-data/data-restored~/alloydb-data/data
Perbarui nilai pg1-path dalam file postgresql.auto.conf untuk memuat data yang dipulihkan:
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'
Di server target, mulai layanan database:
Docker
dockerstartCONTAINER_NAME
Podman
podmanstartCONTAINER_NAME
Setelah layanan database dimulai, Anda dapat terhubung ke instance utama dan menjalankan kueri untuk memverifikasi bahwa data dipulihkan dari cadangan. Untuk mengetahui informasi selengkapnya, lihat Menghubungkan ke AlloyDB Omni di satu server.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)"]]
