[DPM] ベアメタル リカバリー (BMR) バックアップの仕組みとベストプラクティスについて


こんにちは、System Center サポート部の石井です。

DPM 2010 や DPM 2012 では、Windows Server 2008 以降の Windows Server OS に対して、ベアメタル リカバリー (以下 BMR) バックアップが行えます。
通常のファイル バックアップとは実装が異なるため、今回は BMR について、実装の違いの説明も踏まえてベストプラクティスをご紹介します。

少し長文ですが、BMR というのはバックアップ対象サーバーに何があっても復旧出来る、という心強い機能です。
一度ディスク障害やオペミスでデータ消失が起きてしまうと取り返しがつかず、我々サポート部門としても全力を尽くしてもどうにもならないケースがあります。
BMR に理解し、慣れておけば、障害発生時に慌てる必要がありませんので、これを機に是非ご一読をお願いします。

 

- BMR とは

まずは、BMR について簡単にご説明します。

BMR バックアップは、Windows Server 標準のバックアップ ツールである Windows Server バックアップと連携を行うことで、バックアップ対象のシステム領域全体のバックアップを行うという機能となります。

BMR は、OS が配置されているボリュームの丸ごとのバックアップです。
VSS を使用していますので、該当のボリュームに SQL や Exchange、あるいは Active Directory のデータベース等が存在していても整合性が取れたバックアップが保証されます。

また、これをリストアした時、リストアされた OS からの見え方としては、「バックアップの瞬間にシステムの電源をぶちっと切った状態から、再起動してきた。ただし、データは整合性がとれた状態である。」といった形です。OS 起動障害時、あるいは構成変更に失敗した場合、BMR バックアップからシステム復旧することで、BMR 取得タイミングのシステムの状態に戻す事が出来ます。

 

- BMR の仕組み

DPM からバックアップを行うにあたって、保護対象の OS で Windows Server バックアップを起動させます。この際、バックアップ対象とするのは、システム ボリュームだけです。
Windows Server バックアップのコマンドで言うと、”wbadmin start backup -AllCritical” というコマンドに相当しており、-AllCritical というオプションが、OS の起動に重要なボリュームのみ、すべてバックアップをするという指定です。
また、Windows Server バックアップには、共有フォルダに出力するという機能があります。DPM は、この共有フォルダの指定を DPM サーバー自身のレプリカ ボリュームに指定しており、DPM サーバーのレプリカが BMR 実行のたびに書き換えられる、という動作になります。

※ 注意点ですが、BMR は同じハードウェア構成のマシンへのリストアのみをサポートしています。これは、上記の通り、システム領域の一括バックアップであり、該当マシンのデバイス ドライバなどの構成も含めてすべてバックアップするからです。リストア先のハードウェア構成が変わっていては、リストアには成功しても起動時に動作しないデバイス ドライバを読み込んでしまい、うまく動かないケースがほとんどです。このことから、BMR をハードウェア変更を伴うマシン リプレースに使う、ということは出来ませんのでご注意下さい。最後に、DPM をご利用いただくにあたって、BMR についてよくいただくご質問について、ご説明します。

  

 

- BMR と普通のファイル バックアップの違いについて

DPM では BMR 以外のデータは、そのままのファイル形式、たとえばファイルであればファイル拡張子のまま、SQL であれば .mdb と .ldf といったそのままのデータで保持します。
ただし、BMR は、Windows Server バックアップの機能を用いますので、Windows Server バックアップ独自のデータ保存形式において .vhd 形式のファイルに取得対象の OS データが格納されています。
DPM では、この .vhd ファイルを格納します。

注意点としては、「DPM の機能として .vhd ファイルから中身を取り出して、アイテム単位でリストア」、「.vhd を仮想マシンに使用」、「あるいは VHD からの OS ブート」といった使用方法は出来ません。
あくまで、BMR の結果保存された .vhd ファイルは、リストア先サーバーで Windows Server バックアップによるリストアを実行する際に、ソース ファイルとして使用するものとなります。

