長期保持バックアップを復元する

スタンドアロン ユーティリティを使用して、Cloud Storage バケットから長期保存されたバックアップを直接復元できます。これにより、Backup and DR アプライアンスがアクティブでなくてもデータにアクセスできます。

このドキュメントでは、このスタンドアロン復元ユーティリティを使用して、Backup and DR の OnVault と Compute Engine のバックアップ イメージを検出、検証、マウント、復元する方法について説明します。

概要

長期保持されたバックアップは、コンプライアンスとアーカイブ用の OnVault ポリシーを使用して Cloud Storage バケットに保存されます。バックアップ インフラストラクチャに依存せずにデータ アクセスを確保するには、スタンドアロンの復元ユーティリティを使用して、ストレージ バケットから直接このデータを検出、検証、復元します。これは、元のバックアップ/リカバリ アプライアンスが使用できない障害復旧または廃止シナリオで重要です。

始める前に

長期保存されたバックアップの復元を開始する前に、次のセクションを完了します。

必要なロールを取得する

長期保存されたバックアップを復元するために必要な権限を取得するには、ターゲット Cloud Storage バケットに対する Backup and DR Cloud Storage オペレーター （roles/backupdr.cloudStorageOperator）IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織に対するアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

その他の前提条件

長期保存されたバックアップを復元する前に、次の前提条件を満たしていることを確認してください。

  1. 復元を開始する前に、データが OnVault ストレージで使用可能であることを確認します。バックアップ/リカバリ アプライアンス プール内の既存のバックアップを確認し、関連する OnVault 保護ポリシーを割り当てて OnVault に移行します。

  2. Persistent Disk（Persistent Disk）スナップショットを含む復元シナリオでは、すべてのバックアップ メタデータがターゲットの Cloud Storage バケットに複製されていることを確認します。復元ユーティリティは、このメタデータを使用してスナップショット イメージをカタログ化し、処理します。データ転送を容易にし、メタデータが Cloud Storage バケットに存在することを確認するには、Cloud カスタマーケアにお問い合わせください。

  3. このツールを実行するホストシステムが次の要件を満たしていることを確認します。

    • gcloud CLI: インストールされ、PATH 環境変数（特に gcloud storage）でアクセス可能。
    • 認証: gcloud auth login を実行してアクティブな認証情報で構成するか、アプリケーションのデフォルト認証情報（ADC）またはサービス アカウント キーを使用します。

  4. 復元ユーティリティで使用する Cloud Storage バケット名と対応する Google Cloud プロジェクト ID のリストを特定して保持します。

リカバリ ユーティリティをデプロイする

復元プロキシまたは宛先アプリケーション ホストとして機能するように VM インスタンスを構成し、スタンドアロン復元ツールをデプロイします。

アプライアンス、ホスト、イメージを検出する

スタンドアロン復元ユーティリティは、コマンドのバケットとプロジェクトの値のペア（--bucket と --project）を受け入れます。このユーティリティは、次のオペレーションをサポートしています。

  • アプリケーションの一覧表示
  • バックアップを一覧表示する
  • バックアップの有効期限を設定する
  • バックアップ イメージをマウントする
  • バックアップ イメージをマウント解除する

バックアップ イメージをマウントする

復元マウントを実行するには、まずバックアップ イメージ名を特定する必要があります。

利用可能なバックアップを一覧表示して、バックアップ イメージの名前を特定します。

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --list-images

次に、非対話型の復元マウントを実行するには、次のサンプルと同様のコマンドを使用して、選択したバックアップ イメージを指定した復元プロキシまたはターゲット データベース サーバーに直接マウントします。

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --image IMAGE_NAME \
  --mountpoint MOUNT_POINT \
  --auto-mount

次のように置き換えます。

  • BUCKET_NAME: Cloud Storage バケットの名前。
  • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
  • APPLIANCE_NAME: バックアップ/復元アプライアンスの名前または ID。
  • HOST_NAME: ソースホストのホスト名または ID。
  • APPLICATION_NAME: 保護されたアプリケーションの名前または ID。
  • IMAGE_NAME: マウントするアクティブなバックアップ イメージの名前。
  • MOUNT_POINT: （省略可）バックアップがマウントされるローカル ディレクトリ パス。デフォルトは /tmp/recovery_folder です。

