The following workflow explains the cloning steps:
- Configure the
pgbackrest.conffile to access the Cloud Storage backup. - Use
pgBackRestcommands to verify source backups can be accessed. - Use
pgBackRestcommands 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 the
BackupPlanresource for your source database cluster. - A single server target AlloyDB Omni database cluster is created. For more information about installing AlloyDB Omni on Kubernetes, see Install AlloyDB Omni.
- Ensure you are logged in to the database as the
postgresuser.
Configure the pgBackRest file on the target server
Configure the pgBackRest file to enable the target database cluster to access the Cloud Storage bucket where source backups reside.
In the target server, navigate to the
alloydb-datadirectory.Create a
pgBackRestconfiguration file to access backups stored in Cloud Storage:$ cat << EOF > /backup/pgbackrest.conf [db] pg1-path=/mnt/disks/pgsql/data-restored pg1-socket-path=/tmp pg1-user=pgbackrest [global] log-path=/obs/pgbackrest log-level-file=info repo1-type=gcs repo1-gcs-bucket=GCS_SOURCE_BACKUP_BUCKET_NAME repo1-path=GCS_SOURCE_BACKUP_BUCKET_PATH repo1-storage-ca-file=/etc/ssl/certs/ca-certificates.crt repo1-retention-full=9999999 repo1-gcs-key-type=autoReplace the following:
- GCS_SOURCE_BACKUP_BUCKET_NAME: the name of the Cloud Storage
pgBackRestbucket 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
/.
The
repo1-gcs-key-typeis set toautoto use the instance's service account. For more information about other options, see GCS Repository Key Type Option.- GCS_SOURCE_BACKUP_BUCKET_NAME: the name of the Cloud Storage
Verify source backups in target server
Sign in to the target server and run pgBackRest commands to verify that the source database cluster backups are accessible on the target server:
Docker
sudo docker exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/pgsql --stanza=db --repo=1 infoPodman
sudo podman exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/pgsql --stanza=db --repo=1 infoReplace CONTAINER_NAME with the name of a new AlloyDB Omni container—for example, my-omni-1.
The following is a sample response:
stanza: db
status: ok
cipher: none
db (current)
wal archive min/max (15): 000000010000000000000002/00000001000000000000000D
full backup: 20240213-231400F
timestamp start/stop: 2024-02-13 23:14:00+00 / 2024-02-13 23:17:14+00
wal start/stop: 000000010000000000000003 / 000000010000000000000003
database size: 38.7MB, database backup size: 38.7MB
repo1: backup set size: 4.6MB, backup size: 4.6MB
incr backup: 20240213-231400F_20240214-000001I
timestamp start/stop: 2024-02-14 00:00:01+00 / 2024-02-14 00:00:05+00
wal start/stop: 00000001000000000000000D / 00000001000000000000000D
database size: 38.7MB, database backup size: 488.3KB
repo1: backup set size: 4.6MB, backup size: 84.2KB
backup reference list: 20240213-231400F
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, run
pgBackRest commands in your target server. For more information
about these commands, see Restore
Command.
The following are some sample pgBackRest restore commands:
Restore from a backup
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=infoRestore from a point in time
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
Copy data to the target server
After 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.
- In the target server, stop the database service:
Docker
docker stop CONTAINER_NAMEPodman
podman stop CONTAINER_NAMERename the current data directory to another name as a best practice:
mv ~/alloydb-data/data ~/alloydb-data/data-oldRename the
data-restoredtemporary directory to the current data directory:mv ~/alloydb-data/data-restored ~/alloydb-data/dataUpdate
pg1-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:11
restore_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
docker start CONTAINER_NAMEPodman
podman start CONTAINER_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, see Connect to AlloyDB Omni on a single server.