メインコンテンツまでスキップ
Dummy text to avoid mindtouch from removing the blank div

Druva

Phoenixのワークフローの理解

これら手順図では、ファイルサーバー、MS-SQLサーバー、VMware環境のバックアップとリストアのプロセスを説明します。

  • データバックアップの手順
  • ウォームリストアの手順
  • コールドリストアの手順
  • ファイルサーバーバックアップの手順
  • ファイルサーバーリストアの手順
  • 仮想マシンのバックアップの手順
  • 仮想マシンリストアの手順
  • Phoenix AWSプロキシ設定の手順
  • Phoenixディザスタリカバリの手順
  • CloudCache環境のデータバックアップ手順
  • CloudCache環境のデータリストア手順
  • VMware向けのポートと通信プロトコル
  • ファイルサーバー向けのポートと通信プロトコル
  • Phoenix CloudCache向けのポートと通信プロトコル

データバックアップの手順

以下にバックアップ時におけるPhoenix環境内でのデータフローを図示します。 

手順 操作

手順1

 

サーバーにインストールしたPhoenixエージェントがサーバーデータをバックアップポリシーで定義されたスケジュールに従ってバックアップします。Phoenixマスターはスケジュールされた時刻にPhoenixエージェントがインストールされているサーバーからのバックアップを開始します。

手順2

PhoenixエージェントはWAN経由で応答要求メッセージパターンに従ってPhoenixマスターとの通信を試みます。

手順3

Phoenixマスターはエージェントの通信要求を検証します。検証が成功すると、Phoenixマスターはストレージにエージェント要求を割り当てます。

手順4

Phoenixエージェントはデータをストレージにバックアップします。 

ウォームリストアの手順 

ウォーム復元は90日以内のスナップショット (ウォームスナップショット) を使用するデータの復元です。

以下にウォーム復元時におけるPhoenix環境内のデータフローを図示します。 

手順 操作

手順1

サーバーにインストールされているPhoenixエージェントが、WAN経由で90日以内のデータに対する復元リクエストを送ります。

手順2

Phoenixマスターはリクエストを検証し、ストレージに割り当てます。 

手順3

PhoenixエージェントはPhoenixマスターが割り当てたストレージからデータを復元します。

コールドリストアの手順 

コールド復元は90日以上経過したスナップショット (コールドスナップショット) を使用するデータの復元です。

以下にコールド復元時におけるPhoenix環境内のデータフローを図示します。

手順 操作

手順1

サーバーにインストールされているPhoenixエージェントが、WAN経由で90日以上経過したデータの復元リクエストを送ります。

手順2

Phoenixマスターはリクエストを検証し、アーカイブストレージに割り当てます。アーカイブストレージは復元のためのデータを準備するため、解凍処理を開始します。Phoenixは進行中の解凍操作について知らせる電子メールを管理者に送信します。 

手順3

データは解凍状態となり、復元の準備ができます。このデータはPhoenixマスターが割り当てたウォームストレージで利用可能です。

手順4 

Phoenixエージェントは、Phoenixマスターが割り当てたウォームストレージからデータを復元します。 

ファイルサーバーバックアップの手順 

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

本項ではWindowsおよびLinuxオペレーティングシステムを使用したファイルサーバーからのデータバックアップの手順図と手順について説明します。

注意:  バックアップ中にサーバーを再起動やリブートすると、バックアップ操作は中断されます。Phoenixエージェントは、バックアップスケジュールに従って新しいバックアップを開始します。または、いつでも手動バックアップが行えます。 

Windowsオペレーティングシステムのファイルサーバー

ここではWindowsオペレーティングシステムのファイルサーバーにおけるデータバックアップのデータフローについて説明します。

File server backup on Windows

 

バックアップ手順

手順 操作

手順1

バックアップ要求が開始され、Phoenixエージェントに転送されます。

手順2

 

PhoenixはPhoenixエージェントが動作していることをチェックします。

  • エージェントが実行されている場合、Phoenixはバックアップ操作を実行します。
  • エージェントが実行されていない場合、Phoenixはバックアップジョブの種類によってバックアップ操作を実行します。
    • “Backup Now” ジョブでは、バックアップ要求をキューに入れます。バックアップ要求はPhoenixエージェントの起動後に実行されます。
    • スケジュールされたジョブの場合、バックアップ要求をスキップします。 .

手順3

 

Phoenixはバックアップの種類を決定します。

管理者によりバックアップが開始され、それが最初のバックアップである場合、Phoenixはフルバックアップを実行します。管理者により起動された2回目以降のバックアップの場合、Phoenixは増分バックアップを実行します。

手順4

PhoenixエージェントはVSSサービスが実行中であることを確認します。VSSサービスが実行されていない場合、PhoenixエージェントはVSSサービスを開始し、VSSにスナップショットの作成を指示します。

手順5

Phoenixエージェントはバックアップの実行に必要な時間を見積もります。

手順6

Phoenixエージェントはスナップショットが正常に作成されたことを検証します。

手順7

 

  1. スナップショットが正常に作成された場合、PhoenixエージェントはVSSスナップショットをPhoenixクラウドへのデータバックアップ用のファイルセットとして使用します。
  2. スナップショットが正常に作成されない場合、Phoenixエージェントはライブのファイルおよびフォルダーをスキャンし、Phoenixクラウドへのデータバックアップ用のファイルセットを作成します。

 

注意: VSSスナップショットの場合、Phoenixはロックされたファイルをバックアップに含めます。ただし、ライブのフォルダーおよびファイルのスキャンの場合、Pheonixはロックされたファイルを不足ファイルとみなし、次回のスケジュールバックアップ時にそのファイルをバックアップしようとします。

手順8

バックアップが完了すると、Phoenixエージェントは作成したスナップショットを削除します。

Linuxオペレーティングシステムのファイルサーバー

ここではLinuxオペレーティングシステムのファイルサーバーにおけるデータバックアップのデータフローについて説明します。

File server backup on Linux

 

バックアップ手順

手順 操作

手順1

バックアップ要求が開始され、Phoenixエージェントに転送されます。

手順2

PhoenixはPhoenixエージェントが動作していることをチェックします。

  • エージェントが実行されている場合、Phoenixはバックアップ操作を実行します。
  • エージェントが実行されていない場合、Phoenixはバックアップジョブの種類によってバックアップ操作を実行します。
    • “Backup Now” ジョブでは、バックアップ要求をキューに入れます。バックアップ要求はPhoenixエージェントの起動後に実行されます。
    • スケジュールされたジョブの場合、バックアップ要求をスキップします。

手順3

Phoenixはバックアップの種類を決定します。

管理者によりバックアップが開始され、それが最初のバックアップである場合、Phoenixはフルバックアップを実行します。管理者により起動された2回目以降のバックアップの場合、Phoenixは増分バックアップを実行します。

手順4

Phoenixエージェントはファイルサーバー上でライブのファイルとフォルダーのフルスキャンを実行します。

手順5

Phoenixエージェントはバックアップの実行に必要な時間を見積もります。 

手順6

Phoenixエージェントはスキャンしたフォルダーとファイルをデータ転送用のファイルセットとして使用します。

注意: Phoenixはロックされたファイルを不足ファイルとみなし、次回のスケジュールバックアップ時にそのファイルをバックアップしようとします。

 

ファイルサーバーリストアの手順

同一ファイルサーバーへのリストア

別のファイルサーバーへのリストア 

手順 操作

手順1

管理者がリストア操作を開始します。

元の場所または別の場所にデータを復元できます。別の場所の場合、「同じサーバー上の異なるパス」または「別のサーバー上の異なるパス」にすることができます。