抽出が完了すると、マウント ポイント ディレクトリにバックアップされたデータが表示されます。

アプリケーションを復元する

未加工のデータベース ファイルにアクセスするには、MOUNT_POINT/restored_data/ に移動します。ワークロード タイプとマウント構成の復元パスを選択します。

Microsoft SQL

  1. ファイルの特定: db_volume/ ディレクトリ内のプライマリ .mdf データベース ファイルと .ldf データベース ファイルを特定します。
  2. 直接接続（同じホスト）: ターゲット データベース インスタンスを停止します。SQL Server Management Studio を開き、[データベースのアタッチ] を選択して、復元マウント ポイント ディレクトリ内のデータファイルとログファイルを指すファイルパスを指定します。
  3. コピーしてアタッチ（別のホスト）: ターゲット データベース インスタンスを停止します。.mdf ファイルと .ldf ファイルをターゲット サーバーのローカル ストレージ ドライブに転送し、SQL Server Management Studio を使用してアタッチします。

Oracle

  1. ファイルの特定: ユーティリティは、RMAN データベース バックアップと Archive log ボリューム グループをオンラインにしながら、init.ora ファイルまたは spfile ファイルと .dbf データファイルを自動的に検出します。
  2. データベースを復元する: ターゲット Oracle インスタンスをシャットダウンするか、NOMOUNT モードで起動します。初期化パラメータ（制御ファイルなど）を更新して、直接検証のためにマウントされた .dbf ファイルを指すようにするか、.dbf ファイルをローカル ストレージまたは自動ストレージ管理（ASM）ストレージにコピーして、永続的なリカバリーを行います。
  3. データベースを開く: インスタンスを MOUNT ステータスにし、マウントされた TransactionLog ボリューム グループから必要な復元ログを適用して、データベースを開きます。

VMware Engine VM

データベース アプリケーションの復元だけでなく、Google Cloud VMware Engine（VMware Engine）の仮想マシン保護には、仮想ディスク エクステントとともにハードウェア構成全体が含まれます。

  1. ファイルをマウントして特定する: バックアップ イメージをマウントするの説明に沿って、バックアップ イメージをマウントします。このユーティリティは、プライマリ マウントパス内にスパース仮想ディスク（vol00.raw）を生成します。次に、ディスクをアタッチして、db_volume/ ディレクトリの下にゲスト オペレーティング システムのファイル システムを公開します。一方、VMware 構成メタデータ（.ovf、.vmx、Catalog.xml など）は log_files/ フォルダ内に整理されます。
  2. VM を直接復元する: マニフェスト解析用にベースディスクを保護するため、ターゲット VM を無効にします。ワーカー プロセスは、ローカル ストレージからデータブロックを読み取り、VMware Virtual Disk Development Kit（VDDK）ライブラリを使用して VMDK に書き込み、VM を自動的に再起動します。

Compute Engine PD スナップショット

ローカル ファイル システムとしてマウントされる OnVault バックアップとは対照的に、Compute Engine Persistent Disk スナップショットは、新しい Persistent Disk を初期化してターゲットの Compute Engine インスタンスに直接アタッチすることで復元されます。

  1. ターゲットのバックアップとメタデータを特定する: Persistent Disk スナップショット メタデータ カタログ ファイル（pdsnapshot_catalog.json）が Cloud Storage バケットに存在することを確認します。永続ディスク マネージャー ユーティリティを使用して、カタログにリストされている利用可能なバックアップを確認し、復元用の特定の IMAGE ID を選択します。
  2. ボリュームを復元してアタッチする: attach コマンドを使用して、バックアップ スナップショットからの永続ディスクの生成を自動化します。この単一のアクションで、関連するすべてのボリュームの作成と移行先の仮想マシンへの接続が処理されます。
  3. オペレーティング システム レベルでデバイスをマウントする: アタッチが完了したら、ターゲットの Compute Engine インスタンスに接続し、lsblk などのツールを使用して新しくマッピングされたブロック デバイスを特定します。ファイル システムを手動でマウントして、復元されたデータにアクセスするか、アプリケーションの復元プロセスを開始します。

SAP HANA PD