つまり復旧の際にはいったん .vhd をファイル サーバーにリストアし、そのファイルを Windows Server バックアップをリストア先マシンにて実行する必要があります。
OS 起動不可能といった障害時には、Windows Server のインストール DVD から起動して “Complete PC 復元” オプションからこの VHD ファイルを読み込んで復旧をかけます。
DPM サーバーから行えるのは、.vhd ファイルをファイル サーバーに格納するところまでであり、そこから先はリストア対象のマシンから回復を行う必要がある、ということです。

Windows Server バックアップのリストア方法について、よくまとまっている技術情報は以下ですので、障害がおきた時のために事前に検証いただくことをお勧めします。

   参考情報: Windows Server のバックアップ まとめ
   http://blogs.technet.com/b/infrajp/archive/2011/03/18/windows-server.aspx
   -> “Windows Server バックアップによるバックアップと復元” と “System Center Data Protection Manager 2010 (DPM) を利用したバックアップと復元” の項をご参考下さい。

 

 
 

- BMR におけるベスト プラクティス

BMR においては、システム起動に必要なボリュームだけがバックアップ対象になります。
例えば、OS のインストール先である C: と、アプリケーション データ保持領域である D: ドライブがあった場合、多くの場合 C: のみがバックアップ対象となります。
BMR に加えて、アプリケーション データのある D: は DPM から別途バックアップいただき、システム起動障害の際には C: を BMR からリストアし、続いてアプリケーション データの D: を DPM からリストアするという形で復旧するのが効率的です。

後述の Q&A 2 にて説明しますが、構成によっては、アプリケーション データのみがあるはずの D: もシステム領域とみなされる可能性があります。
BMR は Windows Server バックアップの動きに依存しており、若干効率が悪いものとなりますため、DPM からのバックアップに比べると必要な容量が大きく、時間もかかるものとなります。
BMR にて、アプリケーション データが格納されるボリュームも含まれてしまうというのは、本来期待されない構成ですので事前にご確認をいただくことを推奨します。

 

以上が BMR のご説明です。以下 Q&A もご一読をお勧めします。

 

- Q&A 集

 

------------------------------------------------------------------------------------------------
Q&A 1: BMR にあたって、保護対象のサーバーに一時領域は必要なのか?
------------------------------------------------------------------------------------------------

前述のとおり、Windows Server バックアップには、共有フォルダに出力するオプションがあり、DPM は、この共有フォルダの指定を DPM サーバー自身のレプリカ ボリュームに指定しています。このため、保護対象のサーバーにバックアップ ファイルが作られることはありません。

ただし、以下に説明します通り、一時領域が全く不要というわけではありません。
バックアップ中は VSS のスナップショットの保持のため、バックアップ開始から完了までに生じたファイル変更については、別途保護対象サーバーでキャッシュする必要があります。(この仕組みは大変複雑なので、本技術情報では割愛します。)
例えば、BMR バックアップに 1 時間を要し、その間に保護対象のボリュームにて、変更が 10 GB 生じた場合、10 GB の空き容量が保護対象サーバーのボリュームにて必要になります。
また、ものすごく変更量の多い時間帯を避けてバックアップをスケジュールする、といった点も工夫の余地となります。

※ この領域は、バックアップが終われば開放されますし、また次回バックアップでは再利用可能な領域なので、追加で積み重なっていくものではありません。
加えて、バックアップ対象とならないボリュームの変更処理は影響しません。C: のみのバックアップとなる場合、D: にいくら変更を加えても一時領域の消費はありません。

このように VSS のスナップショット保持動作の安定化のため、空き容量は十分に (一般的には最低でも各ボリュームあたり 10 ~ 15  % 程度)  空けておき、バッチによる定期ファイル コピーの処理時間帯など、変更処理の多発する時間帯は避けることが重要です。

------------------------------------------------------------------------------------------------
Q&A 2: BMR バックアップを行うと、レプリカや回復ポイント ボリュームが非常に多く消費されてしまう
------------------------------------------------------------------------------------------------

非常に多数寄せられるご質問ですが、これまでの説明を踏まえてご理解いただく必要があります。

- 回復ポイント ボリュームだけが多く消費されてしまう場合について