選択したファイルサーバーの復元ポイントに対してリストアを実行する宛先サーバーを選択します。たとえば、Windowsリストア用のWindowsサーバーと、Linuxリストア用のLinuxサーバーがあります。

手順2

PhoenixはPhoenixエージェントが動作していることを確認します。

  • エージェントが実行されている場合、Phoenixはリストア操作を実行します。
  • エージェントが実行されていない場合、Phoenixはリストア要求をキューに入れ、Phoenixエージェントの起動後にリストア操作を実行します。

手順3

Phoenixは復元先を検証します。 

手順4

Phoenixは復元先で使用可能な空き容量をチェックします。

手順5

Phoenixはリストアするファイルセットを特定します。

手順6

Phoenixは復元操作を開始し、ファイルセットを復元先に順次ダウンロードします。

 注意: ファイルサーバーのリストア詳細については同一サーバー上でのリストア新規サーバー上でのリストアを参照してください。

NAS共有のバックアップ手順 

以下にWindowsまたはLinux上でNAS共有をバックアップするときのデータの流れを図示します。 

NASBackupWorkflow.png

 

以下に手順をまとめます。 

手順 操作

手順 1

 バックアップ要求が開始され、NASプロキシに転送されます。 

手順 2

 

Phoenix はNASプロキシが動作しているか確認します。 

  • プロキシが動作していれば、Phoenixはバックアップを実行します。
  • プロキシが動作していない場合、 Phoenix はバックアップジョブ種別によって以下のようにバックアップを実行します。
    • backup now ジョブの場合、Phoenix はバックアップ要求をキューイングします。Phoenix はNASプロキシが動作開始したら要求を遂行します。
    • スケジュールジョブの場合、Phoenix はバックアップ要求をスキップします。

手順 3

 

Phoenix はバックアップ種別を決定します。

これがデータソースからの初回バックアップの場合、Pheonixはフルバックアップを実施します。以降のバックアップは増分バックアップになります。

手順 4

Phoenix エージェントはNAS共有上のファイルおよびフォルダーのフルスキャンをを実行します。

手順 5

NAS プロキシはバックアップ用にスキャンしたファイルやフォルダーをPhoenixクラウドへ送信します。

Note: Phoenix が初回試行でロックされたファイルのバックアップが行えない場合、バックアップ終了時にそのファイルがロック解除されたか確認します。ファイルがロック解除された場合、同じバックアップジョブでそれらファイルをバックアップします。ロックされているファイルはバックアップされません。
手順 6 Phoenix クラウドは重複排除を適用し、スナップショットに増分データを保存します。
バックアップ元NAS共有へのリストア手順 

RestoreToSameLocation.png

別のNAS共有へのリストア手順 

RestoreToAlternateLocation.png

NAS デバイスのリストア手順

手順 操作

手順 1

管理者がリストア操作を開始します。

選択したNAS復元ポイントをリストアする際のバックアップ先の共有を選択できます。たとえば、SMB共有はWindowsリストアに、NAS共有はLinuxリストアになります。

手順 2

PhoenixはNASプロキシが実行中かどうかを確認します。 

  • プロキシが動作していれば、Phoenixはリストアを実行します。
  • プロキシが動作していない場合、 Phoenix はリストア要求をキューイングし、NASプロキシが動作開始したらリストア要求を実行します。

手順 3

Phoenix はリストア先の共有種別がバックアップ元と同じかどうか確認し、リストア要求を検証します。

手順 4

Phoenix はリストアするスナップショットを識別します。

手順 5

Phoenix はリストア操作を開始し、スナップショットをリストア先に順次ダウンロードします。

 Note: NAS共有リストアに関する詳細は NAS共有のリストア を参照してください。

NAS共有リストアについて知っておくべきこと 

本セクションでは、NAS共有リストアの重要な考慮事項を示します。

  • ホットスナップショットは、CloudCache設定で指定された期間Phoenix CloudCacheに置かれます。設定の詳細については Configure Phoenix CloudCacheCloudCache を参照してください。
  • グループ管理者の場合、管理する管理グループに属するNAS共有のデータのみをリストアできます。クラウド管理者は、すべての管理グループのNAS共有にデータをリストアできます。
  • バックアップ元のNAS共有と同じオペレーティングシステムであるNAS共有にのみデータをリストアできます。
  • リストア中にネットワーク接続に障害が発生した場合、NASプロキシはPhoenixクラウドとの接続を試みます。ネットワーク接続が復旧すると、NASプロキシは中断された状態からリストアを再開します。
  • リストア中にNASデバイスを再起動すると、リストア操作は中断されます。
  • 同じ場所にデータをリストアすることを選択した場合、別のリストア設定が行われていない限り、その場所の既存データは上書きされます。
  • スナップショットのタイムスタンプはサーバーのタイムゾーンに従って表示されます。たとえば、ニューヨークとロンドンにサーバーがある場合、タイムスタンプはそれぞれESTとUTCタイムゾーンに従って表示されます。
  • ネットワークドライブへのリストアはサポートされていません。
  • SMB 共有の場合:
    • 以下のファイル属性がサポートされます:
      • Not content-indexed
      • Read-only
    • すべての アクセス制御リスト (ACL) がリストアされます。
  • NFS 共有の場合:
    • ファイルオーナー、グループ、ユーザーのファイルパーミッションはリストアされます。
    • ファイル属性はサポートされません。
    • ACL 権限はサポートされません。
    • ファイルやフォルダー向けの以下の特殊パーミッションはサポートされません。
      • Setgid
      • Sticky bit
      • Setuid
  • 同一エージェント上でバックアップとリストアは同時に実行できます。
  • リストア実行中に起動したバックアップ要求はキューイングされます。
  • フルスキャンのリストアは  アイコンで表示されます。
 

MS-SQLサーバーのバックアップ手順

フルバックアップ

PhoenixはMS-SQLサーバのデータベースの永久増分バックアップを実行します。前提条件で述べたように、バックアップおよびリストア操作ではVSSおよびSQLライターサービスを利用します。バックアップポリシーに基づいてフルバックアップが開始されると、PhoenixエージェントはVSSフレームワークを使用してSQLライターサービスと通信します。Phoenixエージェントは、バックアップに含まれるすべてのデータベースのフルスキャンを実行します。データベースの初回バックアップでは、すべてのデータベースがフルバックアップされます。データベースのバックアップが初回以外の場合は、データベースのフルスキャンが実行されますが、重複排除が適用された後にデータベースの更新のみがバックアップされます。バックアップジョブが成功すると、Phoenixはストレージにスナップショット(復元ポイント)を作成します。

フルバックアップを使用して作成されたスナップショットについて

日次保存期間 (daily retention period) としてすべてのスナップショットを保存する日数を指定すると、その期間内に作成されたすべてのスナップショットが保存されます。

たとえば保存期間として、すべてのスナップショットを10日間保持するように指定するとします。バックアップポリシーでは、フルバックアップが毎週水曜日の12:00:00 PMに実行されるようにスケジュールされています。

2017年2月1日から2017年2月28日の間、水曜日は1日、8日、15日、22日です。フルバックアップが2017年2月1日に開始され、ジョブが成功した午後4:00:00にスナップショットが作成されたとします。

2017年2月8日に、もう一つのフルスナップショットが午後3:00:00に作成されました。すべてのスナップショットは10日間保持されるため、2017年2月11日午後11時59分59秒より前である2017年2月1日と2017年2月8日に作成されたフルスナップショットは保持されます。2017年2月11日午後11時59分59秒以降は、2017年2月1日のスナップショットは週次、月次、年次の保存期間に基づいて保持されます。

フルバックアップ後に作成されたスナップショットからデータベースを復元する