ローカル ファイル システムとして直接マウントされる OnVault バックアップとは異なり、SAP HANA Persistent Disk スナップショットの復元では、新しい Persistent Disk をプロビジョニングして、ターゲットの Compute Engine インスタンスにアタッチします。

  1. メタデータを確認してバックアップ イメージを見つける: Persistent Disk スナップショット メタデータ カタログ ファイルが Cloud Storage バケットで使用可能であることを確認します。永続ディスク マネージャー ツールを使用して、カタログ化されたバックアップを検査し、復元に必要な IMAGE ID を選択します。
  2. ディスクをプロビジョニングしてボリュームをアタッチする: attach コマンドを実行して、選択したバックアップ スナップショットから永続ディスクを自動的に生成します。この手順では、必要なすべてのボリュームを作成し、1 回の操作でターゲット仮想マシンにアタッチします。
  3. オペレーティング システム レベルでデバイスをマウントする: ディスクを接続したら、移行先の SAP HANA VM に接続し、lsblk などのツールを使用して新しく割り当てられたブロック デバイスを確認します。ファイル システムを手動でマウントして、復元されたデータにアクセスするか、アプリケーション レベルの復元を開始します。
  4. SAP HANA を復元する: SAP HANA のデータ、ログ、アーカイブ ログの各ボリュームをマウントした後、システム データベースを起動します（必要に応じて特定の時点への復元も行います）。その後、テナント データベースの復元と初期化を行います。

IBM Db2 PD

ローカル ファイル システムとして直接マウントされる OnVault バックアップとは対照的に、IBM Db2 Persistent Disk スナップショットを復元するには、新しい Persistent Disk をプロビジョニングして、宛先 Compute Engine インスタンスにアタッチする必要があります。

  1. バックアップ イメージを特定してメタデータを検証する: Persistent Disk スナップショット メタデータ カタログ ファイルが指定された Cloud Storage バケットに存在することを確認します。永続ディスク マネージャー ツールを使用して、カタログ化されたバックアップを検査し、復元に必要なターゲット IMAGE ID を特定して選択します。
  2. ボリュームをアタッチしてディスクをプロビジョニングする: attach コマンドを実行して、指定されたバックアップ スナップショットから永続ディスクを自動的に作成します。この単一のステップで、必要なすべてのボリュームがプロビジョニングされ、ターゲット仮想マシンに直接アタッチされます。
  3. オペレーティング システムのファイル システムをマウントする: ディスクをアタッチしたら、ターゲットの IBM Db2 VM に接続し、lsblk などのツールを使用して新しくマッピングされたブロック デバイスを特定します。ファイル システムを手動でマウントして、復元されたデータにアクセスするか、アプリケーションの復元を続行します。
  4. アプリケーション データベースを復元する: Db2 データ、トランザクション ログ、アーカイブ ログの各ボリュームをマウントした後、各 Db2 データベース インスタンスをカタログに登録し、必要に応じてデータベースの復元を実行して、データベースをオンラインにします。

MySQL / MariaDB

  1. ファイルを見つける: ユーザー データベース、システム スキーマ、InnoDB テーブルスペースを含むメイン データ ディレクトリを db_volume/ で見つけます。

  2. データベースを復元: アクティブな MySQL または MariaDB サービスを停止します。直接テストするには、my.cnf の datadir エントリを調整して、復元マウント フォルダをターゲットにします。永続的な復元を行うには、データベース ファイルをローカル ストレージ（/var/lib/mysql/ など）にコピーし、ファイル システムの所有権と権限が正しいことを確認します。

  3. オンラインにして復元: データベース サービスを再起動します。バイナリ トランザクション ログが存在する場合は、mysqlbinlog ユーティリティを使用してポイントインタイム リカバリを実行します。

PostgreSQL

  1. ファイルを見つける: db_volume/ ディレクトリで、コア データベース（base/、global/、pg_wal/）や postgresql.conf 構成ファイルなどの PGDATA アセットを特定します。

  2. データベースを復元する: 移行先の PostgreSQL インスタンスをシャットダウンします。マウントから直接検証するには、data_directory 環境変数または PGDATA 環境変数が復元パスを指すように設定します。完全に復元するには、ディレクトリ構造全体をターゲット ホストのローカル ストレージに転送します。

  3. Open database: サービスを再起動して、インスタンスをオンラインにします。ポイントインタイム リカバリが必要な場合は、recovery.conf ファイルを定義するか、postgresql.conf 内の restore_command を構成して（PostgreSQL 12 以降の場合）、log_files/ フォルダからアーカイブされた WAL ログを適用し、データベースをオンラインにします。