Windows Server バックアップの機能にて、バックアップ結果を共有フォルダに出力する際には、以前のバージョンのファイルを一度完全削除してから、新規にバックアップを作成する動きとなります。
DPM では、削除されるはずの以前のバージョンは、回復ポイントとして格納するため、過去のバックアップは保持出来ます。
しかしながら、このように、「一度ファイルを完全削除して、作り直す」動きであるため、毎回、完全にバックアップを作り直すような動作となります。つまり BMR においては、変更差分のみ効率的にバックアップする、という DPM の利点は残念ながら生かせません。

このことから、回復ポイントの世代保持のために必要な回復ポイント ボリュームの容量も、「前回から変更された容量」ではなく、ワーストケースとしては回復ポイント ボリュームの容量として、レプリカの容量×世代分相当の容量が必要となります。
(実際としては、ワーストケースほどの消費とはならず、それよりは節約されることが多いのですが、設計上は、ワーストケースに備えて十分な容量を確保していただくことをお勧めします。)

また、BMR 自体は、システムの起動に必要な領域だけのバックアップになります。このため、一般的には OS 構築後、設定変更がある度に回復ポイントを作成いただく程度の頻度でも問題ありません。
ただし、DPM のディスク ベースのバックアップ スケジュールの制約上、かならず最長でも週 1 度はバックアップが必要です。それ以上、バックアップ採取期間を伸ばす場合、一度保護を停止し、次回バックアップの際に再度保護グループを作成するという繰り返しが必要です。このような運用の場合、ご注意いただきたいのは、ドメインのコンピュータ パスワードの失効に備え、最長でも 1 ヶ月に 1 度はバックアップをいただくという点です。
コンピュータ パスワードの失効したマシン イメージの保存をしていても場合によっては意味がありませんので、週一度の回復ポイント作成とし、4 世代残す、といった最小限の保護グループ設定にして回復ポイント消費を抑えるという工夫もご検討下さい。

- レプリカ ボリュームが多く消費されてしまう場合について

通常のバックアップでは DPM は変更があったブロックのみレプリカを上書きしますが、BMR の場合には OS のWindows Server バックアップの動作として .vhd ファイルごと全て上書きするという動作となります。
C: ドライブ (システム領域) が 100 GB 程度、D: ドライブ (アプリケーション領域) が 1 TB といった環境において、期待されるレプリカ領域は 150 GB 程度ですが、何故か 1 TB 以上必要となってしまう状況があります。

前述の通り、BMR の対象となるボリュームはクリティカル ボリューム (重要なボリューム) と呼ばれます。
このクリティカル ボリュームですが、例えば、SQL や Exchange などの重要なアプリケーションが D: ドライブにインストールされている場合などには、D:\ ドライブもシステム起動に必須の領域と判断されてしまい、クリティカル ボリュームに含まれてしまうことがあります。
この場合には、システム ドライブである C: ドライブに加えて、D: ドライブも丸ごとバックアップがとられてしまうという動作となります。

クリティカル ボリュームにどのボリュームを含めるかについては、VSS のコンポーネントの一つとなります “System Writer” という VSS Writer が判断することとなりますが、手動で変更することはできません。

このことから、サーバー構成の設計時に予め、クリティカル ボリュームと含まれるコンポーネントはデータ ドライブに配置しないように考慮していただく必要があります。
なお、クリティカル ボリュームにどのボリュームが含まれるかにつきましては、下記のDiskShadow コマンドで確認することが可能です。

----------------------------------------------------------------------
DiskShadow コマンドの実行
----------------------------------------------------------------------
1. 保護対象サーバーにおいてコマンド プロンプトを管理者権限にて立ち上げます。
2. 以下のコマンドを実行します。
> DiskShadow

3. その後、"List Writers" コマンドを実行します。
DISKSHADOW > List Writers

"System Writer" の項目にて、"このコンポーネントにより影響を受けるパス" 以下に表示されるパスがクリティカル ボリュームに含まれると判断されているファイルのパスとなります。下記の例は、D:\Program Files 配下にExchange をインストールしたケースとなりますが、この場合には D ドライブ全体もバックアップされることとなります。

