このページの手順では、ソース Kubernetes データベース クラスタが Google Kubernetes Engine で作成され、バックアップ ディスクが Compute Engine 永続ディスクであることを前提としています。また、ターゲット AlloyDB Omni シングル サーバーが Compute Engine 仮想マシン（VM）にインストールされていることを前提としています。
他の環境を使用している場合は、それぞれのドキュメントを参照して、これらの手順を環境に複製してください。
次のワークフローでは、クローンの作成手順を示します。
- ソース データベース クラスタのバックアップ ディスクのバックアップ ディスク情報（永続ボリューム名、Compute Engine 永続ディスク ハンドラなど）を特定します。
- ソース データベース クラスタのバックアップ ディスクをターゲット サーバーにマウントします。
pgBackRestコマンドを使用して、ソース バックアップにアクセスできることを確認します。pgBackRestコマンドを使用して、バックアップをターゲット データベース クラスタに復元します。
始める前に
- ソース データベース クラスタのバックアップが保存されているバックアップ ディスクにアクセスできることを確認します。
- 単一サーバー ターゲットの AlloyDB Omni データベース クラスタが作成されます。Kubernetes への AlloyDB Omni のインストールの詳細については、AlloyDB Omni をインストールするをご覧ください。
postgresユーザーとしてデータベースにログインしていることを確認します。
ソース バックアップのディスク情報を取得する
復元プロセスの一環として、ソース データベース クラスタのバックアップ ディスクの Persistent Volume Claim（PVC）名を特定します。PVC は、Kubernetes 内でアプリケーションの永続ストレージを管理するために使用されます。
次のサンプル コマンドを使用すると、バックアップ ディスクの PVC 名を使用して、基盤となる PV 名と Compute Engine 永続ディスク ハンドラを特定できます。
AlloyDB Omni ソース データベース クラスタを作成した GKE クラスタに接続します。
kubectl get pvc -n DB_CLUSTER_NAMESPACE | grep DB_CLUSTER_NAME | grep backupdisk次のように置き換えます。
DB_CLUSTER_NAMESPACE: このバックアップの Kubernetes Namespace。データベース クラスタの Namespace と一致する必要があります。DB_CLUSTER_NAME: このデータベース クラスタの名前（例:my-db-cluster）。
レスポンスの例を次に示します。
backupdisk-al-fe8c-dbcluster-sample-0 Bound pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a 10Gi RWO standard-rwo 5d21h ```前の手順のバックアップ ディスク名（
backupdisk-al-fe8c-dbcluster-sample-0など）を使用して、基盤となる PV 名を確認します。kubectl get pvc/PVC_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath={.spec.volumeName}次のように置き換えます。
PVC_NAME: 前の手順のレスポンスから取得したバックアップ ディスクの PVC 名（例:backupdisk-al-fe8c-dbcluster-sample-0）。
基盤となる Compute Engine 永続ディスク ハンドラを見つけます。
kubectl get pv/$PV_NAME -o json | jq -r .spec.csi.volumeHandle次のように置き換えます。
PV_NAME: 前の手順のレスポンスから取得したバックアップ ディスクの PV 名。
レスポンスの例を次に示します。
projects/my-project/zones/us-central1-a/disks/pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3バックアップ ディスク名を、次のセクションで使用する変数としてエクスポートします。
export BACKUP_DISK=pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3
バックアップ ディスクをターゲット サーバーにマウントする
ターゲット サーバーが Compute Engine 仮想マシンにインストールされている AlloyDB Omni サーバーであると想定して、バックアップ ディスクをサーバーにマウントします。
gcloud compute instances attach-diskコマンドを実行してディスクをマウントします。gcloud compute instances attach-disk GCE_INSTANCE_NAME \ --disk ${BACKUP_DISK} \ --zone=$GCE_ZONE次のように置き換えます。
GCE_INSTANCE_NAME: Compute Engine 仮想マシンにターゲット サーバーがインストールされているインスタンスの名前。GCE_ZONE: Compute Engine 仮想マシン インスタンスが存在するゾーン。
バックアップ ディスクをターゲット サーバーにマウントします。
lsblk mkdir -p /mnt/disks/backupdisk mount -o discard,defaults /dev/sdb /mnt/disks/backupdisk/var/alloydb/configディレクトリの AlloyDB Omnidataplane.confファイルにカスタム バインディング マウントを追加します。PG_BIND_MOUNTS=/mnt/disks/backupdisk:/mnt/disks/backups:rshared
Docker でのバインディング マウントの詳細については、マウントをバインドするをご覧ください。
ターゲット サーバーを再起動します。
alloydb database-server stop alloydb database-server start
pgBackRest 構成ファイルを更新する
バックアップ ディスク ディレクトリの既存の pgBackRest ファイルを、新しいリポジトリパスで更新します。
ターゲット サーバーで、
/mnt/disks/backupdiskディレクトリに移動します。cd /mnt/disks/backupdisk既存のデータを上書きしないように、
pgbackrest.confファイルでpg1-pathパスを一時ディレクトリに更新します。data-restoredディレクトリは、復元プロセスの一部として自動的に作成されます。sudo sed -i 's|.*pg1-path.*|pg1-path=/mnt/disks/pgsql/data-restored|' pgbackrest.confpgbackrest.confファイルで、一時ディレクトリへのrepo1-pathパスを更新します。sudo sed -i 's|.*repo1-path.*|repo1-path=/mnt/disks/backups/repo|' conf.d/repo1-local-backupplan.conf
ターゲット データベース クラスタのソース バックアップを確認する
ターゲット サーバーにログインして pgBackRest コマンドを実行し、ターゲット サーバーでソース データベース クラスタのバックアップにアクセスできることを確認します。
sudo docker exec pg-service pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 infoレスポンスの例を次に示します。
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
レスポンスのタイムスタンプは、フル バックアップの復元または復元ウィンドウ内の特定の時点からの復元に使用されます。
ターゲット サーバーでバックアップを復元する
復元するバックアップまたは復元ポイントを特定したら、ターゲット サーバーで pgBackRest コマンドを実行します。これらのコマンドの詳細については、復元コマンドをご覧ください。
以下に、pgBackRest コマンドの例を示します。
バックアップから復元する
pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 restore --set=20240213-231400F --type=immediate --target-action=promote --delta --link-all --log-level-console=info特定の時点からの復元
pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 restore --target="2024-01-22 11:27:22" --type=time --target-action=promote --delta --link-all --log-level-console=info
ターゲット サーバーにデータをコピーする
復元コマンドが正常に完了したら、data-restored 一時ディレクトリから現在の AlloyDB データ ディレクトリにデータをコピーできます。
ターゲット サーバーでデータベース サービスを停止します。
alloydb database-server stop現在のデータ ディレクトリの名前を別の名前に変更することをおすすめします。
mv ~/alloydb-data/data ~/alloydb-data/data-olddata-restored一時ディレクトリの名前を現在のデータ ディレクトリに変更します。mv ~/alloydb-data/data-restored ~/alloydb-data/datapostgresql.auto.confファイルのpg1-path値を更新して、復元されたデータを読み込みます。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'ターゲット サーバーでデータベース サービスを起動します。
alloydb database-server start
データベース サービスが起動したら、プライマリ インスタンスに接続してクエリを実行し、バックアップからデータが復元されたことを確認できます。詳細については、単一サーバーの AlloyDB Omni に接続するをご覧ください。