たとえば、2017年2月12日の午前11:00:00にデータベースをリストアするとします。Phoenix管理コンソールからリストアジョブを起動すると、データを復元するために以下のスナップショットの選択肢が表示されます。

  • ホット (Hot)
  • ウォーム (Warm)
  • 解凍済み (Thawed)
  • コールド (Cold)

Phoenixは90日間、スナップショットをウォームストレージに保存します。2017年2月1日に作成されたスナップショットが、2017年2月5日午後11時59分59秒に終了した週の最新スナップショットである場合、週次保持期間に基づいて保存されます。2017年2月1日と2017年2月8日に作成されたスナップショットは、ウォームスナップショットに分類されます。ウォームスナップショットを使用するとデータベースを直接復元できます。コールドスナップショットを使用してデータベースを復元するには、まずそれを解凍する必要があります。スナップショットを解凍すると、解凍済みスナップショットとして表示されるので、それを使用してデータベースを復元できます。11月に作成され保存期間に基づいて保持されているスナップショットは、この例でコールドスナップショットと見なすことができます。

Phoenix CloudCacheを設定していれば、ホットスナップショットが表示されます。Phoenix CloudCacheとホットスナップショットの詳細については、Phoenix CloudCacheを参照してください

ワークフロー

フルバックアップには次の手順が含まれます。

  1. Phoenixはエージェントが実行されているかどうかを確認します。エージェントが実行されていない場合、Phoenixはバックアップリクエストをキューに入れます。Phoenixエージェントの起動後にこのリクエストが実行されます。
  2. バックアップ操作が開始される前に、エージェントはVSSサービスおよびSQLライターサービスが実行されているかどうかを確認します。サービスが実行されていない場合、エージェントはこれらのプロセスを自動的に起動します。
  3. 概算フェーズで、エージェントはボリュームシャドウコピーAPIを使用してMS-SQLサーバーからデータベース情報を取得します。
  4. その後、エージェントはバックアップする必要がある個別のファイルセットを決定します。VSSはスナップショットを提供します。
  5. データベースの初回バックアップ時は、スナップショット全体がバックアップされます。データベースの初回バックアップ以外の場合は、ファイルセットの中で更新されたデータがスナップショットからコピーされ、サーバーにアップロードされます。データがサーバーに正常にアップロードされた後、バックアップは成功のステータスになります。

追加情報

  • VSSスナップショットは一時的なもので、オペレーティングシステムによって自動的に削除されます。ハードドライブにアクセスできない場合、VSSおよびMS-SQLサーバーは内部ファイル情報の認識や更新に時間がかかることがあります。
  • データベースファイルが削除済みファイルを含むパーティションに移動された時間にバックアップが起動した場合、バックアップが失敗する可能性があります。
  • VSSおよびMS-SQLサーバーが内部ファイル情報を更新した後に、バックアップジョブは正常完了します。ただし、いくつかのデータベースファイルが削除済みファイルパーティションに移動され、他のいくつかのファイルが論理パーティションでまだ利用可能である場合、バックアップは常に失敗します。回避策として、このデータベースを手動でクリーンアップする必要があります。
  • システムデータベース tempdb はバックアップされません。
  • バックアップ時、データベースエンティティは次の順序でバックアップされます。
    • データベースファイル:MDFファイル、LDFファイル、NDFファイル
    • エージェント固有のメタデータ(JSONデータ)
    • VSSバックアップドキュメント(XMLデータ)
    • SQL Writerメタデータドキュメント(XMLデータ)
    • Sentinel(JSONデータ)
  • サーバー上で
    • DB1のファイルがC:\Dataにある
    • DB2のファイルがC:\Dataにある
    • DB3のファイルがC:\Program Files\Dataにある

という場合、エージェントはC:\Data と C:\Program Files\Data を2つのファイルセットとして識別し、順番にアップロードします。ただし、ファイルセット内のファイルは並行してアップロードされます。

差分バックアップ

MS-SQLサーバーは差分バックアップ機能を提供します。差分バックアップが起動すると、エージェントは更新されたデータベースに関する情報を要求します。Phoenixは差分データをバックアップし、ストレージにスナップショットを作成します。フルバックアップのスナップショットが存在する場合に差分バックアップを実行できます。フルバックアップのスナップショットが存在しない場合、差分バックアップは自動的にフルバックアップジョブに変換されます。詳しくは、SQL差分バックアップが完全バックアップに変換されるシナリオを参照してください。

注:  [ Backup Now ]をクリックすると、差分バックアップが開始されます。ただし、サーバーの初回バックアップ時はフルバックアップが開始されます。 手動バックアップは、指定した帯域幅による制限が行われず、利用可能な最大帯域幅が使用されます。

差分バックアップを使用して作成されたスナップショットについて

差分バックアップによって作成されたスナップショットは、データベースの復元に使用できるスナップショットを作成するという点で、フルバックアップジョブと同様に機能します。差分バックアップジョブは、フルバックアップジョブと比較して実行が速くなる可能性があるため、フルバックアップの間に複数の差分バックアップをスケジュールできます。

前の例の続きで、毎日午後9:00:00に差分バックアップを指定したとします。2017年2月1日から2017年2月10日までの間に、10個の差分スナップショットが作成されます。2017年2月11日午前5:00:00にスナップショットを使用してデータベースをリストアしようとすると、ウォームスナップショットとして12個のスナップショット(フルバックアップのスナップショット2件と差分バックアップのスナップショット10件)が表示されます。差分スナップショットも、日次、週次、月次、年次の保存期間に基づいて保持されます。

差分バックアップの利点は、バックアップジョブの速度です。エージェントはSQLサーバーから更新されたデータベースに関する情報を直接取得するため、差分バックアップジョブはフルバックアップよりも高速です。

差分バックアップを使用して作成されたスナップショットからのリストア

2017年2月13日の午前11:00:00にデータベースをリストアする場合は、

  • 2017年2月1日と2017年2月2日の差分バックアップの後のスナップショットは消去されます。
  • ウォームスナップショットとして、2017年2月3日から2017年2月12日までに作成された差分バックアップ時のスナップショットを確認できます。
  • 2017年2月1日と2017年2月8日のフルバックアップ時に作成されたスナップショットを見ることができます。

上記のスナップショットはすべてウォームスナップショットに該当するため、任意のスナップショットを復元ポイントとして選択し、それを使用してデータベースを復元できます。ただし、差分バックアップの後に作成されたスナップショットを選択すると、Phoenixはその直前に作成されたフルバックアップスナップショットを使用します。通常、2017年2月1日に作成されたフルバックアップスナップショットは、10日間の保存期間に基づいて消去されます。しかし、リストアに2017年2月8日より前に作成された差分スナップショットを選択した場合、Phoenixは2017年2月1日に作成されたフルバックアップスナップショットを必要とするため、 2017年2月1日のスナップショットは保持されます。

ワークフロー

差分バックアップには次の手順が含まれます。

  1. Phoenixはエージェントが実行されているかどうかを確認します。エージェントが実行されていない場合、Phoenixはバックアップリクエストをキューに入れます。Phoenixエージェントの起動後にリクエストが実行されます。
  2. バックアップ操作が開始される前に、エージェントはVSSサービスおよびSQLライターサービスが実行されているかどうかを確認します。サービスが実行されていない場合、エージェントはこれらのプロセスを自動的に起動します。
  3. 概算フェーズで、エージェントはボリュームシャドウコピーAPIを使用してSQL Serverからデータベース情報を取得します。
  4. 差分バックアップの場合、SQL Serverは最終バックアップ以降のデータベースに対する更新を提供します。Phoenixはこれらの変更をサーバーにアップロードします。ファイルがサーバーに正常にアップロードされると、バックアップは成功のステータスとなります。

追加情報

