Compute Engine で実行されている IBM Db2 インスタンスの保護と復元

このページでは、Persistent Disk スナップショットを使用して Compute Engine インスタンスで Db2 用の Backup and DR Service を使用する方法について説明します。

データ損失、エラー、破損から Db2 本番環境を保護する

Db2 は、IBM の情報管理部門のリレーショナル データベース管理システム ファミリーであり、複数のリレーショナル データベース管理システム プロダクトを中心にしています。多くの企業が、ミッション クリティカルなアプリケーションに Db2 を使用しています。

他のどのデータベースでも発生する可能性があるように、Db2 は破損、誤削除、ランサムウェア攻撃などのセキュリティ脅威の影響を受けやすくなります。Backup and DR サービスを使用すると、本番環境システムを効率的かつ安全にバックアップして復元できます。

Backup and DR サービスを使用して Db2 データベースを保護する方法の概要については、IBM Db2 のバックアップと DR をご覧ください。

最初に Backup and DR サービスをデプロイする

始める前に、次の手順を読んで完了する必要があります。

Backup and DR サービスの仕組みを確認する

次に、バックアップと DR の使用を開始する: Compute Engine インスタンスを保護して復元するで、Backup and DR サービスの仕組みを確認します。

バックアップ用の Db2 インスタンスを準備する

前提条件

  • Db2 サービスとデータベースが実行されている必要があります。
  • アーカイブログ バックアップのデータベース logarchmeth1 パラメータと logarchmeth2 パラメータは、ログバックアップの有効なパスに設定する必要があります。
  • バックアップと DR サービスで保護する Db2 データが存在する（Compute Engine）のすべての Db2 サーバーは、バックアップと DR サービスにオンボーディングされている必要があります。
  • バックアップと DR サービスによって保護される Db2 データが存在する（Compute Engine 内の）すべての Db2 サーバーに、バックアップと DR エージェントをインストールする必要があります。
  • すべての Db2 データベース db、ログ、ログ バックアップのマウント ポイントに、永続ディスク VG と LVM が必要です。Db2 アプリケーションの永続ディスク上の直接ファイル システムはサポートされていません。
  • データベース、アクティブ ログ、ログバックアップのロケーションの Db2 データベースに同じマウントポイントを使用しないでください。

Db2 データベースをホストする Compute Engine インスタンスを検出して保護する

Db2 データベース アプリケーションをオンボーディングする前に、Db2 Compute Engine VM をオンボーディングする必要があります。Compute Engine インスタンスを Backup and DR サービスにオンボーディングするには、Compute Engine インスタンスの検出と保護をご覧ください。

このクイックスタート演習について

この演習では、Compute Engine インスタンスで実行されている Db2 データベースを検出して保護し、最後に、バックアップ イメージから新しいロケーションに完全に機能する新しい Db2 データベースをマウントする手順について説明します。

  1. Compute Engine にバックアップと DR エージェントをインストールする
  2. Db2 データベースのバックアップ プランを作成する
  3. Db2 データベースを検出して保護する
  4. バックアップから Db2 データベースを復元する: マウントと復元

ホストにバックアップと DR エージェントをインストールする

バックアップと DR エージェントは、Compute Engine インスタンスをバックアップ/リカバリ アプライアンスに接続します。エージェントをインストールするには、Linux ホストにバックアップと DR エージェントをインストールするをご覧ください。

Db2 データベースのバックアップ プランを作成する

ポリシー テンプレートを作成するをご覧ください。

Db2 データベースの詳細なポリシー設定を設定する

ポリシー テンプレートを作成するときに、Persistent Disk スナップショットを使用する Db2 保護に固有の高度なポリシー設定を構成します。

スナップショットのロケーション: Persistent Disk スナップショットを保存するリージョンを選択します。デフォルトでは、マルチリージョンが選択されます（ソースディスクのロケーションに基づく）。スナップショットの保存場所を、ソースディスクのリージョンとは異なるリージョンに変更することもできます。スナップショットをソースディスクのロケーションとは異なるロケーションに保存すると、データは異なるロケーション間のネットワークを通過するため、ネットワーク費用が発生する可能性があります。スナップショットには、Cloud Storage の下り（外向き）と同じ料金が発生します。Persistent Disk スナップショットの詳細を確認する。料金の詳細については、ディスクの料金をご覧ください。

