Alur kerja berikut menjelaskan langkah-langkah yang digunakan untuk meng-clone:
Buat dan terapkan file manifes DBCluster di cluster database target dengan parameter livenessProbe dinonaktifkan.
Buat dan konfigurasi file pgbackrest.conf untuk mengakses cadangan Cloud Storage.
Gunakan perintah pgBackRest untuk memverifikasi bahwa Anda dapat mengakses cadangan sumber.
Gunakan perintah pgBackRest untuk memulihkan cadangan ke cluster database target.
Sebelum memulai
Pastikan Anda memiliki akses ke jalur lengkap bucket Cloud Storage tempat backup cluster database sumber Anda disimpan. Ini adalah jalur yang sama yang Anda
gunakan saat membuat resource BackupPlan untuk cluster database sumber.
Buat cluster database AlloyDB Omni target.
Untuk mengetahui informasi selengkapnya tentang cara menginstal AlloyDB Omni di Kubernetes, lihat
Membuat cluster database.
Pastikan Anda login ke database sebagai pengguna postgres.
Membuat cluster database di cluster database target
Buat cluster database dengan menonaktifkan parameter livenessProbe untuk sementara
selama proses pemulihan selesai.
DB_CLUSTER_NAME: nama cluster database ini—misalnya, my-db-cluster.
ENCODED_PASSWORD: sandi login database untuk peran pengguna postgres default, yang dienkode sebagai string base64—misalnya, Q2hhbmdlTWUxMjM= untuk ChangeMe123.
CPU_COUNT: jumlah CPU yang tersedia untuk setiap instance database dalam cluster database ini.
MEMORY_SIZE: jumlah memori per instance database
dari cluster database ini. Sebaiknya tetapkan ini ke 8 gigabyte per CPU. Misalnya, jika Anda menetapkan cpu ke 2 sebelumnya dalam manifes ini, sebaiknya tetapkan memory ke 16Gi.
DISK_SIZE: ukuran disk per instance database—misalnya, 10Gi.
Terapkan file manifes:
kubectlapply-fDBCLUSTER_FILENAME
Ganti kode berikut:
DBCLUSTER_FILENAME: nama file manifes DBCluster
yang dibuat pada langkah sebelumnya.
Gunakan perintah kubectl describe untuk memverifikasi bahwa resource cluster database
berada dalam status READY.
Mengonfigurasi file pgBackRest
Konfigurasi file pgBackRest untuk mengizinkan cluster database target mengakses bucket Cloud Storage tempat cadangan sumber berada.
Di cluster database target, temukan detail pod cluster database:
GCS_SOURCE_BACKUP_BUCKET_NAME: nama bucket Cloud Storage yang Anda buat saat membuat file manifes resource BackupPlan untuk 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 lain, lihat Opsi Jenis Kunci Repository Cloud Storage.
Memverifikasi cadangan sumber di cluster database target
Jalankan perintah pgBackRest untuk memverifikasi bahwa cadangan cluster database sumber dapat diakses di cluster database target.
Stempel waktu dalam respons digunakan untuk memulihkan cadangan penuh atau memulihkan dari titik waktu dalam periode pemulihan.
Memulihkan cadangan di cluster database target
Setelah Anda mengidentifikasi cadangan atau titik waktu yang ingin dipulihkan, jalankan perintah
pgBackRest di cluster database target. Untuk mengetahui informasi selengkapnya
tentang perintah ini, lihat Perintah
Restore.
Berikut beberapa contoh perintah pemulihan pgBackRest:
Setelah perintah pemulihan berhasil diselesaikan, Anda dapat memulai proses postgres.
supervisorctl.parstartpostgres
Setelah proses postgres 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 yang berjalan di
Kubernetes.
[[["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-05 UTC."],[[["\u003cp\u003eThis guide demonstrates how to clone an AlloyDB Omni database cluster in Kubernetes by restoring from a Cloud Storage backup of the source cluster.\u003c/p\u003e\n"],["\u003cp\u003eThe process begins by creating a \u003ccode\u003eDBCluster\u003c/code\u003e manifest on the target cluster with the \u003ccode\u003elivenessProbe\u003c/code\u003e temporarily disabled to allow the restore to complete.\u003c/p\u003e\n"],["\u003cp\u003eConfiguration of the \u003ccode\u003epgBackRest.conf\u003c/code\u003e file is required, ensuring it correctly references the Cloud Storage bucket where the source database backups are stored.\u003c/p\u003e\n"],["\u003cp\u003eVerification of source backups in the target database cluster is achieved using \u003ccode\u003epgBackRest\u003c/code\u003e commands before proceeding with the restore.\u003c/p\u003e\n"],["\u003cp\u003eThe restore process is then completed using specific \u003ccode\u003epgBackRest\u003c/code\u003e commands to restore either from a specific backup set or to a designated point in time.\u003c/p\u003e\n"]]],[],null,["# Clone a database cluster in Kubernetes using a Cloud Storage backup\n\nSelect a documentation version: 16.3.0keyboard_arrow_down\n\n- [Current (16.8.0)](/alloydb/omni/current/docs/kubernetes-dr-backup-k8-gcs)\n- [16.8.0](/alloydb/omni/16.8.0/docs/kubernetes-dr-backup-k8-gcs)\n- [16.3.0](/alloydb/omni/16.3.0/docs/kubernetes-dr-backup-k8-gcs)\n- [15.12.0](/alloydb/omni/15.12.0/docs/kubernetes-dr-backup-k8-gcs)\n- [15.7.1](/alloydb/omni/15.7.1/docs/kubernetes-dr-backup-k8-gcs)\n- [15.7.0](/alloydb/omni/15.7.0/docs/kubernetes-dr-backup-k8-gcs)\n- [15.5.5](/alloydb/omni/15.5.5/docs/kubernetes-dr-backup-k8-gcs)\n- [15.5.4](/alloydb/omni/15.5.4/docs/kubernetes-dr-backup-k8-gcs)\n- [15.5.2](/alloydb/omni/15.5.2/docs/kubernetes-dr-backup-k8-gcs)\n\n\u003cbr /\u003e\n\nThis page shows you how to clone a database cluster in Kubernetes using a Cloud Storage backup of an AlloyDB Omni database cluster.\n\n\u003cbr /\u003e\n\nThe following workflow explains the steps used to clone:\n\n1. Create and apply the `DBCluster` manifest file on the target database cluster with the `livenessProbe` parameter disabled.\n2. Create and configure the `pgbackrest.conf` file to access the Cloud Storage backup.\n3. Use `pgBackRest` commands to verify you can access source backups.\n4. Use `pgBackRest` commands to restore the backup to the target database cluster.\n\nBefore you begin\n----------------\n\n- Make sure you have access to the full path of the Cloud Storage bucket where your source database cluster backup is stored. This is the same path you used when you created the [`BackupPlan`](/alloydb/omni/16.3.0/docs/backup-kubernetes#remote) resource for your source database cluster.\n- Create a target AlloyDB Omni database cluster. For more information about installing AlloyDB Omni on Kubernetes, see [Create a database cluster](/alloydb/omni/16.3.0/docs/deploy-kubernetes#create).\n- Ensure you are logged in to the database as the `postgres` user.\n\nCreate a database cluster in a target database cluster\n------------------------------------------------------\n\nCreate a database cluster by temporarily disabling the `livenessProbe` parameter\nwhile the restore process completes.\n\n1. Create the `DBCluster` resource manifest file:\n\n apiVersion: v1\n kind: Secret\n metadata:\n name: db-pw-\u003cvar translate=\"no\"\u003eDB_CLUSTER_NAME\u003c/var\u003e\n type: Opaque\n data:\n \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-nt\"\u003eDB_CLUSTER_NAME\u003c/span\u003e\u003c/var\u003e: \"\u003cvar translate=\"no\"\u003eENCODED_PASSWORD\u003c/var\u003e\"\n ---\n apiVersion: alloydbomni.dbadmin.goog/v1\n kind: DBCluster\n metadata:\n name: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eDB_CLUSTER_NAME\u003c/span\u003e\u003c/var\u003e\n spec:\n primarySpec:\n availabilityOptions:\n livenessProbe: \"Disabled\"\n adminUser:\n passwordRef:\n name: db-pw-\u003cvar translate=\"no\"\u003eDB_CLUSTER_NAME\u003c/var\u003e\n resources:\n cpu: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eCPU_COUNT\u003c/span\u003e\u003c/var\u003e\n memory: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eMEMORY_SIZE\u003c/span\u003e\u003c/var\u003e\n disks:\n - name: DataDisk\n size: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eDISK_SIZE\u003c/span\u003e\u003c/var\u003e\n storageClass: standard\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eDB_CLUSTER_NAME\u003c/var\u003e: the name of this database cluster---for\n example, `my-db-cluster`.\n\n - \u003cvar translate=\"no\"\u003eENCODED_PASSWORD\u003c/var\u003e: the database login password for the\n default `postgres` user role, encoded as a base64 string---for example,\n `Q2hhbmdlTWUxMjM=` for `ChangeMe123`.\n\n - \u003cvar translate=\"no\"\u003eCPU_COUNT\u003c/var\u003e: the number of CPUs available to each\n database instance in this database cluster.\n\n - \u003cvar translate=\"no\"\u003eMEMORY_SIZE\u003c/var\u003e: the amount of memory per database instance\n of this database cluster. We recommend setting this to 8 gigabytes per\n CPU. For example, if you set `cpu` to `2` earlier in this manifest, then\n we recommend setting `memory` to `16Gi`.\n\n - \u003cvar translate=\"no\"\u003eDISK_SIZE\u003c/var\u003e: the disk size per database instance---for\n example, `10Gi`.\n\n2. Apply the manifest file:\n\n kubectl apply -f \u003cvar translate=\"no\"\u003eDBCLUSTER_FILENAME\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eDBCLUSTER_FILENAME\u003c/var\u003e: the name of the `DBCluster` manifest file created in the previous step.\n\nUse the `kubectl describe` command to verify that the database cluster resource\nis in the `READY` status.\n\nConfigure the `pgBackRest` file\n-------------------------------\n\nConfigure the `pgBackRest` file to enable the target database cluster to access\nthe Cloud Storage bucket where source backups reside.\n\n1. In your target database cluster, find the database cluster pod details:\n\n kubectl get pod -l \"alloydbomni.internal.dbadmin.goog/dbcluster=\u003cvar translate=\"no\"\u003eDB_CLUSTER_NAME\u003c/var\u003e, alloydbomni.internal.dbadmin.goog/task-type=database\"\n\n The response includes the name of the cluster database pod.\n2. Log into the pod:\n\n kubectl exec -ti \u003cvar translate=\"no\"\u003eDATABASE_POD_NAME\u003c/var\u003e -- /bin/bash\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eDATABASE_POD_NAME\u003c/var\u003e: the name of the database cluster pod from the previous step.\n3. Stop the pod before updating the `pgBackRest` configuration file:\n\n supervisorctl.par stop postgres\n\n4. 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\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=/scripts/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 bucket that you created when creating the [`BackupPlan`](/alloydb/omni/16.3.0/docs/backup-kubernetes#remote) resource manifest file for 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\n account. For more information about other options, see [Cloud Storage Repository Key\n Type\n Option](https://pgbackrest.org/configuration.html#section-repository/option-repo-gcs-key-type).\n\nVerify source backups in the target database cluster\n----------------------------------------------------\n\nRun `pgBackRest` commands to verify that the source database cluster backups are\naccessible on the target database cluster. \n\n pgbackrest --config-path=/backup --stanza=db --repo=1 info\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 database cluster\n-------------------------------------------------\n\nAfter you identify the backup or a point in time you want to restore to, run\n`pgBackRest` commands in your target database cluster. 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=/backup --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=/backup --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\nRestart the pod\n---------------\n\nAfter the restore command completes successfully, you can start the `postgres`\nprocess. \n\n supervisorctl.par start postgres\n\nAfter the `postgres` process starts, you can connect to the primary instance and\nrun queries to verify that the data is restored from the backup. For more\ninformation, see [Connect to AlloyDB Omni running on\nKubernetes](/alloydb/omni/16.3.0/docs/run-connect#kubernetes).\n\nWhat's next\n-----------\n\n- [Clone a database cluster in Kubernetes using a local backup](/alloydb/omni/16.3.0/docs/kubernetes-dr-backup-k8-local)"]]