次の場合、Phoenixは差分バックアップをフルバックアップとして扱います。 

  • フルバックアップが完了していないデータベースの差分バックアップが試行されたとき 
  • 最終バックアップ以降、新しいデータベースファイルがデータベースに追加されたか、データベースから削除されたとき
  • データベースファイルが、最終バックアップ以降に名前変更または移動されたとき
  • データベースの名前が変更されたとき
  • アップロードされたデータベースファイルとそのメタデータ間の不一致が検出されたとき 
  • マスターデータベースが最終フルバックアップに含まれており、マスターデータベースファイルのパスまたは名前が最終フルバックアップ以降に変更されたとき
  • Phoenixがボリュームシャドウコピーサービスからデータ変更に関する詳細を取得できなかったとき
  • フルバックアップが失敗すると、次の差分バックアップはフルバックアップに変換されます。
  • フルバックアップがPhoenix MS-SQLエージェントによって実行され、2回目のフルバックアップがサードパーティのバックアップツールまたはMS SQLサーバーによって実行された場合。その後、Phoenixエージェントは次の差分バックアップを完全バックアップに変換できます。 
  • 前回のフル/差分バックアップ以降にデータベースが縮小されたと判断した場合、Phoenixは後続の差分バックアップをフルバックアップに変換します。 

トランザクションログのバックアップ

MS-SQLサーバーのトランザクションログには、サーバーに対するすべての変更が記録されます。Phoenixは、バックアップポリシーで指定した間隔に基づいてトランザクションログを適時バックアップし、フルまたは差分バックアップが完了した後に起動します。Phoenixがトランザクションログをバックアップすると、MS-SQLサーバー上のトランザクションログは切り捨てられます。サーバーのフルバックアップが一度も完了しない場合、トランザクションログのバックアップは開始されません。トランザクションログはより厳密なRPOを提供し、フルバックアップまたは差分バックアップを使用して作成されたスナップショットに依存します。ログバックアップは、単純復旧 (simple recovery) モードのデータベースには適用されません。 

ログバックアップスケジュールについて

バックアップされたトランザクションログは、日次保存期間に基づいて保持されます。週次、月次、年次の保存ポリシーはログバックアップには適用されません。

たとえば、ログバックアップの間隔を30分に指定したとします。上記の例では、フルバックアップは2017年2月1日午後12:00:00に開始され、2017年2月1日午後4:00:00に完了しましたが、この場合、午後4時30分にログバックアップが開始されます。その後、差分バックアップが開始される午後9時00分まで30分ごとにトランザクションログがバックアップされます。

トランザクションログからの復元

トランザクションログを使用してデータベースを復元すると、次のことが可能になります。

  • トランザクションが発生した時点 (point-in-time) の選択
  • トランザクションログでマークされたトランザクションを選択して、データベースをその時点にリストア
  • トランザクションが発生した時点を選択し、データベースをスタンバイモードのままにする

ポイントインタイムトランザクションまたはマーク付きトランザクションを選択すると、Phoenixはスナップショットを使用してデータベースを復元します。スナップショットを使用してデータベースを復元すると、選択したトランザクションまでトランザクションログがデータベースに適用されます。これにより、2つのスナップショット間の時点にデータベースを復元できるようになるため、RPOを短くすることができます。

ワークフロー 

次のフローチャートは、トランザクションログのワークフローを示しています。

tmp.png

AGバックアップセット向けトランザクションマークのバックアップ / リストアの制限 

ログバックアップがセカンダリノードで実施された場合、Phoenixはトランザクションマークをバックアップしません。 

MS-SQLサーバーは、可用性グループ(AG)内のデータベースのセカンダリノードで、トランザクションログに関連するトランザクションマークを複製しません。PhoenixのAGバックアップセットのトランザクションマークをリストアしようとすると、ログバックアップがプライマリノードとセカンダリノードのどちらで行われたかによって、MS-SQLサーバー上に作成されたトランザクションマークが表示される場合と表示されない場合があります。 

MS-SQL Serverの復元ワークフロー

データベーススナップショットの復元ワークフロー

次の手順では、インスタンスまたはAGのデータベースのスナップショットリストアをトリガーしたときのリストアジョブについて説明します。

手順 操作

1

あなたまたは別の管理者が復元を開始します。 

2

Phoenixは、Phoenixエージェントが実行されているかどうかを確認します。 

  • エージェントが実行中の場合、Phoenixは復元操作を実行します。
  • エージェントが実行されていない場合、Phoenixは復元要求をキューに入れます。リクエストは、MS-SQLサーバー上のPhoenixエージェントが実行を開始した後に実行されます。
Phoenixは、復元先(元のインスタンスまたは別のMS-SQLサーバー)を検証します。 

4

Phoenixは、復元先がドライブではないかどうかを検証します。たとえば、D:\への復元は失敗します。 

:復元場所をドライブではなくサブフォルダーに設定します(例:D:\ ThisFolder)。  

5 Phoenixは、復元が開始されたインスタンスが使用可能かどうかを検証します。 
6 Phoenixは、復元用のデータベースが利用可能かどうかを検証します。 
7 Phoenixは、復元先で利用可能な空き領域を確認します。 

8

Phoenixは、復元するファイルセットを特定することから復元操作を開始します。Phoenixは、ファイルセットを復元先に順次ダウンロードします。ファイルセット(複数のデータベースに属するデータが含まれている可能性があります)内で、Phoenixは異なるデータベースに属するファイルの同時ダウンロードを実行します。ファイルセットのダウンロードが完了すると、Phoenixは次のファイルセット(1つ以上のデータベースに属するデータも含まれている可能性があります)を復元先にダウンロードします。

9

Phoenixは、リストアに次の構文を使用します:<宛先パス> \ <スナップショット> \ <リクエストID> \ <ファイルセット> \ <実際のファイル>。<Request ID>フォルダーは、各復元要求を一意に識別します。

10

さらに、Phoenix  はD:\ restore \ <snapshot> \ <Request ID>にdatabase_files.txtファイル  も作成し  ますこのファイルには、データベースファイルがデータベースにマップされる方法、およびデータベースがそのインスタンスにUnicode形式でマップされる方法の詳細が含まれています。 

11

指定した場所で、Phoenixはデータベースをrst_ <データベース名>として復元します。ただし、その場所にrst_ <データベース名>がすでに存在していることがPhoenixによって検出されると、データベース名に増分カウンターが追加されます。たとえば、データベースDBの復元時に、Phoenixが以前の復元操作でrst_DBを見つけた場合、データベースDBはrst_DB_1として復元されます。カウンターは、既存の復元データセットが出現するたびに1ずつ増加します。
12 AGに復元する場合、PhoenixはAGのすべてのセカンダリノードで手順9を繰り返します。Phoenixは、提供された共有ネットワークの場所にデータベースをバックアップし、復元されたデータベースは、AGのすべてのプライマリノードとセカンダリノードに複製されます。 

13

復元が完了したら、

  1. 「回復モード」を選択すると、指定したインスタンスのデータベースがアクティブになります。 
  2. 「復旧モードなし」を選択した場合、指定したインスタンスのデータベースは「復旧中」として表示されます。
  3. 「追加のトランザクションログの復元を許可するスタンバイモード」が選択されている場合、データベースは指定したインスタンスのスタンバイ/読み取り専用として表示されます。 
  4. [可用性グループに復元]が選択されている場合、データベースはAGのすべてのノードで同期されているように見えます。

ポイントインタイムの復元ワークフロー

次の表は、トランザクションログを使用したポイントインタイムリストアワークフローを示しています。

手順 操作

1

ポイントインタイムリストアを開始します。

2

 