スナップショットの種類: Db2 バックアップに使用する Persistent Disk スナップショットのタイプを選択します。スナップショットは、永続ディスクからデータを増分的にバックアップします。バックアップ中に、新しいスナップショットが作成され、Persistent Disk の現在の状態がキャプチャされます。このスナップショットは、後でマウントまたは復元用の新しいディスクの作成に使用できます。Compute Engine ではデータの整合性を確保するため、自動チェックサムを使用して各スナップショットの複数のコピーを複数のロケーションに保存します。Persistent Disk スナップショットの詳細を確認する。料金の詳細については、ディスクの料金をご覧ください。

  • 標準: デフォルトでは、標準スナップショット タイプが選択されています。バックアップを 90 日未満保持する場合は、標準タイプを使用します。
  • アーカイブ: バックアップを長期間保持する場合は、アーカイブ タイプを選択します。アーカイブ スナップショットの最小請求対象期間は、ポリシーで定義された保持期間に関係なく 90 日です。また、アーカイブ タイプは、マウント ジョブまたは復元ジョブで使用された場合に追加の取得料金が発生します。

Db2 アーカイブ ログのバックアップを有効にして保護する

データベースのスナップショット ポリシーを作成するときに、指定した頻度でログファイルをキャプチャすることもできます。データベース ログがキャプチャされる頻度は、データベースの頻度とは別に定義されます。たとえば、データベースは毎日キャプチャされ、ログは 1 時間ごとにキャプチャされます。

Truncate（Purge）Log After Backup: バックアップ後に Db2 アーカイブ ログを切り捨て（パージ）するかどうかを指定します。[Truncate Log after Backup] が有効になっている場合、Db2 アーカイブログは切り捨てられます。デフォルトでは、アーカイブのパージはデータベースのバックアップごとに実行されます。最適な復元 RTO を実現するには、デフォルトを使用することをおすすめします。本番環境のログ保持が設定されている場合、[Application Details and Settings] の [Retention of production db logs in hour] の設定に基づいてパージが実行されます。

次のオプションがあります。

  • バックアップ後にログを切り捨て/パージしない: デフォルトです。このモードでは、アーカイブ ログはパージされません。
  • バックアップ後にログを切り捨て/パージする: アーカイブ ログのパージを有効にする場合は、このオプションを選択します。
  • Enable Database Log Backup: オプションを [Yes] に設定します。[データベース ログのバックアップを有効にする] オプションを使用すると、バックアップ プラン ポリシーでデータベースと関連するすべてのトランザクション ログファイルをバックアップできます。ログは、ログ スナップショット ジョブの実行時にバックアップされます。[はい] に設定すると、関連するオプションが有効になります。
  • RPO: データベース ログ バックアップを分単位で指定します。[Enable Database Log Backup] が [Yes] に設定されている場合、RPO によってデータベース ログのバックアップ頻度が定義されます。頻度は分単位で設定し、データベースのバックアップ間隔を超えないようにする必要があります。設定できる最小値（分単位）は 15 です。
  • Log Backup Retention Period (In Days): [Enable Database Log Backup] が [Yes] に設定されている場合、ログの保持はスナップショット ポリシーの保持とは別に定義されます。保持期間を別々に設定すると、スナップショット プールに保存されているデータベースのコピーとともにログを使用できます。
  • Replicate Logs (Uses streamsnap Technology): このオプションを [No] に設定します。これは、Db2 Persistent Disk スナップショット保護には適用されません。
  • Send Logs to OnVault Pool: このオプションを [No] に設定します。これは、Db2 Persistent Disk スナップショット保護には適用されません。

Db2 アーカイブログのバックアップに関する推奨事項

ログバックアップで最適な結果を得るには、次の点に注意してください。

  • Db2 データベース アーカイブ ログのマウントを使用して、Db2 アーカイブ ログのバックアップ以外のファイルを保存しないでください。
  • デフォルトでは、アーカイブのパージは 24 時間ごとに実行されます。これにより、最適な復元 RTO が実現されます。本番環境ログの保持が設定されている場合、パージは [Application Details & Settings] の [Retention of production db logs in hour] の設定に基づいて実行されます。本番環境のログ保持設定に基づいてアーカイブを保存するように、Db2 アーカイブログ バックアップ ディスクのサイズを調整します。

App Manager から Db2 データベースを検出して保護する

Db2 データベース アプリケーションを検出して保護する手順は次のとおりです。

  1. 管理コンソールの [App Manager] > [Applications] ページで、[Add Application] を選択します。
  2. ウィザードで [Db2] を選択します。
  3. ウィザードに沿って操作します。
    1. [選択] セクションで、管理する Db2 インスタンスを選択します。
    2. [管理] セクションで、ポリシー テンプレートとリソース プロファイルを適用します（これらはバックアップ プランを作成するで作成しました）。
    3. [Application Settings] の [Configure] セクションで、[Configure backup options] を設定します。
    4. バックアップのキャプチャ方法: [Use Persistent Disk Snapshot] を選択します。
    5. 本番環境 DB ログの保持時間（時間）: logarchmeth1 の宛先から Db2 アーカイブ ログのバックアップを完全に削除するために使用されます。この設定に基づいて、指定した時間より古いログがパージされます。デフォルト値では、最後のデータ バックアップより前のすべてのログが完全に削除されます（デフォルトは 24 時間）。
  4. [保存] > [次へ] > [完了] をクリックします。