--- "List Writers" コマンド実行結果の抜粋 ---
* WRITER "System Writer"
              - ライター ID   = {e8132975-6f93-4464-a53e-1050253ae220}
                - ライター インスタンス ID = { <ライター インスタンス ID> }
                - 復元イベントをサポートします = FALSE
                - ライター復元条件 = VSS_WRE_NEVER
                - 復元方法 = VSS_RME_RESTORE_AT_REBOOT_IF_CANNOT_REPLACE
                - 復元後に再起動が必要 = TRUE
                - 除外されたファイル:
                + コンポーネント "System Writer:\System Files"
                        - 名前: System Files
                        - 論理パス:
                        - 完全なパス: \System Files
                        - キャプション: System Files
                        - 種類: VSS_CT_FILEGROUP [2]
                        - 選択可能: FALSE
                        - トップ レベル: TRUE
                        - バックアップの完了時に通知する: FALSE
                        - このコンポーネントにより影響を受けるパス:
                            …
                            - d:\program files\microsoft\exchange server\v14\bin
                            …
                        - このコンポーネントにより影響を受けるボリューム:
                            - \\?\Volume{ <C:\ ドライブのGUID> }\ [C:\]
                            - \\?\Volume{ <D:\ ドライブのGUID> }\ [D:\]
                        - コンポーネントの依存性:
--- 終り ---

このような場合、D: も BMR の対象に含まれてしまい、BMR の容量がとてつもなく多く消費されてしまう上、データ転送容量、I/O 負荷、所要時間の観点からも問題となります。
(BMR では、Exchange や SQL のデータの整合性は保証されるので、運用上「それでも良し」と判断出来るのであれば良いのですが。)

残念ながら、一度 Exchange や SQL をインストールした後に上記設定を変更する方法は無く、一度アンインストールして C: に再インストールするしかありません。
Exchange や SQL の実行形式はシステム領域  (例ではC:) に、データベース・ログ ファイルはアプリケーション領域 (例では D:) に、という構成となるよう、あらかじめ設計し、運用に入る前に上記 diskshadow コマンドでのチェックをお願いします。

 

--------------------------------------------------------------------
Q&A 3: System State バックアップに意味はあるのか
--------------------------------------------------------------------

BMR のサブセットとして、System State (システム状態) のバックアップという選択があります。
BMR に含まれるので、DPM では BMR をチェックして保護対象に加えると、System State も自動的に追加されます。

これは、主にレジストリ変更を行ったせいでシステムが不安定となった場合や、Active Directory データベースのみバックアップしたい場合、といった限定的な目的に備えてバックアップするものです。
System State だけのバックアップを行った場合、システムの障害時の OS 復旧には使えませんのでご注意下さい。

理由として、System State はバックアップ取得元の OS の一意な ID に紐付いてリストアが可能なものとなります。
システム障害時、OS 再インストールを行ってしまうと、OS の一意な ID は変化してしまい、そのシステムに以前の System State はリストア出来ないのです。

従って、System State はシステム障害に備えるものではありません。先ほどの AD データベースやレジストリ、といった明確な目的が無い限りは BMR を選択して下さい。

 

 

参考情報:

『マイクロソフトサポート部門が明かす「System Center よくあるトラブル集」- Data Protection Manager(DPM)編』
http://download.microsoft.com/download/3/0/B/30B96417-2808-4508-9239-CDC5267D0078/20120519.26_4-3_DPM.pdf (PDF 形式)
http://download.microsoft.com/download/3/0/B/30B96417-2808-4508-9239-CDC5267D0078/20120519.26_4-3_DPM.xps (XPS 形式)
 -> “3. BMR とは” にて、BMR の Tips をご紹介しています。本ポストに含まれないものもありますので、是非ともご一読下さい。また、資料前半では DPM の理解において重要な VSS の技術説明をしています。

上記資料は Technet Fileders セミナー: [Tech Fielders の集い 2012 初夏 大阪] System Center だらけの 6 時間! にてご紹介したものとなります。
http://www.microsoft.com/ja-jp/techfielders/seminar.aspx

 

Comments (0)

Skip to main content