Phoenixは、Phoenixエージェントが実行されているかどうかを確認します。 

  • Phoenixエージェントが実行されている場合、Phoenixは復元ジョブを実行します。
  • Phoenixエージェントが実行されていない場合、Phoenixは復元ジョブをキューに入れます。Phoenixエージェントが実行を開始すると、復元ジョブが完了します。 

Phoenixは、復元先(元のグループ、代替グループ、または可用性グループ)と復元先の場所を検証します。

:場所がドライブではないことを確認してください。たとえば、C:\です。データベースを復元するには、データベースファイルをサブフォルダーに復元します。たとえば、C:\ DBFilesです。

4 Phoenixは、SQL Serverインスタンスが復元に使用できるかどうかを検証します。復元ジョブが元のデータベースを置き換える場合、Phoenixはデータベースが復元可能かどうかもチェックします。 
6 Phoenixは、復元に使用できる空き領域を確認し、復元するファイルセットを特定することによって復元ジョブを開始します。Phoenixは、ファイルセットを復元先に順次ダウンロードします。ファイルセット(複数のデータベースに属するデータが含まれている可能性があります)内で、Phoenixは異なるデータベースに属するファイルを同時にダウンロードします。ファイルセットのダウンロードが完了すると、Phoenixは次のファイルセット(1つ以上のデータベースに属するデータも含まれている可能性があります)を復元先にダウンロードします。
7 Phoenixは、リストアに次の構文を使用します:<宛先パス> \ <スナップショット> \ <リクエストID> \ <ファイルセット> \ <実際のファイル>。<Request ID>フォルダーは、各復元ジョブを一意に識別します。

8

Phoenixエージェントは、復元場所からトランザクションログを取得します。

  • ユーザーが指定した日付と時刻(または選択したマークされたトランザクション)を選択します
  • 復元が有効になっているモードを確認します。
    • リカバリモードが有効になっている場合、Phoenixはデータベースを復元し、データベースを操作可能な状態にします(これにバックアップセットを追加することはできません)。
    • リカバリ モードなしが有効になっている場合、Phoenixはデータベースを復元し、データベースをアクセスできない保留状態のままにします。 
    • スタンバイ モードが有効な場合、指定された日時に最も近いトランザクションを識別します。Phoenixは、トランザクションログを使用して、特定されたトランザクションまでデータベースの変更を復元します。さらに、ポイントインタイムリストア後にトランザクションを含むログファイルをダウンロードします。 

元のデータベースが置き換えられると、Phoenixエージェントはデータベースへのすべての接続を終了し、ダウンロードしたトランザクションログを使用してデータベースを復元します。 

9 データベースが可用性グループに復元される場合、Phoenixエージェントはデータベースを指定された共有ネットワークの場所に復元し、データベースをすべてのセカンダリノードに同期するか、利用可能な場合は自動シードを使用します。 

復元が完了した後: 

  • 場合はリカバリモードが  選択され、データベースは、指定されたことをインスタンスのアクティブとして表示されます。 
  • 復旧モードなし]  が選択されている場合、データベース は指定したインスタンスの[ 復元中]として表示されます。
  • 場合はスタンバイモードには、追加のトランザクションログのリストアできるように  選択され、指定したことをスタンバイ/読み取り専用インスタンスのように、データベースが表示されます。 
  • 可用性グループに復元]  が選択されている場合、データベースはAGのすべてのノードで同期されているように見えます。

Oracleデータベースのバックアップワークフロー

OracleのPhoenixバックアップワークフローを以下に示します。

WelcomeOracleGraphics2x.png

手順 説明
手順1 Oracleデータベース管理者は、Phoenixバックアップストア上のマウントの名前を使用してRMANスクリプトをトリガーします。RMANはOracle RMANバックアップを作成し、マウントに保存します。 

Phoenixバックアップストアは、マウントに保存されたOracle RMANバックアップのスナップショットを作成します。 
手順2 Phoenixバックアップストアは、Oracle RMANバックアップのZFSスナップショットを作成し、スナップショットにタイムスタンプを適用します。 

タイムスタンプは、RMANがOracle RMANバックアップのバックアップマウントへの書き込みを完了した後に、Phoenixバックアップストアに対して行われたPUTリクエストに対応しています。詳細については、Phoenix Backup Store APIリファレンスを参照してください
手順3 Phoenixバックアップストアは、スナップショットをPhoenixクラウドにアップロードします。このスナップショットは復元ポイントとして機能します。
スナップショットがクラウドにアップロードされると、Phoenixバックアップストアから削除されます。

データベース管理者がRMANスクリプトを実行するたびに、RMANはマウント上にOracle RMANバックアップを作成します。Phoenixバックアップストアは、RMANが作成してマウントに保存するすべての新しいOracle RMANバックアップの新しいスナップショットを作成し、スナップショットをクラウドにアップロードして新しい復元ポイントを作成します。 

RMANは、Phoenixバックアップストアで十分なストレージが利用可能になるまでバックアップデータを保存できます。十分なストレージが利用できない場合、RMANはバックアップを保存できず、バックアップジョブは失敗します。PhoenixバックアップストアからOracle RMANバックアップを定期的に削除するか、ストレージ容量を増やしてください。 

Oracleデータベースの復元ワークフロー

Oracle_workflow_restore_1.png

手順 オペレーション

手順1

Phoenixの管理者がスナップショットを選択し、復元を開始します。

手順2

Phoenixの管理者は、スナップショットを元のPhoenixバックアップストアまたは代替のPhoenixバックアップストアに復元できます。 

手順3

スナップショットが解凍され、Oracle RMANバックアップとしてPhoenixバックアップストア上の場所にダウンロードされます。Phoenix Backup Store上のOracle RMANバックアップのダウンロード場所は、  / mnt / restores / <backupmount_name> / <restore_job_id> / dataです。

  • マウント名は、復元するために選択したマウントの名前です。
  • ジョブIDは、復元ジョブのIDです。ジョブIDはジョブページから取得できます。 

手順4

スナップショットの場所はRMANホストにマッピングされているため、RMANはそのスナップショットに格納されているデータを使用して、データベースをOracleインスタンスに復元できます。 

手順5

データベース管理者は、Oracle RMANバックアップをOracleインスタンスに復元します。  

VMware仮想マシンバックアップの手順

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

Phoenixは仮想マシンが含まれるサーバーグループに関連付けられたバックアップポリシーに定義されたスケジュールに基づいて、またはPhoenix管理コンソールから実行されたオンデマンド・バックアップによって、仮想マシンのバックアップを実行します。これにはPhoenixコンポーネントとVMwareコンポーネントの連係動作が含まれます。

以下の図に仮想マシンのバックアップ時のデータフローを示します。

仮想マシンバックアップの手順

手順 操作

手順1

仮想マシンのバックアップ要求は以下により開始されます。

  • バックアップポリシーで定義されたスケジュール
  • 手動バックアップ

Phoenixはバックアップ要求をバックアッププロキシプールに転送します。

  • Phoenixは負荷分散アルゴリズムによって、バックアップ要求を実行するバックアッププロキシを自動的に識別します。
  • 識別されたバックアッププロキシがビジー状態の場合、バックアッププロキシが解放されたときにバックアップ要求がキューイングおよび開始されます。

手順2

  • vCenterサーバーによって管理されるESXiホストに仮想マシンがデプロイされる環境では、バックアッププロキシはvCenterサーバーに接続して仮想マシンを検出し、その構成を取得します。
  • 仮想マシンがスタンドアロンESXiホストにデプロイされている環境では、バックアッププロキシはESXiホストに接続して仮想マシン構成を取得します。

バックアッププロキシはESXiハイパーバイザーまたはvCenterサーバーに仮想マシンのVMDKファイルとVMXファイルを問い合わせます。   

手順3