バックアップ プランが適用されたことを示す緑色のシールドのついたデータベースが [App Manager Applications] リストに表示されます。

バックアップから Db2 データベースを復元する: マウントと復元

データベースを復元すると、バックアップから元のデータが上書きされます。この手順は、バックアップされたデータベースを復元するためのものです。バックアップからデータベースを復元するには、バックアップから Db2 データベースを復元するをご覧ください。

データベースをマウントすると、データベースの新しいコピーがマウント ポイントに配置され、元のデータベースと同じように使用できるようになります。バックアップから新しいデータベースをマウントするには、Db2 バックアップを標準マウントとしてマウントするをご覧ください。

Db2 バックアップを標準マウントとしてマウントする

標準マウントでは、データ、アクティブ ログ、アーカイブ ログ ボリュームのバックアップ イメージ ディスクが指定されたターゲットに提供されます。Db2 データベースのバックアップは、任意の手動オペレーションの標準マウントとしてマウントできます。

マウント時の事前チェック

  • コネクタの接続ステータス: {backupdr_name_short} エージェントがインストールされ、アプライアンスとエージェント間のホスト接続にシークレットが適用されていることを確認します。
  • 指定されたマウント ロケーションは、マウント オペレーションで使用できます。
  • ターゲットに同じ VG が存在し、データベースで使用されている場合は、VG がデータベースで使用されているというメッセージとともに事前チェックに失敗します。続行するには、マウント オペレーションを開始する前にデータベースをシャットダウンします。
  • Google Cloudサービスのソース プロジェクトとターゲット プロジェクトに対する権限チェック。

バックアップからデータベースをマウントする

バックアップをマウントする手順は次のとおりです。

  1. [App Manager] > [Applications] リストで、保護されたデータベースを右クリックして、[Access] を選択します。

  2. スナップショット イメージを選択し、[マウント] を選択します。

  3. [Mount] ページの [GCE INSTANCE NAME] で、ターゲット Db2 サーバーを選択します。フィルタ「プロジェクト名」、「リージョン」、「ゾーン」を使用できます。

  4. 必要に応じて、[ラベル] フィールドにマウントに関連する一意の名前を入力します。INCLUDED DATABASES: バックアップ イメージ内のデータベースのリストを示す情報のみです。

  5. [Mapping Options] で以下を指定します。

    • MOUNT POINT: ソースの MOUNT POINT が事前入力されています。選択したターゲットで使用されていないパスを指定します。このパスは、ターゲット サーバーですべての data、active log、dbpath、Logbackup ボリュームのスナップショット イメージのマウントに使用します。
    • DISK TYPE: ソースの DISK TYPE 値が事前に入力されています。ディスクタイプはプルダウンから変更できます。

  6. [フライト前のチェック] をクリックします。これにより、マウントを成功させるためにターゲット サーバーで必要なオプションが検証されます。事前フライトが正常に完了すると、[送信] ボタンが有効になります。失敗した場合、プリフライトは、修正してプリフライトを再実行する必要があるチェックを示します。

  7. [送信] をクリックします。ジョブ モニタに移動して、ジョブの進行状況と詳細を確認できます。

マウントされたデータベース バックアップが不要になったらマウントを解除する

マウントされたデータベース バックアップをマウント解除するには:

  • マウント後にディスクを削除または保持するには、[Application] > [Access] ページに移動し、マウントされたイメージを選択します。
  • アクセス ページの [現在の有効なマウント] プルダウンには、次の 2 つのオプションがあります。
    • マウント解除と削除: このオプションを選択すると、マウント ポイントをマウント解除し、ディスクを切断して、ターゲット サーバーからディスクを削除できます。
    • アクティブなマウントを削除する: このオプションを選択すると、ディスクは接続されたままマウントされ、バックアップと DR サービスからメタデータが削除されます。ユーザーは、Google Cloud コンソールを使用して、このイメージをターゲット インスタンスから削除する必要があります。

バックアップから Db2 データベースを復元する

この手順は、バックアップされたデータベースを復元するためのものです。

プリフライト チェック