SAP ASE

  1. ファイルを探す: マウントされた db_volume/ フォルダ内にある、特定のユーザー データベースとログデバイスとともに、プライマリ マスター デバイスを特定します。

  2. データベースを復元: 宛先 SAP ASE インスタンスをシャットダウンします。直接マウントの場合、RUN_server 構成を更新して、マスター デバイス パラメータ（-d など）を復元パスにリダイレクトします。または、すべてのデバイス アセットを永続ストレージの場所に転送します。

  3. Open database: SAP ASE dataserver プロセスを開始します。トランザクション ログが存在する場合は、LOAD TRAN オペレーションを実行して、データベースをオンラインにする前にポイントインタイム リカバリを実行します。

SAP MaxDB

  1. ボリュームを見つける: db_volume/ マウントパスに移動して、プライマリ SAP MaxDB データファイルとログファイルを見つけます。

  2. 復元またはリダイレクトの構成: 宛先の SAP MaxDB プロセスを停止します。データベース マネージャー（dbmcli）を使用して、DataVolumeName などのパラメータを復元マウントを指すように更新するか、完全復元のためにファイルをローカル ストレージに直接コピーします。

  3. 起動してオンラインにする: Database Manager を使用して、データベース インスタンスを起動し、運用ステータスを ONLINE に設定します。

SAP IQ

  1. ファイルを見つける: db_volume/ ディレクトリに移動して、プライマリ SAP IQ メインストア、カタログ ストア（.db）、関連するすべての一時ストア アセットを特定します。

  2. Restore database: 宛先 SAP IQ インスタンスをシャットダウンします。復元マウントから直接検証を実行するには、マウントされたカタログ ファイルを参照するように起動パラメータを変更します。永続的な復元を行うには、適切なファイル システムの所有権と権限が維持されていることを確認しながら、すべてのストア ボリュームをローカル ストレージに転送します。

  3. データベースを開く: start_iq ユーティリティを実行してインスタンスをオンラインにし、データの完全性を確認します。

IBM Db2 LVM/ダンプ

  1. ファイルを見つける: db_volume/ と log_files/ のマウントパスに移動します。保護方法に基づいて、ダンプベースの復元用の LVM データ ボリュームとログ ボリューム、または特定のバックアップ イメージ アセットを特定します。
  2. データベースを復元（LVM）: 宛先 Db2 インスタンスをシャットダウンします。データベース データとアクティブなトランザクション ログ ボリュームをリカバリー マウントからターゲットのローカル ストレージに転送し、Db2 ユーザーとグループのファイル システムの所有権が正しいことを確認します。
  3. データベースの復元（ダンプベースの完全復元と増分復元）: アクティブな接続を停止し、ターゲット データベースが存在する場合は削除します。db2ckrst ツールと特定のバックアップ タイムスタンプを使用して、必要な増分シーケンスをカタログ化します。指定された順序で各イメージに対して RESTORE オペレーションを実行します。
  4. データベースを開く: Db2 インスタンスを起動します。データベースが保留状態のままになっている場合や、特定の時点への復元が必要な場合は、db2 rollforward ユーティリティを使用してトランザクション ログを適用し、復元を完了してインスタンスをオンラインにします。

リソースのクリーンアップ

必要なデータベース ファイルをすべてデータベース エンジンからコピーまたは切り離したら、アクティブ ボリュームを安全にマウント解除し、関連するループデバイスを切り離して、ローカル ステージング ディレクトリを削除し、残存ロックや孤立した参照を回避します。

ボリュームをマウント解除して復元ディレクトリをクリーンアップするには、次のコマンドを実行します。

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --mountpoint MOUNT_POINT \
  --unmount
rm -rf MOUNT_POINT

次のように置き換えます。

  • MOUNT_POINT: バックアップがマウントされたローカル ディレクトリ パス（/tmp/recovery_folder など）。

次のステップ