Phoenixはバックアップの種類を決定します。

  • これが初回の自動バックアップである場合、Phoenixはフルバックアップを実行します。
  • 2回目以降のすべてのバックアップでは、Phoenixは増分バックアップを実行します。

バックアッププロキシは仮想マシンのスナップショットを取得し、バックアップの準備を行います。

手順4

VDDKコネクションがSSL転送モードで仮想マシンと確立されます。

手順5

バックアッププロキシは仮想マシンと接続し、仮想マシンデータをバックアップするための読み取り専用コネクションを確立します。

手順6

バックアッププロキシは仮想マシンのスナップショットを使用してバックアップ用のVMDKファイルを読み取ります。仮想マシンのデータをコピーし、Phoenix CloudCache (設定されている場合) またはPhoenixクラウドに送信する準備をします。

NBDモードによる暗号化されたvmdkバックアップはサポートされていません。暗号化されたvmdkディスクは、NBDSSLまたはHotAddを使用してバックアップできます。仮想マシンのディスクバックアップでサポートされている転送モードは以下の通りです。

バックアッププロキシ 仮想マシン 転送モード
暗号化 暗号化 HotAdd
非暗号化 暗号化 NBD-SSL
暗号化 非暗号化 HotAdd

手順7

バックアッププロキシはスナップショットデータを連続ストリームでPhoenixクラウドに転送します。データをPhoenixクラウドに転送する前に、バックアッププロキシは重複排除を実行します。

バックアップが完了すると、バックアッププロキシはスナップショットを削除します。

仮想マシンのバックアップに関する詳細は Backup and Restore VMware Virtual Machines.を参照してください。

VMware仮想マシンリストアの手順

 

 

手順 操作

手順1

 

Phoenix管理者が仮想マシンのリストアを開始します。Phoenixはリストア要求をバックアッププロキシプールへ転送します。

  • Phoenixは負荷分散アルゴリズムによって、リストア要求を実行するバックアッププロキシを自動的に識別します。
  • 識別されたバックアッププロキシがビジー状態の場合、バックアッププロキシが解放されたときにリストア要求がキューイングおよび開始されます。

 

手順2

Phoenixはリストア場所がNAS (Network-attached Storage) でないことを確認します。

  • vCenterサーバーによって管理されるESXiホストに仮想マシンがデプロイされる環境では、バックアッププロキシはvCenterサーバーに接続して仮想マシンを検出し、その構成を取得します。
  • 仮想マシンがスタンドアロンESXiホストにデプロイされている環境では、バックアッププロキシはESXiホストに接続して仮想マシン構成を取得します。

手順3

VDDKコネクションがSSL転送モードで仮想マシンと確立されます。

手順4

バックアッププロキシは、フル仮想マシンリストアまたはVMDKファイルリストアかをチェックします。バックアッププロキシは仮想マシンに接続し、仮想マシンデータを復元するための書き込み接続を確立します。

  • フル仮想マシンリストアの場合、Phoenixは同じ構成 (バックアップ時の仮想マシン構成) を持つ新しい仮想マシンを以下の名前で作成します。

<元の仮想マシン名>_<カウンタ>

  • ディスクリストアでは、最小構成 (100MB RAM、1 CPU, 1つのビデオカード、リストアするディスク) で指定した場所に以下の名前で新しい仮想マシンを作成します。

<元の仮想マシン名>_<カウンタ>

注意: ディスクリストアでは、仮想マシンを作成せずにディスクを作成することはできないため、最小構成の仮想マシンを作成します。

手順5

バックアッププロキシはPhoenixクラウドから仮想マシンデータを取得します。

手順6

リストア操作が開始されます。

Phoenixはリストアが正常に完了したかチェックします。

  • リストアが正常に完了すると、新しい仮想マシンが使用可能になります。
  • リストアが失敗した場合、Phoenixは新しく作成した仮想マシンを削除します。

Hyper-V仮想マシンのバックアップワークフロー

Phoenixエディション: ファイル:/tick.pngBusiness Enterprise Elite ファイル:/cross.png ファイル:/tick.png

Phoenixは、バックアップポリシーで定義されたスケジュールに基づいて、またはPhoenix管理コンソールからバックアップがトリガーされた場合に、仮想マシンをバックアップします。バックアップのワークフローを以下に説明します。

hyperV_backup_workflow-4.png

仮想マシンのバックアップワークフロー

手順 操作

手順1

仮想マシンのバックアップ要求は、以下に基づいて開始されます。

  • バックアップポリシーで定義されたスケジュール。
  • オンデマンドバックアップ

Phoenixは、バックアップ要求をエージェントに転送します。

手順2

Phoenixエージェントは、VSS  サービスが実行されていることを確認し  ます。Phoenixエージェントは、VSSサービスにスナップショットの作成を要求します。VSSサービスが実行されていない場合、PhoenixエージェントはVSSサービスを開始し、VSSにスナップショットを作成するように指示します。

Druvaでは、Hyper-V統合サービスでバックアップ(ボリュームスナップショット)を有効にすることをお勧めします。バックアップ(ボリュームスナップショット)が有効な場合、VSSサービスは仮想マシン上のサービスを中断することなくスナップショットを作成できます。

Phoenixエージェントは、スナップショットが正常に作成されたかどうかを検証し、バックアップジョブを開始します。
Windows Server 2008およびWindows Server 2008 R2ホストの場合:

注: Integration Servicesは、WindowsゲストOSを備えた仮想マシンで使用できます。ただし、Microsoftは特定のLinuxディストリビューションにも統合サービスを提供しています。詳細については、以下を参照してください。 仮想マシンで統合サービスを利用できない場合、Phoenixはスナップショットを取得できず、バックアップは失敗します。

Windows Server 2016以降では、Phoenixエージェントは、以下の場合に、Resilient Change Tracking(RCT)機能を使用して仮想マシンをバックアップできます。

  • ホストにインストールされているPhoenixエージェントが4.7.5以降であり、かつ
  • 仮想マシン構成のバージョンは6.2以降です。仮想マシンがHyper-Vクラスターでホストされている場合、仮想マシンクラスターの機能レベルはレベル9以上である必要があります。 

Phoenixエージェントは、上記の条件を満たすHyper-VホストでRCTを使用して仮想マシンをバックアップできます。

  • バックアップジョブ間で仮想マシンの変更内容を効率的に追跡します
  • 増分バックアップはより高速になります

注: Phoenixエージェントは、基準を満たすホストから初めて仮想マシンをバックアップする場合、RCT機能を使用して仮想マシンのスナップショットを取得できます。VSSを使用して作成されたホストからの仮想マシンのスナップショットが存在する場合、Phoenixエージェントは引き続きVSSを使用します。ただし、次の場合:

  • 上記の基準を満たすホストからのVSSスナップショット、および
  • 後続のバックアップジョブでRCT機能を使用する   

ホスト上のPhoenixエージェントをアップグレードし、バックアップ方法をRCTに変更します。  

手順3

Phoenixがバックアップのタイプを決定します。 

  • これが最初の自動バックアップである場合、Phoenixは完全バックアップを実行します。 
  • それ以降のすべてのバックアップでは、Phoenixは増分バックアップを実行します。 

 

手順4

エージェントはバックアップ用のデータを推定します

手順5

エージェントは、VSS提供のスナップショットに基づいてデータをバックアップします

次の手順

バックアップと復元のためにPhoenixを構成する場合は、以下を参照してください。

詳細については、以下を参照してください。

Hyper-V仮想マシンの復元ワークフロー

hyperV_restore_workflow-2.png

手順 オペレーション

手順1

Phoenix管理者が仮想マシンの復元を開始します。Phoenixは、復元要求をHyper-Vサーバーエージェントに転送します。

