第 15 章 Azure リソースの監視と管理（10〜15%）
バックアップと回復
この章で学ぶこと
- Recovery Services コンテナーの作成
- Azure Backup コンテナーを作成する
- バックアップ ポリシーを作成して構成する
- Azure Backup を使用してバックアップと復元の操作を実行する
- Azure リソース用に Azure Site Recovery を構成する
この章に出てくる用語
- Azure Backup
- VM やファイル、データベースの複製を定期的に取り、必要なときに元の場所へ戻すためのサービス。 バックアップ先のストレージは Azure が管理するので、利用者は「何を」「どれくらいの頻度で」「どれだけの期間」残すかを決めるだけでよい。ここで言う「コンテナー（Vault）」は、バックアップデータと設定を入れておく器で、Blob のコンテナーとは別物。
- Azure Site Recovery（ASR）
- サーバーを別の場所へ継続的に複製しておき、障害時にそちらへ切り替えて動かし続けるためのサービス。 Backup が「あとで戻すための複製」なのに対し、こちらは「すぐ動かせる状態の複製」を別リージョンに持ち続ける。オンプレミスから Azure への移行にも使われる。
バックアップデータを入れる器が 2 種類あり、守る対象によってどちらを使うかが決まっている。選択の余地はない。
| ワークロード | コンテナー |
|---|---|
| Azure VM | Recovery Services コンテナー |
| Azure VM 内の SQL Server / SAP HANA | Recovery Services コンテナー |
| Azure Files | Recovery Services コンテナー |
| オンプレの Windows Server（MARS エージェント） | Recovery Services コンテナー |
| System Center DPM / Azure Backup Server（MABS） | Recovery Services コンテナー |
| Azure Site Recovery | Recovery Services コンテナー |
| Azure Blob | Backup コンテナー |
| Azure Disk | Backup コンテナー |
| Azure Database for PostgreSQL | Backup コンテナー |
| Kubernetes（AKS） | Backup コンテナー |
試験では
覚え方は「従来からのワークロードは Recovery Services、比較的新しいデータサービスは Backup コンテナー」。Azure Site Recovery も Recovery Services コンテナーを使う点に注意する。
後から変更できない設定
試験では
コンテナーのストレージ冗長性（LRS / GRS / ZRS）は、最初のバックアップを保護した後は変更できない。「後から GRS にしたい」→ できない。コンテナーを作り直すことになる。これが最も定番の設問。
補足
GRS のコンテナーではリージョン間復元（CRR）を有効にできる。Microsoft が障害を宣言するのを待たずに、自分の判断でセカンダリリージョンの復旧ポイントから復元できるようになる。
バックアップポリシーは、頻度（スケジュール）と保持期間（日次・週次・月次・年次）を定義する。1 つのポリシーを複数のリソースに適用できる。
インスタント復元
バックアップ時には、まずスナップショットが取られる。コンテナーへ転送し終える前でも、このスナップショットから高速に復元できる。既定の保持は 2 日で、1〜5 日の範囲で設定できる。
論理的な削除
試験では
削除されたバックアップデータは追加で 14 日間保持され、この期間は課金されない。「バックアップを消したのにすぐ消えない」「誤って消したが戻せるか」の答えがこれ。強化された論理的な削除では期間をカスタマイズでき、常時オンにもできる。
オンプレミスをバックアップする
| ツール | できること | こう聞かれたら選ぶ |
|---|---|---|
| MARS エージェント | Windows のファイル・フォルダー・システム状態を直接 Azure へ | ファイル単位で手軽に |
| Azure Backup Server（MABS）/ DPM | SQL、SharePoint、Exchange、Hyper-V / VMware VM | アプリケーション整合性／ベアメタル復旧 |
試験では
MARS エージェントだけではアプリケーション整合性のあるバックアップやベアメタル復旧はできない。SQL Server や Exchange を止めずに整合性を保って取りたいなら MABS / DPM が要る。
# Recovery Services コンテナーを作る
az backup vault create -g rg -n vault1 \
--location japaneast
# VM の保護を有効にする
az backup protection enable-for-vm -g rg \
--vault-name vault1 --vm vm1 \
--policy-name DefaultPolicy
# ディスクを復元する
az backup restore restore-disks -g rg \
--vault-name vault1 --container-name <c> \
--item-name vm1 --rp-name <復旧ポイント> \
--storage-account <保存先>VM やサーバーを別リージョン（またはオンプレから Azure）へ継続的にレプリケートし、災害時にそちらへ切り替えて動かし続けるサービスだ。
試験では
Backup は「戻す」、Site Recovery は「別の場所で動かし続ける」。「リージョン障害が起きても業務を継続したい」→ Site Recovery。「誤って消したファイルを戻したい」→ Backup。どちらか一方で両方は賄えない。
RPO と RTO
| 指標 | 意味 | 覚え方 |
|---|---|---|
| RPO（復旧ポイントの目標） | 障害時に失われうるデータの時間幅 | どこまで戻るか |
| RTO（復旧時間の目標） | 復旧までにかかる時間の目標 | どれだけ早く戻るか |
フェールオーバーの種類
試験では
「本番を止めずに復旧手順を確認したい」→ テストフェールオーバー。分離したネットワークで実行されるので、稼働中のシステムに影響しない。定期的に実施して手順を検証するのが実務でも推奨される。
フェールオーバーの後、元のリージョンへ戻すには再保護（逆方向へレプリケートし直す）とフェールバック（元へ切り替える）の 2 段階が必要になる。単に「戻す」ボタンがあるわけではない。
バックアップレポートは、バックアップの成否・使用容量・ポリシー準拠を集計する機能だ。
試験では
バックアップレポートの利用には Log Analytics ワークスペースが必要。コンテナーの画面だけでは出ない。第 14 章の診断設定でログを送る構成が前提になる。
補足
バックアップジョブの失敗は、Azure Monitor のアラートで通知できる。アクショングループ（第 14 章）を使い回せるので、他の監視と同じ通知先にまとめられる。
この章のまとめ
- Azure VM をバックアップするコンテナー
- Azure Blob をバックアップするコンテナー
- Azure Site Recovery が使うコンテナー
- コンテナーのストレージ冗長性は後から変更できるか
- GRS のコンテナーで障害宣言を待たずに復元する機能
- インスタント復元スナップショットの既定の保持