文書化
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: 
Business Enterprise Elite
本項ではWindowsおよびLinuxオペレーティングシステムを使用したファイルサーバーからのデータバックアップの手順図と手順について説明します。
注意: バックアップ中にサーバーを再起動やリブートすると、バックアップ操作は中断されます。Phoenixエージェントは、バックアップスケジュールに従って新しいバックアップを開始します。または、いつでも手動バックアップが行えます。
Windowsオペレーティングシステムのファイルサーバー
ここではWindowsオペレーティングシステムのファイルサーバーにおけるデータバックアップのデータフローについて説明します。
バックアップ手順
| 手順 | 操作 |
|---|---|
|
手順1 |
バックアップ要求が開始され、Phoenixエージェントに転送されます。 |
|
手順2
|
PhoenixはPhoenixエージェントが動作していることをチェックします。
|
|
手順3
|
Phoenixはバックアップの種類を決定します。 管理者によりバックアップが開始され、それが最初のバックアップである場合、Phoenixはフルバックアップを実行します。管理者により起動された2回目以降のバックアップの場合、Phoenixは増分バックアップを実行します。 |
|
手順4 |
PhoenixエージェントはVSSサービスが実行中であることを確認します。VSSサービスが実行されていない場合、PhoenixエージェントはVSSサービスを開始し、VSSにスナップショットの作成を指示します。 |
|
手順5 |
Phoenixエージェントはバックアップの実行に必要な時間を見積もります。 |
|
手順6 |
Phoenixエージェントはスナップショットが正常に作成されたことを検証します。 |
|
手順7
|
|
|
手順8 |
バックアップが完了すると、Phoenixエージェントは作成したスナップショットを削除します。 |
Linuxオペレーティングシステムのファイルサーバー
ここではLinuxオペレーティングシステムのファイルサーバーにおけるデータバックアップのデータフローについて説明します。
バックアップ手順
| 手順 | 操作 |
|---|---|
|
手順1 |
バックアップ要求が開始され、Phoenixエージェントに転送されます。 |
|
手順2 |
PhoenixはPhoenixエージェントが動作していることをチェックします。
|
|
手順3 |
Phoenixはバックアップの種類を決定します。 管理者によりバックアップが開始され、それが最初のバックアップである場合、Phoenixはフルバックアップを実行します。管理者により起動された2回目以降のバックアップの場合、Phoenixは増分バックアップを実行します。 |
|
手順4 |
Phoenixエージェントはファイルサーバー上でライブのファイルとフォルダーのフルスキャンを実行します。 |
|
手順5 |
Phoenixエージェントはバックアップの実行に必要な時間を見積もります。 |
|
手順6 |
Phoenixエージェントはスキャンしたフォルダーとファイルをデータ転送用のファイルセットとして使用します。 注意: Phoenixはロックされたファイルを不足ファイルとみなし、次回のスケジュールバックアップ時にそのファイルをバックアップしようとします。 |
ファイルサーバーリストアの手順
同一ファイルサーバーへのリストア
別のファイルサーバーへのリストア
| 手順 | 操作 |
|---|---|
|
手順1 |
管理者がリストア操作を開始します。 元の場所または別の場所にデータを復元できます。別の場所の場合、「同じサーバー上の異なるパス」または「別のサーバー上の異なるパス」にすることができます。 選択したファイルサーバーの復元ポイントに対してリストアを実行する宛先サーバーを選択します。たとえば、Windowsリストア用のWindowsサーバーと、Linuxリストア用のLinuxサーバーがあります。 |
|
手順2 |
PhoenixはPhoenixエージェントが動作していることを確認します。
|
|
手順3 |
Phoenixは復元先を検証します。 |
|
手順4 |
Phoenixは復元先で使用可能な空き容量をチェックします。 |
|
手順5 |
Phoenixはリストアするファイルセットを特定します。 |
|
手順6 |
Phoenixは復元操作を開始し、ファイルセットを復元先に順次ダウンロードします。 |
注意: ファイルサーバーのリストア詳細については同一サーバー上でのリストア、新規サーバー上でのリストアを参照してください。
NAS共有のバックアップ手順
以下にWindowsまたはLinux上でNAS共有をバックアップするときのデータの流れを図示します。
以下に手順をまとめます。
| 手順 | 操作 |
|---|---|
|
手順 1 |
バックアップ要求が開始され、NASプロキシに転送されます。 |
|
手順 2
|
Phoenix はNASプロキシが動作しているか確認します。
|
|
手順 3
|
Phoenix はバックアップ種別を決定します。 これがデータソースからの初回バックアップの場合、Pheonixはフルバックアップを実施します。以降のバックアップは増分バックアップになります。 |
|
手順 4 |
Phoenix エージェントはNAS共有上のファイルおよびフォルダーのフルスキャンをを実行します。 |
|
手順 5 |
NAS プロキシはバックアップ用にスキャンしたファイルやフォルダーをPhoenixクラウドへ送信します。 Note: Phoenix が初回試行でロックされたファイルのバックアップが行えない場合、バックアップ終了時にそのファイルがロック解除されたか確認します。ファイルがロック解除された場合、同じバックアップジョブでそれらファイルをバックアップします。ロックされているファイルはバックアップされません。 |
| 手順 6 | Phoenix クラウドは重複排除を適用し、スナップショットに増分データを保存します。 |
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を参照してください。
ワークフロー
フルバックアップには次の手順が含まれます。
- Phoenixはエージェントが実行されているかどうかを確認します。エージェントが実行されていない場合、Phoenixはバックアップリクエストをキューに入れます。Phoenixエージェントの起動後にこのリクエストが実行されます。
- バックアップ操作が開始される前に、エージェントはVSSサービスおよびSQLライターサービスが実行されているかどうかを確認します。サービスが実行されていない場合、エージェントはこれらのプロセスを自動的に起動します。
- 概算フェーズで、エージェントはボリュームシャドウコピーAPIを使用してMS-SQLサーバーからデータベース情報を取得します。
- その後、エージェントはバックアップする必要がある個別のファイルセットを決定します。VSSはスナップショットを提供します。
- データベースの初回バックアップ時は、スナップショット全体がバックアップされます。データベースの初回バックアップ以外の場合は、ファイルセットの中で更新されたデータがスナップショットからコピーされ、サーバーにアップロードされます。データがサーバーに正常にアップロードされた後、バックアップは成功のステータスになります。
追加情報
- 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日のスナップショットは保持されます。
ワークフロー
差分バックアップには次の手順が含まれます。
- Phoenixはエージェントが実行されているかどうかを確認します。エージェントが実行されていない場合、Phoenixはバックアップリクエストをキューに入れます。Phoenixエージェントの起動後にリクエストが実行されます。
- バックアップ操作が開始される前に、エージェントはVSSサービスおよびSQLライターサービスが実行されているかどうかを確認します。サービスが実行されていない場合、エージェントはこれらのプロセスを自動的に起動します。
- 概算フェーズで、エージェントはボリュームシャドウコピーAPIを使用してSQL Serverからデータベース情報を取得します。
- 差分バックアップの場合、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を短くすることができます。
ワークフロー
次のフローチャートは、トランザクションログのワークフローを示しています。
AGバックアップセット向けトランザクションマークのバックアップ / リストアの制限
ログバックアップがセカンダリノードで実施された場合、Phoenixはトランザクションマークをバックアップしません。
MS-SQLサーバーは、可用性グループ（AG）内のデータベースのセカンダリノードで、トランザクションログに関連するトランザクションマークを複製しません。PhoenixのAGバックアップセットのトランザクションマークをリストアしようとすると、ログバックアップがプライマリノードとセカンダリノードのどちらで行われたかによって、MS-SQLサーバー上に作成されたトランザクションマークが表示される場合と表示されない場合があります。
MS-SQL Serverの復元ワークフロー
データベーススナップショットの復元ワークフロー
次の手順では、インスタンスまたはAGのデータベースのスナップショットリストアをトリガーしたときのリストアジョブについて説明します。
| 手順 | 操作 |
|---|---|
|
1 |
あなたまたは別の管理者が復元を開始します。 |
|
2 |
Phoenixは、Phoenixエージェントが実行されているかどうかを確認します。
|
| ３ | Phoenixは、復元先（元のインスタンスまたは別のMS-SQLサーバー）を検証します。 |
|
4 |
Phoenixは、復元先がドライブではないかどうかを検証します。たとえば、D：\への復元は失敗します。
|
| 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
|
Phoenixは、Phoenixエージェントが実行されているかどうかを確認します。
|
|
３ |
Phoenixは、復元先（元のグループ、代替グループ、または可用性グループ）と復元先の場所を検証します。
|
| 4 | Phoenixは、SQL Serverインスタンスが復元に使用できるかどうかを検証します。復元ジョブが元のデータベースを置き換える場合、Phoenixはデータベースが復元可能かどうかもチェックします。 |
| 6 | Phoenixは、復元に使用できる空き領域を確認し、復元するファイルセットを特定することによって復元ジョブを開始します。Phoenixは、ファイルセットを復元先に順次ダウンロードします。ファイルセット（複数のデータベースに属するデータが含まれている可能性があります）内で、Phoenixは異なるデータベースに属するファイルを同時にダウンロードします。ファイルセットのダウンロードが完了すると、Phoenixは次のファイルセット（1つ以上のデータベースに属するデータも含まれている可能性があります）を復元先にダウンロードします。 |
| 7 | Phoenixは、リストアに次の構文を使用します：<宛先パス> \ <スナップショット> \ <リクエストID> \ <ファイルセット> \ <実際のファイル>。<Request ID>フォルダーは、各復元ジョブを一意に識別します。 |
|
8 |
Phoenixエージェントは、復元場所からトランザクションログを取得します。
元のデータベースが置き換えられると、Phoenixエージェントはデータベースへのすべての接続を終了し、ダウンロードしたトランザクションログを使用してデータベースを復元します。 |
| 9 | データベースが可用性グループに復元される場合、Phoenixエージェントはデータベースを指定された共有ネットワークの場所に復元し、データベースをすべてのセカンダリノードに同期するか、利用可能な場合は自動シードを使用します。 |
復元が完了した後：
- 場合はリカバリモードが 選択され、データベースは、指定されたことをインスタンスのアクティブとして表示されます。
- [ 復旧モードなし] が選択されている場合、データベース は指定したインスタンスの[ 復元中]として表示されます。
- 場合はスタンバイモードには、追加のトランザクションログのリストアできるように 選択され、指定したことをスタンバイ/読み取り専用インスタンスのように、データベースが表示されます。
- [ 可用性グループに復元] が選択されている場合、データベースはAGのすべてのノードで同期されているように見えます。
Oracleデータベースのバックアップワークフロー
OracleのPhoenixバックアップワークフローを以下に示します。
| 手順 | 説明 |
|---|---|
| 手順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データベースの復元ワークフロー
| 手順 | オペレーション |
|---|---|
|
手順1 |
Phoenixの管理者がスナップショットを選択し、復元を開始します。 |
|
手順2 |
Phoenixの管理者は、スナップショットを元のPhoenixバックアップストアまたは代替のPhoenixバックアップストアに復元できます。 |
|
手順3 |
スナップショットが解凍され、Oracle RMANバックアップとしてPhoenixバックアップストア上の場所にダウンロードされます。Phoenix Backup Store上のOracle RMANバックアップのダウンロード場所は、 / mnt / restores / <backupmount_name> / <restore_job_id> / dataです。
|
|
手順4 |
スナップショットの場所はRMANホストにマッピングされているため、RMANはそのスナップショットに格納されているデータを使用して、データベースをOracleインスタンスに復元できます。 |
|
手順5 |
データベース管理者は、Oracle RMANバックアップをOracleインスタンスに復元します。 |
VMware仮想マシンバックアップの手順
Phoenix Editions: Business Enterprise Elite
Phoenixは仮想マシンが含まれるサーバーグループに関連付けられたバックアップポリシーに定義されたスケジュールに基づいて、またはPhoenix管理コンソールから実行されたオンデマンド・バックアップによって、仮想マシンのバックアップを実行します。これにはPhoenixコンポーネントとVMwareコンポーネントの連係動作が含まれます。
以下の図に仮想マシンのバックアップ時のデータフローを示します。
仮想マシンバックアップの手順
| 手順 | 操作 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
手順1 |
仮想マシンのバックアップ要求は以下により開始されます。
Phoenixはバックアップ要求をバックアッププロキシプールに転送します。
|
||||||||||||
|
手順2 |
バックアッププロキシはESXiハイパーバイザーまたはvCenterサーバーに仮想マシンのVMDKファイルとVMXファイルを問い合わせます。 |
||||||||||||
|
手順3 |
Phoenixはバックアップの種類を決定します。
バックアッププロキシは仮想マシンのスナップショットを取得し、バックアップの準備を行います。 |
||||||||||||
|
手順4 |
VDDKコネクションがSSL転送モードで仮想マシンと確立されます。 |
||||||||||||
|
手順5 |
バックアッププロキシは仮想マシンと接続し、仮想マシンデータをバックアップするための読み取り専用コネクションを確立します。 |
||||||||||||
|
手順6 |
バックアッププロキシは仮想マシンのスナップショットを使用してバックアップ用のVMDKファイルを読み取ります。仮想マシンのデータをコピーし、Phoenix CloudCache (設定されている場合) またはPhoenixクラウドに送信する準備をします。 NBDモードによる暗号化されたvmdkバックアップはサポートされていません。暗号化されたvmdkディスクは、NBDSSLまたはHotAddを使用してバックアップできます。仮想マシンのディスクバックアップでサポートされている転送モードは以下の通りです。
|
||||||||||||
|
手順7 |
バックアッププロキシはスナップショットデータを連続ストリームでPhoenixクラウドに転送します。データをPhoenixクラウドに転送する前に、バックアッププロキシは重複排除を実行します。 バックアップが完了すると、バックアッププロキシはスナップショットを削除します。 |
仮想マシンのバックアップに関する詳細は Backup and Restore VMware Virtual Machines.を参照してください。
VMware仮想マシンリストアの手順
| 手順 | 操作 |
|---|---|
|
手順1 |
Phoenix管理者が仮想マシンのリストアを開始します。Phoenixはリストア要求をバックアッププロキシプールへ転送します。
|
|
手順2 |
Phoenixはリストア場所がNAS (Network-attached Storage) でないことを確認します。
|
|
手順3 |
VDDKコネクションがSSL転送モードで仮想マシンと確立されます。 |
|
手順4 |
バックアッププロキシは、フル仮想マシンリストアまたはVMDKファイルリストアかをチェックします。バックアッププロキシは仮想マシンに接続し、仮想マシンデータを復元するための書き込み接続を確立します。
<元の仮想マシン名>_<カウンタ>
<元の仮想マシン名>_<カウンタ> 注意: ディスクリストアでは、仮想マシンを作成せずにディスクを作成することはできないため、最小構成の仮想マシンを作成します。 |
|
手順5 |
バックアッププロキシはPhoenixクラウドから仮想マシンデータを取得します。 |
|
手順6 |
リストア操作が開始されます。 Phoenixはリストアが正常に完了したかチェックします。
|
Hyper-V仮想マシンのバックアップワークフロー
Phoenixエディション： Business Enterprise Elite
Phoenixは、バックアップポリシーで定義されたスケジュールに基づいて、またはPhoenix管理コンソールからバックアップがトリガーされた場合に、仮想マシンをバックアップします。バックアップのワークフローを以下に説明します。
仮想マシンのバックアップワークフロー
| 手順 | 操作 |
|---|---|
|
手順1 |
仮想マシンのバックアップ要求は、以下に基づいて開始されます。
Phoenixは、バックアップ要求をエージェントに転送します。 |
|
手順2 |
Phoenixエージェントは、VSS サービスが実行されていることを確認し ます。Phoenixエージェントは、VSSサービスにスナップショットの作成を要求します。VSSサービスが実行されていない場合、PhoenixエージェントはVSSサービスを開始し、VSSにスナップショットを作成するように指示します。 Druvaでは、Hyper-V統合サービスでバックアップ（ボリュームスナップショット）を有効にすることをお勧めします。バックアップ（ボリュームスナップショット）が有効な場合、VSSサービスは仮想マシン上のサービスを中断することなくスナップショットを作成できます。 Phoenixエージェントは、スナップショットが正常に作成されたかどうかを検証し、バックアップジョブを開始します。
注： Integration Servicesは、WindowsゲストOSを備えた仮想マシンで使用できます。ただし、Microsoftは特定のLinuxディストリビューションにも統合サービスを提供しています。詳細については、以下を参照してください。 Windows Server 2016以降では、Phoenixエージェントは、以下の場合に、Resilient Change Tracking（RCT）機能を使用して仮想マシンをバックアップできます。
Phoenixエージェントは、上記の条件を満たすHyper-VホストでRCTを使用して仮想マシンをバックアップできます。
|
|
手順3 |
Phoenixがバックアップのタイプを決定します。
|
|
手順4 |
エージェントはバックアップ用のデータを推定します |
|
手順5 |
エージェントは、VSS提供のスナップショットに基づいてデータをバックアップします |
次の手順
バックアップと復元のためにPhoenixを構成する場合は、以下を参照してください。
詳細については、以下を参照してください。
Hyper-V仮想マシンの復元ワークフロー
| 手順 | オペレーション |
|---|---|
|
手順1 |
Phoenix管理者が仮想マシンの復元を開始します。Phoenixは、復元要求をHyper-Vサーバーエージェントに転送します。 |
|
手順2 |
Phoenixは、Phoenixエージェントが実行されているかどうかを確認します。エージェントが実行中の場合、Phoenixは仮想マシンを復元します。エージェントが実行されていない場合、エージェントがバックアップと復元の準備ができるまで、復元ジョブはキューに入れられます。 |
|
手順3 |
Phoenixエージェントは、宛先のHyper-Vサーバーに仮想マシンを復元するのに十分なストレージがあるかどうかを確認します。 |
|
手順4 |
Phoenixエージェントは、仮想マシンの完全な復元か仮想ディスクの復元かを確認します。エージェントはサーバーに接続し、書き込み接続を確立して仮想マシンデータを復元します。
|
|
手順5 |
Phoenix CloudはスナップショットをHyper-Vサーバーエージェントに送信します。 |
|
手順6 |
復元操作が開始されます。 Phoenixは、復元が正常に完了したかどうかを確認します。
|
Phoenix災害復旧ワークフロー
Phoenixエディション： 
Business Enterprise Elite 
（別途購入）
災害復旧段階
次の表は、障害復旧プロセスのさまざまな段階を示しています。
DRaaSで使用されるさまざまな用語と概念の定義については、「災害復旧の概念」を参照してください 。
| ステージ | 説明 |
|---|---|
| 戻す |
PhoenixDRaaSを使用すると、PhoenixAWSプロキシは次のようになります。
|
| フェイルオーバー |
Phoenix AWSプロキシは、DRコピーを初めて作成するときに仮想マシン全体を複製します。その後、DR計画で指定された複製頻度に基づいて、DRコピーを増分更新します。このDRコピーは、AWSアカウントに存在するコピーを置き換えます。Phoenix AWSプロキシは、仮想マシンの最新のDRコピーのみを維持します。フェイルオーバー時に、Phoenix AWSプロキシは次のことを行います。
|
| フェイルバック | EC2インスタンスをフェイルバック（フェイルオーバー）し、フェイルオーバー中にAWSアカウントに復旧した後、数時間で仮想化インフラストラクチャをシングルクリックで仮想マシンを復旧できます。 |
次の図は、Phoenix DRaaSワークフローを示しています。
ワークフローを復元
DR復元ワークフローフローについて簡単に説明し、Druvaアカウントから顧客アカウントにデータをコピーするプロセス中に何が起こっているかを理解しましょう。
- Phoenixクラウドは、PhoenixのAWSプロキシに、PhoenixのS3バケットから仮想マシンのバックアップデータをコピーするように指示します。
- 次に、Phoenix AWSプロキシはAPI呼び出しを行って、このコマンドを実行します。
- S3からのデータはPhoenixAWSプロキシを経由してEBSボリュームに到達し、このPhoenixAWSプロキシのデータパスはインターネットゲートウェイです。
ここでは、もう1つのエンティティであるS3エンドポイントを紹介します。これにより、あるアカウントから別のアカウントに送信されるデータがAWSネットワークを離れないことが保証されます。 - データがEBSボリュームにコピーされると、Phoenix AWSプロキシは別のAPI呼び出しを介して、ボリュームのEBSスナップショットを作成し、ボリューム自体を削除します。
フェイルオーバーのワークフロー
フェイルオーバーとは何かということは、災害が発生してプライマリデータセンターが利用できなくなったときに何が起こるかを尋ねることです。ここで何が起こるかです。
- まず、管理者がPhoenix管理コンソールからフェイルオーバーをトリガーし、PhoenixクラウドがPhoenixAWSプロキシにフェイルオーバーを開始するように指示します。
- EBSスナップショットは、EBSボリュームを作成するために使用されます。Phoenix AWSプロキシは、AWSアカウントにEC2インスタンスを作成します。VMをDR用に構成するときに、Phoenix管理コンソールからEC2インスタンスタイプを選択できます。EBSボリュームがEC2インスタンスにアタッチされます。
- プロセスが完了すると、EC2インスタンスが再起動され、そのワークロードをサポートする準備が整います。保護されたすべてのVMに対して同じプロセスが繰り返されます。
- 最後の手順は、DNSサーバーを更新して、トラフィックを新しいEC2サーバーのIPアドレスにリダイレクトすることです。
Phoenixは、フェイルオーバーシーケンスを決定できる高度なオーケストレーション機能を提供し、EC2間の依存関係を作成し、EC2ブート中に実行するスクリプトを追加します。依存関係の例としては、データベースにデータを保存するeコマースWebサーバーがあります。データベースが使用可能になる前にWeb EC2を開始しても意味がありません。
Druva DRaaSでは、別のVPCまたはサブネットでのDRテストも可能です。
フェイルバックのワークフロー
フェールバックの開始点は、新しく再構築されたプライマリデータセンターと、プライマリサイトに転送する必要があるデータを含むバックアップDRサイトです。
- 最初の手順は、PhoenixバックアッププロキシVMを再デプロイして、Phoenix Cloudとの通信を確立し、クラウドからバックアップ構成を取得することです。
- 次の手順では、バックアッププロキシがテンプレートVMを起動します。テンプレートVMはEC2インスタンスに到達し、その構成情報（CPU数、メモリサイズ、ディスク数など）を取得します。
- 受け取ったこの情報に基づいて、1つ以上のVMDKディスクを接続し、EBSボリュームからVMDKディスクへのデータのコピーを開始します。
- ダウンロードが完了すると、テンプレートVMが再起動され、EC2インスタンスから読み取られた構成パラメーターが使用されます。その後、サーバーは操作可能になります。保護されたすべてのVMに対して同じプロセスが繰り返されます。
- 最後の手順は、DNSを更新してトラフィックをプライマリサイトにリダイレクトすることです。
関連記事
Phoenix AWSプロキシ設定の手順
Phoenix Editions:Business Enterprise Elite
(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: Business Enterprise Elite
次の図は、Phoenix CloudCacheが導入された環境におけるバックアップ時のデータフローを示します。
| 手順 | 説明 |
|---|---|
|
手順1
|
Phoenixエージェントはサーバーグループに割り当てられているバックアップポリシーに定義されたスケジュールに従ってサーバーデータをバックアップします。スケジュールされた時間にPhoenixクラウドのPhoenixマスターがバックアップ要求を開始し、Phoenixエージェントに転送します。
|
|
手順2
|
|
|
手順3
|
事前定義されたスケジュールに従って、Phoenix CloudCacheはバックアップデータをPhoenixマスターが割り当てるストレージと同期します。
|
注意: 管理者は同期スケジュールとPheonix CloudCacheが使用できる帯域を設定する必要があります。詳細はConfigure Phoenix CloudCacheを参照してください。
CloudCache環境のデータリストア手順
Phoenix Editions: Business Enterprise Elite
以下の図は、ホットリストア時のPhoenix環境内でのデータフローを示します。
| 手順 | 説明 |
|---|---|
|
手順1 |
PhoenixクラウドのPhoenixマスターがリストア要求を開始し、Phoenixエージェントに転送します。 |
|
手順2
|
|
VMware向けのポートと通信プロトコル
Phoenixは仮想インフラストラクチャと通信し、仮想マシンのデータをバックアップおよびリストアします。この通信では、データの通信と転送が安全に行われるポートと通信プロトコルが利用されます。
Phoenixは、Phoenixコンポーネントと仮想インフラストラクチャのコンポーネント (vCenter Server、ESXiホスト、仮想マシンなど) 間のコネクションを確立して通信を開始するために、TLS (Transport Layer Security) とSSL (Secure Socket Layer) プロトコルの組み合わせを使用します。
次の図は、Phoenixがバックアップおよびリストア操作中に安全な接続と通信のためPhoenixによって使用されるポートと通信プロトコルを示します。
以下の表で、Phoenixと各種VMwareコンポーネント間の通信に使用されるポートと通信プロトコルについて説明します。
| ポート / 通信プロトコル | 説明 |
|---|---|
|
443 |
Phoenixは以下の間で安全な接続と通信を確立するためにポート443を使用します。
注意: バックアッププロキシはスタンドアロンESXiとしてPhoenixに登録されている場合のみ、ESXiホストとポート443上でコネクションを確立します。ESXiホストがvCenterサーバー経由でPhoenixに登録されている場合、バックアッププロキシはポート902上でESXiホストと通信します。 |
|
902 |
PhoenixはバックアッププロキシとvCenterサーバー経由でPhoenixに登録されたESXiホストとの間でコネクションを確立するためにポート902を使用します。 |
|
TLS |
Phoenixは以下の間で安全な接続と通信を確立するためにTLSを使用します。
|
|
SSL |
Phoenixは以下の間で発生する安全な接続にSSLを使用します。
|
ファイルサーバー向けのポートと通信プロトコル
Phoenixはファイルサーバーと通信し、ファイルサーバーのデータをバックアップおよびリストアします。この通信では、データの通信と転送が安全に行われるポートと通信プロトコルが利用されます。
Phoenixは、Phoenixコンポーネントとファイルサーバー間のコネクションを確立して通信を開始するために、TLS (Transport Layer Security) を使用します。
次の図は、Phoenixがバックアップおよびリストア操作中に安全な接続と通信のためPhoenixによって使用されるポートと通信プロトコルを示します。
Phoenix CloudCache向けのポートと通信プロトコル
Phoenix CloudCacheは社内のサーバーおよびPhoenixクラウドと通信し、データをバックアップおよびリストアします。この通信では、データの通信と転送が安全に行われるポートと通信プロトコルが利用されます。
Phoenix CloudCacheはPhoenixコンポーネントとコネクションを確立して通信を開始するために、TLS (Transport Layer Security) を使用します。
次の図は、バックアップおよびリストア操作中に安全な接続と通信のためPhoenix CloudCacheによって使用されるポートと通信プロトコルを示します。