仮想マシンを元の場所または別の場所に復元できます。Phoenixエージェントがアクティブ化されており、宛先Hyper-VサーバーがホストとしてPhoenixに登録されていることを確認します。 

手順2

Phoenixは、Phoenixエージェントが実行されているかどうかを確認します。エージェントが実行中の場合、Phoenixは仮想マシンを復元します。エージェントが実行されていない場合、エージェントがバックアップと復元の準備ができるまで、復元ジョブはキューに入れられます。 

手順3

Phoenixエージェントは、宛先のHyper-Vサーバーに仮想マシンを復元するのに十分なストレージがあるかどうかを確認します。

手順4

Phoenixエージェントは、仮想マシンの完全な復元か仮想ディスクの復元かを確認します。エージェントはサーバーに接続し、書き込み接続を確立して仮想マシンデータを復元します。

  • 完全な仮想マシンの復元の場合、Phoenixは、同じ構成(つまり、バックアップ時の仮想マシンの構成)を持つ新しい仮想マシンを同じ場所に次の構文で作成します。 
    元の場所の復元の場合:<Name元の仮想マシンの> _ <カウンター>
    代替リストアの場合<ユーザー指定の仮想マシン名> _ <カウンター>
  • ディスクの復元の場合、Phoenixは選択した場所にディスクを復元します。 

手順5

Phoenix CloudはスナップショットをHyper-Vサーバーエージェントに送信します。

手順6

復元操作が開始されます。

Phoenixは、復元が正常に完了したかどうかを確認します。 

  • 復元が正常に完了すると、新しい仮想マシンが使用可能になります。
  • リストアが失敗した場合、Phoenixは新しく作成された仮想マシンを削除します。

Phoenix災害復旧ワークフロー 

Phoenixエディション: ファイル:/cross.pngBusiness         Enterprise     Elite ファイル:/tick.png ファイル:/tick.png

(別途購入)

災害復旧段階

次の表は、障害復旧プロセスのさまざまな段階を示しています。

DRaaSで使用されるさまざまな用語と概念の定義については、「災害復旧の概念」を参照してください  。 

ステージ 説明
戻す

PhoenixDRaaSを使用すると、PhoenixAWSプロキシは次のようになります。

  • Phoenix Cloudから仮想マシンのバックアップデータを読み取ります
  • 仮想マシンをEBSボリュームに複製します
  • AWSアカウントにDRコピーと呼ばれるEBSボリュームのEBSスナップショットを作成します
  • EBSボリュームを削除します
フェイルオーバー

Phoenix AWSプロキシは、DRコピーを初めて作成するときに仮想マシン全体を複製します。その後、DR計画で指定された複製頻度に基づいて、DRコピーを増分更新します。このDRコピーは、AWSアカウントに存在するコピーを置き換えます。Phoenix AWSプロキシは、仮想マシンの最新のDRコピーのみを維持します。フェイルオーバー時に、Phoenix AWSプロキシは次のことを行います。

  • 使用可能なDRコピ​​ーをEBSボリュームに変換します
  • EC2インスタンスの起動に必要なこのEBSボリュームにドライバーを注入します
  • EC2インスタンスを起動し、数分で本番環境にスピンアップします
フェイルバック EC2インスタンスをフェイルバック(フェイルオーバー)し、フェイルオーバー中にAWSアカウントに復旧した後、数時間で仮想化インフラストラクチャをシングルクリックで仮想マシンを復旧できます。

次の図は、Phoenix DRaaSワークフローを示しています。

DR Failback Workflow.png

ワークフローを復元

DR復元ワークフローフローについて簡単に説明し、Druvaアカウントから顧客アカウントにデータをコピーするプロセス中に何が起こっているかを理解しましょう。

DR_overview.jpg

  1. Phoenixクラウドは、PhoenixのAWSプロキシに、PhoenixのS3バケットから仮想マシンのバックアップデータをコピーするように指示します。
  2. 次に、Phoenix AWSプロキシはAPI呼び出しを行って、このコマンドを実行します。 
  3. S3からのデータはPhoenixAWSプロキシを経由してEBSボリュームに到達し、このPhoenixAWSプロキシのデータパスはインターネットゲートウェイです。
    ここでは、もう1つのエンティティであるS3エンドポイントを紹介しますこれにより、あるアカウントから別のアカウントに送信されるデータがAWSネットワークを離れないことが保証されます。
  4. データがEBSボリュームにコピーされると、Phoenix AWSプロキシは別のAPI呼び出しを介して、ボリュームのEBSスナップショットを作成し、ボリューム自体を削除します。

フェイルオーバーのワークフロー

フェイルオーバーとは何かということは、災害が発生してプライマリデータセンターが利用できなくなったときに何が起こるかを尋ねることです。ここで何が起こるかです。

DR_failover.jpg

  1. まず、管理者がPhoenix管理コンソールからフェイルオーバーをトリガーし、PhoenixクラウドがPhoenixAWSプロキシにフェイルオーバーを開始するように指示します。
  2. EBSスナップショットは、EBSボリュームを作成するために使用されます。Phoenix AWSプロキシは、AWSアカウントにEC2インスタンスを作成します。VMをDR用に構成するときに、Phoenix管理コンソールからEC2インスタンスタイプを選択できます。EBSボリュームがEC2インスタンスにアタッチされます。
  3. プロセスが完了すると、EC2インスタンスが再起動され、そのワークロードをサポートする準備が整います。保護されたすべてのVMに対して同じプロセスが繰り返されます。 
  4. 最後の手順は、DNSサーバーを更新して、トラフィックを新しいEC2サーバーのIPアドレスにリダイレクトすることです。

Phoenixは、フェイルオーバーシーケンスを決定できる高度なオーケストレーション機能を提供し、EC2間の依存関係を作成し、EC2ブート中に実行するスクリプトを追加します。依存関係の例としては、データベースにデータを保存するeコマースWebサーバーがあります。データベースが使用可能になる前にWeb EC2を開始しても意味がありません。

Druva DRaaSでは、別のVPCまたはサブネットでのDRテストも可能です。 

フェイルバックのワークフロー

フェールバックの開始点は、新しく再構築されたプライマリデータセンターと、プライマリサイトに転送する必要があるデータを含むバックアップDRサイトです。

DR_failback.jpg

  1. 最初の手順は、PhoenixバックアッププロキシVMを再デプロイして、Phoenix Cloudとの通信を確立し、クラウドからバックアップ構成を取得することです。 
  2. 次の手順では、バックアッププロキシがテンプレートVMを起動します。テンプレートVMはEC2インスタンスに到達し、その構成情報(CPU数、メモリサイズ、ディスク数など)を取得します。 
  3. 受け取ったこの情報に基づいて、1つ以上のVMDKディスクを接続し、EBSボリュームからVMDKディスクへのデータのコピーを開始します。 
  4. ダウンロードが完了すると、テンプレートVMが再起動され、EC2インスタンスから読み取られた構成パラメーターが使用されます。その後、サーバーは操作可能になります。保護されたすべてのVMに対して同じプロセスが繰り返されます。 
  5. 最後の手順は、DNSを更新してトラフィックをプライマリサイトにリダイレクトすることです。

Phoenix AWSプロキシ設定の手順 

Phoenix Editions: File:/cross.pngBusiness         File:/tick.png Enterprise     File:/tick.pngElite

(Purchase Separately)

Phoenix AWSプロキシは、Phoenixサービスを実行するEC2 (Elastic Compute Cloud) インスタンスです。これはPhoenixバックアップストレージからAWSアカウントへデータのコピーを指揮し、DRプランで指定された頻度でAMIコピーを作成ます。Phoenix AWSプロキシは顧客AWSアカウントで動作します。プロキシはVMのバックアップストレージが置かれているのと同じAWSリージョンで起動されます。ディザスタリカバリ用にインスタンス化されたAMIは、同じリージョンに作成されます。

