本記事では、EC2にActive Directoryをインストールした環境での、バックアップ・リストア手法の一例について記載します。想定シナリオとしては、FSMOを含め、ドメインコントローラーの役割を持つEC2の全てに障害が発生しているという状況です。つまり、EC2を新規作成し、ドメインコントローラーに昇格するという手段は使えないという状況を想定しています。
Active Directory on EC2 バックアップ・リストアの流れ
全台障害時のActive Directoryのバックアップ・リストアについて、大まかな流れを記載します。なお、Windows Server バックアップを利用しているのは、VSSに対応しており、かつ、サードパーティ製のソフトウェアが不要であるためです。
- Windows Server バックアップでバックアップを取得する
- EC2のAMIイメージを取得する
- AMIイメージからEC2をリストアする
- Windows Server バックアップからリストアする
上記のバックアップ・リストア工程を経ると、最終的にWindows Server バックアップを利用してバックアップを取得した段階にActive Directoryの内部状態が戻ります。最新の状態というわけではありませんが、全てのドメインコントローラーが壊れてしまっている壊滅的な状態からの復旧なので、そこは妥協点となります。
なお、ドメインコントローラーを冗長化している状態に戻すためには、追加で次のような作業も必要になりますが、取り急ぎ、上記の時点でActive Directoryは最低限度のレベルで復旧となります。
- 他ドメインコントローラーの強制降格を行う
- 他ドメインコントローラーのメタデータを削除する
- 他ドメインコントローラーの再昇格を行う
それでは、具体的な流れに入ります。
Windows Server バックアップでバックアップを取得する
本項目では次のような内容を記載します。
- Windows Server バックアップ専用のEBSを用意する
- Windows Server バックアップの機能を追加する
- Windows Server バックアップの設定を行う
Windows Server バックアップ専用のEBSを用意する
Windows Server バックアップを利用したバックアップ先は専用ディスクを利用することが推奨されています。今回も専用EBSを用意し、そちらにバックアップを行うように設定します。
まず、EBSのボリュームコンソールからボリュームの作成をクリックします。
特に次の2点に注意しつつ値を埋めてボリュームの作成をクリックします。
- ボリュームのサイズは保存世代数等の要件に応じて事前に検証して見積もります
- AZはEC2が存在するものと同じものを指定します
今回は次のような値を設定しました。
| 項目 | 値 |
|---|---|
| ボリュームタイプ | 汎用 SSD (gp2) |
| サイズ(GiB) | 20 |
| アベイラビリティーゾーン | ap-northeast-1a |
| スナップショット ID | なし |
| 暗号化 | 有効 |
作成したEBSを右クリックしボリュームのアタッチをクリックします。
インスタンスにはActive DirectoryがインストールされたEC2を指定します。ここでは、FSMOの役割を保有しているドメインコントローラーを指定することをお勧め致します。リストア後、他ドメインコントローラーを追加する際に、FSMOの強制以降を行う手順が減るためです。
また、デバイスは環境に合わせて指定する必要がありますが、今回は他にEBSをアタッチしていないため、xvdfを指定しました。アタッチをクリックすると該当のインスタンスにEBSをアタッチできます。
Windows Server バックアップの機能を追加する
続いて、上述の手順でEBSをアタッチしたEC2上にWindows Server バックアップの機能を追加します。まずは、サーバマネージャーから管理 > 役割と機能の追加をクリックします。
開始する前にが表示された場合は次へをクリックします。
インストールの種類の選択では役割ベースまたは機能ベースのインストールを選択し次へをクリックします。
対象サーバーの選択では自分自身を選択し次へをクリックします。
サーバーの役割の選択では特に何も追加で選択せずに次へをクリックします。
機能の選択でWindows Server バックアップをにチェックを入れ次へをクリックします。
インストールをクリックします。
インストールが完了するまで待ちます。これで機能を追加することができました。
Windows Server バックアップの設定を行う
ここではスケジュールからWindows Server バックアップを行うように設定します。まずはサーバーマネージャーからツール > Windows Server バックアップでwbadminを起動します。
左ペインのローカル バックアップを選択し、右ペインの操作にあるバックアップ スケジュールをクリックします。
はじめにでは次へをクリックします。
バックアップの構成の選択ではカスタムを選択し次へをクリックします。
バックアップする項目を選択では、まず項目の追加をクリックします。
項目の選択ウィンドウが出てくるのでシステム状態を選択しOKをクリックします。
システム状態が追加されていることを確認し次へをクリックします。
バックアップの時間の設定では実際のバックアップ時刻を選択します。今回は日次で20時30分としています。設定したら次へをクリックします。
作成先の種類の選択では、今回は専用EBSを用意しているので、バックアップ専用のハードディスクにバックアップするを選択し次へをクリックします。
作成先ディスクの選択では、まずすべての使用可能なディスクを表示をクリックします。
すべての使用可能なディスクを表示ウィンドウが出てくるので、追加したEBS専用のディスクを選択し、OKをクリックします。
EBS専用のディスクにチェックを入れ、次へをクリックします。
該当のディスクがフォーマットされる旨の警告が出てくるので、はいをクリックします。
内容を確認し完了をクリックします。
スケジュールが作成されるまで待ちます。
これでスケジュールの設定ができました。スケジュール時刻まで待ちましょう。
EC2のAMIイメージを取得する
ここからは、先程の工程で設定したスケジュールでバックアップが正常に取れていることを前提としています。
実際の運用では、手動ではなく自動で作成するパターンがほとんどだと思います。ただし、今回はAMIを手動で取得します。インスタンスを右クリックしイメージ > イメージの作成をクリックします。
今回は再起動しないにチェックを入れてイメージの作成をクリックしAMIイメージを取得します。EBSには、Windows Server バックアップ専用のものが含まれていることを確認します。
Windows Server バックアップからリストアする
本項目では次のような内容を記載します。
- AMIイメージからEC2をリストアする
- EC2がディレクトリサービス復元モードで起動するように設定する
- Windows Server バックアップからリストアする
AMIイメージからEC2をリストアする
AMIイメージからリストアする際の前提としては、次のようなものを想定しています。
- リストア対象となるドメインコントローラーのEC2は削除済みである
- リストア後はリストア前と同じIPアドレスを利用する
- リストア対象を含み全てのドメインコントローラーは削除または停止されておりリストア中に通信は発生し得ない
元々、全てのドメインコントローラーに障害が発生した状況を想定してはいますが、作業中に何らかの意図しない通信が発生し、Active Directoryが完全に破損してしまうようなことがあってはいけないので、全てのドメインコントローラーが削除または停止された状態を想定しています。今回も、該当のEC2は削除してからリストア作業を実施しています。
当該のAMIイメージを右クリックし起動からEC2をリストアします。この際、IPアドレスは元々のものを利用するように設定することを忘れないようにします。
起動できました。 元々のEC2は既に削除済みであるため、同じサブネットにも作成できます。
EC2がディレクトリサービス復元モードで起動するように設定する
ディレクトリサービス復元モード(DSRM)とは、Active Directoryを停止した状態でOSを起動するモードです。主として、名前の通り、Active Directoryを復元するために用いられます。通常はサーバ起動時にF8キーを押すことでこのモードを選択できるのですが、EC2では起動時にF8キーを押すことができませんので、次のように少し手間がかかります。
- 復元したEC2からルートボリュームのEBSをデタッチする
- デタッチしたEBSを作業用のEC2にアタッチする
- ディレクトリサービス復元モードで起動するように設定する
実際に流れを見ていきましょう。
まずは、リストアしたEC2を右クリックしインスタンスの状態 > 停止で停止します。
インスタンスが停止したら、ルートボリュームとして利用しているEBSを右クリックしボリュームのデタッチをクリックします。
デタッチできたら、再度同じEBSを右クリックしボリュームのアタッチをクリックします。アタッチ対象のインスタンスは復元したインスタンス以外の作業用Windows系インスタンスです。なお、作業用インスタンスは復元するサーバとは別バージョンを利用することをお勧め致します(※詳細は「詰まった点」にて後述します)。他にEBSをアタッチしていないため、デバイスはxvdfとします。
EBSをアタッチしたら、作業用インスタンスに接続します。ディスクの管理を開き、アタッチしたEBSがオンラインになっていない場合、右クリックしオンラインでオンライン状態にします。
管理者権限でコマンドプロンプトを起動し、次のコマンドを実行します。D:\Boot\BCDの部分はアタッチしたデバイス名に応じて修正します。なお、このコマンドは起動モードを編集するものです。
bcdedit /store D:\Boot\BCD /set {default} safeboot dsrepair成功すると次のようにこの操作を正しく終了しました。と出力されます。
C:\Users\Administrator>bcdedit /store D:\Boot\BCD /set {default} safeboot dsrepair
この操作を正しく終了しました。再度、作業用インスタンス上でディスクの管理を開き、アタッチしたEBSを右クリックしオフラインでオフライン状態にします。
該当のEBSを作業用インスタンスからデタッチします。
デタッチしたEBSを復元したEC2のルートボリュームにアタッチしなおします。OSバージョンやAMI等により異なる場合はありますが、今回はルートボリュームの/dev/sda1を指定しています。
これで、復元したEC2がディレクトリサービス復元モードで起動するようになります。
Windows Server バックアップからリストアする
該当のEC2がディレクトリサービス復元モードで起動するようになったので、コンソールから起動し、ログインします。なお、ログイン時のユーザはAdministratorで、パスワードはドメインコントローラー昇格時に指定したディレクトリサービス復元モードのパスワードであることに注意が必要です。Active Directoryが動作していないので、ドメインユーザでログインはできません。
起動したら、サーバマネージャーからツール > Windows Server バックアップでwbadminを開きます。
左ペインのローカル バックアップを選択し、右ペインの操作にある回復をクリックします。
はじめにではこのサーバーを選択します。バックアップ先のEBSは自分自身にアタッチされているためです。
バックアップの日付の選択では要件に応じてバックアップを選択し次へをクリックします。
回復の種類の選択ではシステム状態を選択し次へをクリックします。
システム状態の回復先の場所を選択では元の場所を選択しActive Directory ファイルの Authoritative Restore を実行するにもチェックを入れて次へをクリックします。今回のシナリオでは、この時点で他にドメインコントローラーが存在しないため、バックアップを正とします。
警告が出てきますが、OKをクリックします。
確認では次のように指定されていることを確認し回復をクリックします。
- 回復項目: システム状態
- 回復先: 元の場所
- 回復オプション: Authoritative Restore
警告が出てきますが、はいをクリックします。
回復が終わるまで待ちます。スペックにもよると思いますが、t3a.smallでは、ディレクトリのオブジェクトが初期状態でも30分～40分程度かかりました。
終了すると再起動を促すダイアログが出てくるので再起動をクリックします。
再起動完了後、Administratorかつドメインコントローラー昇格時に指定したディレクトリサービス復元モードのパスワードでログインすると、次のように回復が正常完了した旨のコマンドプロンプトが出てきます。
このままだと、延々とディレクトリサービス復元モードで起動してしまうようになってしまうので、解除します。ファイル名を指定して実行にmsconfigと入力してシステム構成を起動します。
ブートタブのセーフ ブートのチェックを外してOKをクリックします。
ダイアログが出てくるので再起動をクリックします。
再起動完了後、今度はドメインユーザでログインします。正常に回復できていればログインできます。
以上で取り急ぎ1台目のドメインコントローラーのリストアはできました。一応サービスは再開可能な段階です。
備考
後続作業
冒頭にも記載しましたが、この後、複数のドメインコントローラーでの冗長構成を復活させるためには、次のような作業が必要になります。
- 他ドメインコントローラーの強制降格を行う
- 他ドメインコントローラーのメタデータを削除する
- 他ドメインコントローラーの再昇格を行う
こちらにつきましては、ドメイン コントローラー降格手順 (Windows Server 2012) RRS feedに公開情報がありますため、そちらをご参考に実施いただければと存じます。
その他の方法
今回は非常に回りくどいリストア手順となりました。未確認ですが、FSMOの役割を持っているドメインコントローラーを停止できるのであれば、停止して一貫性のあるAMIイメージを取得するのも手段としてあり得るものと思います。また、VSSに対応したスナップショットを利用するのも手段として考えられるかもしれません。
参考
詰まった点
ディレクトリサービス復元モードにしたら0xc000000eで起動しない
今回、Active DirectoryはWindows Server 2019を利用して検証を行っていたのですが、途中、ルートボリュームをディレクトリサービス復元モードにする際に利用する作業用インスタンスもWindows Server 2019を利用したところ、次のようなエラーでEC2が起動できなくなってしまいました。
状態: 0xc000000e
情報: 要求されたデバイスが接続されていないか、デバイスにアクセスできません。
フォーラムレベルの情報ですが、どうやら、同じOSバージョンだとこの事象に陥ることがあるようです。試しに別のOSバージョンであるWindows Server 2016を利用したところ、上手くいくようになりました。今回、別バージョンのOSを利用するようにお勧めさせていただいた理由です。
参考
コメント
認識違ってたら申し訳ございません。
全台DC障害を想定して1台目のDCのリストアであれば、
AMIからDCを復元してそのまま起動で良いのではないでしょうか？
USNロールバックも起こりませんし。
もちろんAMIに有効なActiveDirectoryデータが整合性のある状態で取得出来ている前提ですが。
と、書きながら気づきましたが、
「その他の方法」に以下記載されておりました。
———————————–
未確認ですが、FSMOの役割を持っているドメインコントローラーを停止できるのであれば、停止して一貫性のあるAMIイメージを取得するのも手段としてあり得るものと思います。
———————————–
この事から本手順はDCを稼働したままVSS無しでSnapShot取得している前提であるため、Active Directoryの整合性のあるデータはWindows Backup側で取得して、そちら側からリストアする手順であると理解しました。
コメントいただきありがとうございます。
分かりにくい手順となっており恐縮ではございますが、ご記載いただきました下記の通りでございます。
> この事から本手順はDCを稼働したままVSS無しでSnapShot取得している前提であるため、Active Directoryの整合性のあるデータはWindows Backup側で取得して、そちら側からリストアする手順であると理解しました。
全体的な傾向等は把握しておりませんが、DCは無停止で運用されるケースが多いものと考えており、また、執筆当時では通常のスナップショットは停止状態以外での整合性を保障していなかったため、このような紹介をさせていただいた次第です。
現在は、下記の通り、VSSを利用したAWS Backupによるスナップショット取得にも対応しているようでございますので、そちらを利用する手順もあるものと存じます。
https://aws.amazon.com/jp/about-aws/whats-new/2020/09/aws-backup-supports-application-consistent-backups-of-microsoft-workloads-on-ec2/
AWS Backupのリンクについては、記事に反映させていただきました。
改めまして、コメントいただきありがとうございました。
以上、よろしくお願い致します。