復元手順を送信する前に、事前フライト チェックで、データベースの復元を成功させるために必要な前提条件が検証されます。

  • Db2 SID: Db2 は、同じ Db2 SID 名でターゲット ノードに構成されています。
  • Db2 VERSION: ターゲット Db2 バージョンはソース Db2 バージョンと同じです。
  • 新しいターゲットに復元する場合
    • マッピング オプションで指定されたマウントポイントがターゲット サーバーで使用されていないか、マウントされていないことを確認します。
    • 指定したマウント場所がマウント オペレーションで使用可能であることを確認します。
  • Db2 インスタンスが実行されているかどうかを確認します。復元オペレーション中にシャットダウンする必要があります。
  • ターゲットに同じ VG が存在し、データベースで使用されている場合は、VG がデータベースで使用されているというメッセージとともに事前チェックに失敗します。続行するには、復元を開始する前にデータベースをシャットダウンします。
  • Google Cloud サービスのソース プロジェクトとターゲット プロジェクトに対する権限チェック。

Db2 データベースをソースに復元する

  1. [App Manager] > [Applications] リストで、データベースを右クリックして [Access] を選択します。
  2. 復元する最新のスナップショットを選択して、[Restore] を選択します。
  3. [復元] ページで、[ソースに復元] を選択します。すべてのフィールドには、保護された Db2 インスタンスのソース値が事前に入力されています。アプリケーション オプションを除き、すべてのフィールドは変更できません。
  4. ラベル: 必要に応じて、このフィールドにマウントに関連する一意の名前を入力します。
  5. [INCLUDED DATABASES] は情報のみを表示します。バックアップ イメージ内のデータベースのリストが表示されます。
  6. アプリケーション オプションを設定します。
    • ロールフォワード時間: ログで保護されているデータベースの場合は、復元する日時を選択します。
    • TARGET INSTANCE: 保護されたデータベース インスタンス名が事前に入力され、変更できません。
    • マッピング オプション:
    • ボリューム マウント ポイントの場所: Db2 data、dbpath、log、log backup volumes がマウントされるソース ボリューム グループ、論理ボリューム、デバイスパス、ディスクタイプが事前入力されています。
    • ディスクタイプ: ディスクタイプでは、バックアップ イメージから復元されたデータに使用される基盤となるブロック ストレージのタイプを選択できます。
  7. [フライト前のチェック] をクリックします。プリフライト チェックが失敗した場合は、問題を修正してプリフライト チェックを再送信します。プリフライト チェックが成功したら、[送信] をクリックして復元ジョブを送信します。

Db2 データベースを新しいターゲットに復元する

  1. [App Manager] > [Applications] リストで、データベースを右クリックして [Access] を選択します。
  2. 復元する最新のスナップショットを選択して、[復元] を選択します。[復元] ページで、[新しいターゲットに復元] を選択します。すべてのフィールドには、保護された Db2 インスタンスのソース値が事前に入力されていますが、編集できます。
  3. 新しいターゲットに復元するには、Db2 データベースを復元するインスタンスのプロジェクト、リージョン、ゾーンを選択します。
  4. [インスタンス名] で、復元するノードを、対象となる Compute Engine インスタンスのプルダウン リストから選択します。
  5. ラベル: 必要に応じて、このフィールドにマウントに関連する一意の名前を入力します。
  6. INCLUDED DATABASES は情報のみで、バックアップ イメージ内のデータベースのリストが表示されます。
  7. 元のアプリケーション ID を置き換えます。このオプションは、バックアップが最初に生成された同じアプライアンスの新しいホストに復元する場合にのみ使用できます。
    • はい: 元のアプリケーションに代わるもので、元のアプリケーションと同じアプリケーション ID、ジョブ履歴、バックアップ イメージ、バックアップ プランを保持します。
    • いいえ: 元のアプリに代わるものではありません。復元ジョブの一環として、新しいアプリケーションとして検出されます。
  8. アプリケーション オプションを設定します。
    • ロールフォワード時間: ログで保護されているデータベースの場合は、復元する日時を選択します。
    • TARGET INSTANCE: 保護されたデータベース インスタンス名が事前に入力され、変更できません。
    • マッピング オプション:
    • ボリューム マウント ポイントの場所: Db2 data、dbpath、log、log backup volumes がマウントされるソース ボリューム グループ、論理ボリューム、デバイスパス、ディスクタイプが事前入力されています。
    • ディスクタイプ: ディスクタイプでは、バックアップ イメージから復元されたデータに使用される基盤となるブロック ストレージのタイプを選択できます。
  9. [フライト前のチェック] をクリックします。プリフライト チェックが失敗した場合は、問題を修正してプリフライト チェックを再送信します。プリフライト チェックが成功したら、[送信] をクリックして復元ジョブを送信します。