Phoenix AWSプロキシ設定の手順

Phoenix AWSプロキシを設定するには、まずPhoenixポータルから.jsonポリシーをダウンロードする必要があります。このポリシーはAWSポータルでIAMポリシーとVMimportポリシーを作成し、VMimportロール信頼関係を確立するために使用されます。IAMポリシーとロールを作成したら、自社のAWSリージョン向けのAMI IDを取得して、プロキシを起動する必要があります。以下の図は、Phoenix AWSプロキシ設定の手順と、設定を行う各ポータルを示します。

以下の表にPhoenix AWSプロキシを設定する手順をまとめます。

手順 ポータル 説明
Download Policies

Phoenix ポータル

IAMポリシーとVMimportポリシーを作成し、AWSのVMimportロールの信頼関係を確立するために使用されるポリシーをダウンロードします。

Create IAM Policy and Roles AWS ポータル IAMポリシーとロールを作成します。IAMポリシーを使用すると、ユーザー、グループ、ロール、リソースの権限を定義できます。IAMロールはAWSユーザーにアクセス機能を提供します。VMimportポリシーを作成します。これは仮想マシンイメージを仮想環境からAmazon EC2にAMIとしてインポートするために、信頼された権限属性を定義します。VMimportポリシーを使用すると、Amazon EC2にアクセスしてAWSアカウントにAMIを作成できます。
Get AMI ID Phoenix ポータル AWSリージョンのAMI IDを取得します。
Launch Phoenix AWS proxy AWS ポータル VMがバックアップされるAWSリージョンでPhoenix AWSプロキシを起動します。
Register Phoenix AWS proxy AWS ポータル Phoenix AWS プロキシを登録してアクティベートします。

Phoenixディザスタリカバリの手順 

Phoenix DRaaSのAMI (Amazon Machine Image) コピーは、仮想マシンのバックアップにより作成され、AWSアカウントで管理されます。災害時には、これらAMIからEC2インスタンスを起動し、数分で本番環境を立ち上げることができます。AMIコピーは定義されたスケジュールに従って最新の仮想マシンバックアップ情報で更新されます。Phoenix DRaaSの手順を次の図に示します。

CloudCache環境のデータバックアップ手順 

Phoenix Editions: File:/cross.png Business File:/cross.png Enterprise File:/tick.png Elite

次の図は、Phoenix CloudCacheが導入された環境におけるバックアップ時のデータフローを示します。

Data Backup Workflow

手順 説明

手順1

 

Phoenixエージェントはサーバーグループに割り当てられているバックアップポリシーに定義されたスケジュールに従ってサーバーデータをバックアップします。スケジュールされた時間にPhoenixクラウドのPhoenixマスターがバックアップ要求を開始し、Phoenixエージェントに転送します。

注意: Phoenix CloudCacheはPhoenixマスターとの永続的なコネクションを維持します。

手順2

 

  1. PhoenixエージェントはPhoenix CloudCacheにデータをバックアップします。
  2. PhoenixエージェントはPhoenixマスターがバックアップ用に割り当てたストレージにメタデータを保存します。

手順3

 

事前定義されたスケジュールに従って、Phoenix CloudCacheはバックアップデータをPhoenixマスターが割り当てるストレージと同期します。 

注意: Phoenix CloudCacheはクラウドストレージとオンデマンドで接続を確立します。同期が完了すると、Phoenixクラウドストレージとの接続が終了します。次の動作のため、Phoenix CloudCacheはPheonixマスターが割り当てるクラウドストレージとの接続を確立します。

注意: 管理者は同期スケジュールとPheonix CloudCacheが使用できる帯域を設定する必要があります。詳細はConfigure Phoenix CloudCacheを参照してください。

CloudCache環境のデータリストア手順

Phoenix Editions: File:/cross.png Business File:/cross.png Enterprise File:/tick.png Elite

以下の図は、ホットリストア時のPhoenix環境内でのデータフローを示します。

Data Restore Workflow

手順 説明

手順1

PhoenixクラウドのPhoenixマスターがリストア要求を開始し、Phoenixエージェントに転送します。

手順2

 

  1. PhoenixエージェントはPhoenixクラウド内のストレージからメタデータを取得します。
  2. PhoenixエージェントはPhoenix CloudCacheにクエリを実行してデータを復元します。

VMware向けのポートと通信プロトコル

Phoenixは仮想インフラストラクチャと通信し、仮想マシンのデータをバックアップおよびリストアします。この通信では、データの通信と転送が安全に行われるポートと通信プロトコルが利用されます。

Phoenixは、Phoenixコンポーネントと仮想インフラストラクチャのコンポーネント (vCenter Server、ESXiホスト、仮想マシンなど) 間のコネクションを確立して通信を開始するために、TLS (Transport Layer Security) とSSL (Secure Socket Layer) プロトコルの組み合わせを使用します。

次の図は、Phoenixがバックアップおよびリストア操作中に安全な接続と通信のためPhoenixによって使用されるポートと通信プロトコルを示します。

以下の表で、Phoenixと各種VMwareコンポーネント間の通信に使用されるポートと通信プロトコルについて説明します。

ポート / 通信プロトコル 説明

443

Phoenixは以下の間で安全な接続と通信を確立するためにポート443を使用します。

  • バックアッププロキシとPhoenixクラウド間
  • バックアッププロキシとPhoenix CloudCache間
  • バックアッププロキシとvCenterサーバー間
  • バックアッププロキシとESXiホスト間

 

注意: バックアッププロキシはスタンドアロンESXiとしてPhoenixに登録されている場合のみ、ESXiホストとポート443上でコネクションを確立します。ESXiホストがvCenterサーバー経由でPhoenixに登録されている場合、バックアッププロキシはポート902上でESXiホストと通信します。

902

PhoenixはバックアッププロキシとvCenterサーバー経由でPhoenixに登録されたESXiホストとの間でコネクションを確立するためにポート902を使用します。

TLS

Phoenixは以下の間で安全な接続と通信を確立するためにTLSを使用します。

  • バックアッププロキシとPhoenixクラウド間
  • バックアッププロキシとPhoenix CloudCache間
  • Phoenix CloudCacheとPhoenixクラウド間

SSL

Phoenixは以下の間で発生する安全な接続にSSLを使用します。

  • バックアッププロキシとvCenterサーバー間
  • バックアッププロキシとESXiホスト間

ファイルサーバー向けのポートと通信プロトコル

Phoenixはファイルサーバーと通信し、ファイルサーバーのデータをバックアップおよびリストアします。この通信では、データの通信と転送が安全に行われるポートと通信プロトコルが利用されます。

Phoenixは、Phoenixコンポーネントとファイルサーバー間のコネクションを確立して通信を開始するために、TLS (Transport Layer Security) を使用します。

次の図は、Phoenixがバックアップおよびリストア操作中に安全な接続と通信のためPhoenixによって使用されるポートと通信プロトコルを示します。

Phoenix CloudCache向けのポートと通信プロトコル

Phoenix CloudCacheは社内のサーバーおよびPhoenixクラウドと通信し、データをバックアップおよびリストアします。この通信では、データの通信と転送が安全に行われるポートと通信プロトコルが利用されます。

Phoenix CloudCacheはPhoenixコンポーネントとコネクションを確立して通信を開始するために、TLS (Transport Layer Security) を使用します。

次の図は、バックアップおよびリストア操作中に安全な接続と通信のためPhoenix CloudCacheによって使用されるポートと通信プロトコルを示します。

 

 
  • この記事は役に立ちましたか?