Azureで仮想マシンを立てて動かしていると、遅かれ早かれ突き当たるのが「もしこのVMが壊れたら、データはどうなるんだろう」という不安です。オペミスで大事なディスクを消してしまった、更新プログラムを当てたらOSが起動しなくなった、あるいは近年いちばん怖い——ランサムウェアにサーバーごと暗号化された。こういう「いざという時」の保険がAzure Backupです。
ところが、いざMicrosoft Learnの公式ドキュメントを開くと、「Recovery Servicesコンテナー」「GFS保持ポリシー」「不変コンテナー」「MUA」といった聞き慣れない用語が次々に出てきて、「結局どこをどう設定すれば守れるの？」と手が止まってしまいます。私自身、Azureのバックアップを初めて任されたときにまさにここで戸惑いました。
「バックアップって、とりあえず有効化しておけばいいの？ ランサムウェア対策になるって聞くけど、普通のバックアップと何が違うの？ あと料金が青天井にならないか心配…」
この記事では、Azure Backupを「いざという時の保険」＋「攻撃者に壊されない金庫」というたとえで一本筋を通しながら、VMのバックアップ・復元の手順、初心者がつまずくGFS保持ポリシーの設計、そして近年もっとも実務で刺さるランサムウェア対策（論理削除・不変性・多要素削除保護）までを、公式の正確さは押さえつつ日本語で噛み砕いて解説します。読み終わるころには、「何を守るために、どこをどう設定すればいいか」を自分で組み立てられるようになります。
Azure Backupとは？——インフラ不要の「クラウドの金庫」
Azure Backupは、Azure上のVMやデータをクラウドに複製して保護してくれるマネージドバックアップサービスです。ポイントは「マネージド」という言葉です。従来オンプレでバックアップをやろうとすると、テープ装置やバックアップ専用サーバー、保管用のストレージ、それを守るためのソフトウェア……と、けっこうな設備が必要でした。Azure Backupはこうしたバックアップ基盤を自前で持たなくていいのが最大の魅力です。
たとえるなら、貴重品を守るために自宅に金庫室を作るのではなく、銀行の貸金庫を借りるようなものです。金庫室の建築も、警備員の雇用も、耐火設計も全部銀行（Azure）任せ。あなたは「何を、どのくらいの頻度で、どのくらいの期間預けるか」を決めるだけ。預けたデータの保管や冗長化はAzureが面倒を見てくれます。
ここで大事なのが、バックアップは「保険」であって「高可用性」とは別物だという点です。可用性ゾーンやロードバランサーは「今動いているものを止めないための仕組み」ですが、バックアップは「壊れた・消えた・汚染された後で、過去のある時点に巻き戻すための仕組み」です。両方あって初めて安心できる、という関係だと覚えておいてください。
登場人物を整理する：コンテナーとバックアップポリシー
手を動かす前に、Azure Backupの2つの主役を頭に入れておくと、以降がぐっと分かりやすくなります。
Recovery Servicesコンテナー＝金庫本体
Recovery Servicesコンテナー（Vault）は、バックアップした復旧ポイント（過去のスナップショット）を保管する入れ物です。さきほどのたとえでいう「貸金庫そのもの」にあたります。VMをバックアップすると、その中身は毎回このコンテナーに溜まっていきます。
コンテナーを作るときに1つ重要な選択があります。ストレージの冗長性です。これは「金庫を何か所に分けて置くか」の設定で、後述するコストにも復元の柔軟性にも効いてきます。ここでは「LRS（同一データセンター内で3重）／GRS（別リージョンにも複製）」という選択肢がある、とだけ押さえておきましょう。
バックアップポリシー＝預け方のルール
バックアップポリシーは、「いつバックアップを取り（スケジュール）、どのくらい残すか（保持）」を定義したルールです。金庫にたとえるなら、「毎日何時に貴重品を預けに行き、古いものはいつ引き取るか」という運用ルールですね。VMにこのポリシーを紐づけることを、Azureでは「バックアップを有効化する」と呼びます。
つまり流れとしては、①金庫（コンテナー）を用意 → ②預け方のルール（ポリシー）を決める → ③守りたいVMをルールに登録する、という3ステップです。この骨格さえ掴めば、公式ドキュメントの用語の海で迷子になりません。
何を守れるのか？——対応ワークロード
Azure Backupは「VM専用」ではありません。代表的なものだけ挙げると、次のようなワークロードを守れます。
- Azure VM：仮想マシンをまるごと（OSディスク＋データディスク）バックアップ。この記事のメイン。
- Azure Files：クラウドのファイル共有。共有フォルダーごと保護できる。
- VM内のSQL Server：VMの中で動いているSQL Serverを、データベース単位で整合性を取ってバックアップ。
- SAP HANA：Azure VM上のSAP HANAデータベースも対象。基幹系まで守れる。
ここで押さえたいのは、「VMまるごと」と「アプリ単位」で守り方が違うということです。VMバックアップは箱ごと丸ごと。一方でSQL ServerやSAP HANAは、DBのトランザクション整合性を取った上で、DB単位・ログ単位で細かく復元できます。「サーバーが壊れたら箱ごと戻したい」のか「特定のDBだけ数分前に戻したい」のかで、選ぶ守り方が変わる——この感覚を持っておくと設計で迷いません。
実践：VMのバックアップを有効化して復元するまで
では、いちばん基本のVMバックアップを、実際の操作イメージで追ってみます。ポータルとAzure CLIの両方を示します。
① コンテナーを作り、VMにバックアップを有効化する
ポータルなら「Recovery Servicesコンテナー」を新規作成し、コンテナーの中で「バックアップ」→「Azure仮想マシン」を選んで守りたいVMとポリシーを指定するだけです。CLIだと次のような流れになります。
# 1. コンテナーを作成
az backup vault create \
--resource-group myRG \
--name myVault \
--location japaneast
# 2. VMにバックアップを有効化（既定ポリシーを適用）
az backup protection enable-for-vm \
--resource-group myRG \
--vault-name myVault \
--vm myVM \
--policy-name DefaultPolicy各コマンドのざっくりした意味はこうです。
az backup vault create：金庫（コンテナー）そのものを用意する。az backup protection enable-for-vm：指定したVMを「毎日決まった時間に自動でバックアップする対象」として登録する。--policy-nameで預け方のルールを指定。
有効化すると、以降はポリシーのスケジュールに従って自動でバックアップが走ります。VMの中にエージェントを手で入れる必要はなく、Azureが裏側で拡張機能を使ってスナップショットを取ってくれます。
② 今すぐ取りたい：オンデマンドバックアップ
「大きな変更を加える前に、今この瞬間の状態を1個だけ取っておきたい」——こういうときはオンデマンドバックアップを使います。スケジュールを待たずに手動で1回だけ取る操作です。
az backup protection backup-now \
--resource-group myRG \
--vault-name myVault \
--container-name myVM \
--item-name myVM \
--retain-until 31-12-2026--retain-untilで「このオンデマンド分をいつまで残すか」を指定します。危険な作業の直前に一発取っておく、という使い方が実務では鉄板です。
③ 復元する：復旧ポイントから巻き戻す
いざという時が来たら、溜まった復旧ポイント（過去の時点）の一覧から戻したい日時を選んで復元します。VMバックアップの復元には主に2つのやり方があります。
- 新しいVMとして丸ごと復元：その時点のVMをまるっと別の新規VMとして起こす。OSごとおかしくなった時に安全。
- ディスクだけ復元：ディスクを復元して既存VMに付け替える、あるいはファイルを取り出す。「あのファイルだけ戻したい」に対応。
「ファイル1個消しただけなのに、VMまるごと復元しないといけないの？」——いいえ。ファイル単位で取り出す「ファイル回復」機能もあるので、状況に応じて粒度を選べます。
ここで大事な心構えを1つ。バックアップは「取れているか」ではなく「戻せるか」で価値が決まります。有効化して満足せず、一度でいいので実際に復元して「本当に起動するか」を確かめておくこと。これをやっておかないと、本番の障害時に初めて「復元できないバックアップだった」と気づく——という最悪の事故につながります。
スケジュールと保持：どれだけの頻度で、いつまで残すか
ポリシーの中身で最初に決めるのがスケジュール（頻度）と保持期間です。いちばんシンプルな形は「毎日1回バックアップを取り、それを30日間残す」といった日次スケジュール＋日次保持です。
ここで初心者がやりがちなのが、「不安だから全部365日残す」という設定です。気持ちは分かりますが、これはコストの観点で悪手になりがちです。バックアップは残す量と期間に比例して料金がかかるので、「毎日分を1年間フルで残す」と保管データが膨れ上がります。かといって短くしすぎると、「先月末時点に戻したい」に応えられません。
この「細かさ」と「長さ」のジレンマを賢く両立するのが、次に説明するGFS保持です。
GFS保持（祖父-父-子）を写真の保存でたとえる
GFSはGrandfather-Father-Son（祖父-父-子）の略で、残す粒度を期間ごとに変えるという保持の考え方です。言葉は難しそうですが、やっていることはスマホの写真整理とそっくりです。
スマホの写真を思い出してください。直近1週間の写真は全部残していますよね。でも1年前の写真を「毎日全部」持っている人は少なくて、たいてい「イベントの日の1枚」や「月に数枚」に絞られていくはずです。10年前になると「その年の思い出が数枚あればいい」くらいの粒度になる。古くなるほど残す密度を下げていく——これがGFSの発想そのものです。
Azure Backupのポリシーに当てはめると、こういう組み合わせになります。
- 日次（子）：毎日取って、直近30日ぶんを残す。→ 昨日・一昨日の細かい巻き戻しに使う。
- 週次（父）：毎週の特定曜日の分を、12週ぶん残す。→ 「先々週の状態」に戻れる。
- 月次（祖父）：毎月の特定日の分を、12か月ぶん残す。→ 「半年前の月末」に戻れる。
- 年次：毎年の特定日の分を、7年など長期で残す。→ 監査・法令対応の「◯年前の記録」に使う。
こうすると、「直近は細かく、過去は間引いて長く」を同時に満たせます。全部を毎日365日残すのに比べて保管量を大きく減らせるので、要件（どこまで戻せる必要があるか）とコストのバランスが取れるわけです。監査で「7年保存」が求められる業種でも、年次だけ7年に伸ばせば、日次まで7年持つ必要はありません。
GFSは最初こそ「設定項目が多くて面倒」に見えますが、写真整理と同じで「古いものほど間引く」だけと捉えれば怖くありません。ポリシーの日次・週次・月次・年次の各欄に、それぞれの保持日数を入れていくだけです。
【最重要】ランサムウェア対策：金庫そのものを守る
ここからが、近年もっとも実務で重要になっているテーマです。従来「バックアップさえ取っていれば安心」でしたが、ランサムウェア攻撃はその常識を崩しました。
最近の攻撃者は賢くて、サーバーを暗号化する前にまずバックアップを探し出して削除・破壊しにきます。なぜなら、バックアップが生きていれば身代金を払わずに復旧できてしまうからです。つまり「バックアップごと人質に取る」のが今の手口。金庫のたとえでいえば、泥棒が金庫の中身を盗む前に、まず金庫の鍵と予備の金庫を壊しにくるようなものです。
そこでAzure Backupには、「金庫そのものを攻撃者から守る」ための三重の防御が用意されています。1つずつ見ていきましょう。
① 論理削除（Soft Delete）：消しても14日間は残る
論理削除は、バックアップデータが「削除」されてもすぐには物理的に消えず、一定期間（既定14日間）ゴミ箱状態で保持される仕組みです。攻撃者やオペミスでバックアップを消されても、その期間内なら復活できます。PCのゴミ箱と同じ発想ですが、これが標準で有効になっているのが重要です。さらに強化版として、その期間中は攻撃者でも完全削除できない「常時オン」の設定もあり、より確実に守れます。
② 不変性（イミュータブル）：書き換え・早期削除を禁じる
不変コンテナー（イミュータブルVault）は、いったん保管した復旧ポイントを、保持期間が切れるまで「書き換えも早期削除もできない」ようにロックする設定です。金庫でいえば、一度預けたら期限が来るまで誰も——管理者本人ですら——中身を取り出して書き換えられない、開かずの金庫にするイメージ。
これがランサムウェア対策として強力なのは、攻撃者が管理者権限を奪ったとしても、不変ロックされた復旧ポイントは改ざんも削除もできないからです。「保持期間を1日に縮めて即削除」といった裏技も封じられます。不変性はロック解除できる状態とロックしたら二度と緩められない状態を選べるので、本番の重要データには後者を検討します。
③ 多要素削除保護（MUA）：危険な操作に二人目の承認を要求
MUA（Multi-User Authorization／多要素承認）は、バックアップの削除や保護の停止といった「危険な操作」に、もう一人の承認を必須にする仕組みです。「Resource Guard」という別のガード役リソースを間に挟むことで実現します。
たとえるなら、核ミサイルの発射に二人の鍵が同時に必要な「ツーマンルール」です。たとえ攻撃者が1つのアカウントを乗っ取っても、削除操作には別の管理者（Resource Guardを管理する側）の承認が要るため、単独ではバックアップを消せません。人為ミスの防止にも効きます。
この3つは重ねて使うほど強いのがポイントです。論理削除で「消しても消えない」、不変性で「そもそも改ざん・早期削除できない」、MUAで「危険な操作に承認を挟む」。中身（VM）だけでなく金庫（コンテナー）そのものを守る——これが現代のバックアップ設計の勘所です。
クロスリージョン復元（CRR）：地域まるごとダウンに備える
ここまでは「データを守る」話でした。次は「リージョンごと使えなくなったらどうするか」という一段大きな備えです。
コンテナー作成時に冗長性をGRS（geo冗長ストレージ）にしておくと、バックアップはペアリージョン（東日本なら西日本のような対のリージョン）にも自動で複製されます。この状態でクロスリージョン復元（CRR）を有効にしておくと、元のリージョンが災害などでダウンしていても、ペアリージョン側から復元できます。
金庫のたとえでいえば、大事な書類のコピーを、別の街の支店の金庫にも置いておくようなもの。本店が火事になっても、別の街の支店からいつでも取り出せます。ただしCRRを使うにはコンテナーの冗長性がGRSであることが前提です。後述しますがGRSはLRSより料金が高いので、「そこまでの災害耐性が要るか」を要件と照らして選びます。
RBACと監視：Backup Centerで一元管理する
コンテナーが1つ2つのうちはいいのですが、プロジェクトが増えると「どのVMがちゃんとバックアップ取れてる？失敗してない？」を全体で見たいという悩みが出ます。ここで使うのがBackup Centerです。
Backup Centerは、複数のコンテナー・サブスクリプションをまたいでバックアップの状態を一元監視できる管理画面です。「昨夜バックアップに失敗したジョブはどれか」「保護されていないVMはないか」を横断的に確認できるので、運用のダッシュボードとして重宝します。
権限（RBAC）の面では、担当者にフルの所有者権限を渡すのではなく、目的に合ったバックアップ用の組み込みロールで委任するのが基本です。代表的なのが次の2つです。
- バックアップ共同作成者（Backup Contributor）：バックアップの有効化・ポリシー設定・オンデマンド実行などができる。ただしコンテナー自体の削除やアクセス権の付与はできないので、運用担当に渡すのに向く。
- バックアップオペレーター（Backup Operator）：バックアップの実行や復元はできるが、ポリシーの変更はできない、より限定的なロール。
「バックアップを運用する人」に金庫の建て直し権限（削除）まで渡す必要はありません。最小権限で委任するのは、先ほどのMUAとも思想が一貫しています。Azure全体の権限設計の考え方は Azure RBACの記事 でも噛み砕いているので、あわせて読むと理解が深まります。
コスト：料金は「保護インスタンス＋ストレージ」で決まる
最後にお金の話です。心配された「青天井にならないか」ですが、Azure Backupの料金は大きく2つの要素で決まると理解すれば、見積もりの見当がつきます。
- 保護インスタンス料金：バックアップ対象1つあたりの基本料金。守るデータのサイズ帯によって単価が決まる。
- バックアップストレージ料金：実際にコンテナーに保管しているデータ量に対する料金。ここが保持期間と冗長性で変動する。
コストを左右する最大のツマミは冗長性の設定です。同じデータでも、LRS（同一データセンターに3重）＜ ZRS（ゾーンに分散）＜ GRS（別リージョンにも複製）の順に保管コストが上がります。GRSは災害に強い代わりに、複製する分だけ料金が乗るわけです。
だからこそ、コストは「要件から逆算」して決めるのが正解です。「絶対に地域災害からも守りたい重要システム」はGRS＋長期保持、「壊れても数日前に戻せれば十分な検証環境」はLRS＋短期保持、といった具合に。全部を最強設定にするとムダに高くなり、全部を最安にすると要件を満たせない——このバランス取りこそがバックアップ設計の腕の見せ所です。GFS保持で「古いものは間引く」のも、まさにこのコスト最適化の一環でした。
まとめ
この記事では、Azure Backupを「いざという時の保険」＋「攻撃者に壊されない金庫」という軸で、実務でつまずく順に見てきました。要点を振り返ります。
- Azure Backup：バックアップ基盤を自前で持たずに済むマネージドサービス。可用性とは別物の「巻き戻すための保険」。
- 2つの主役：復旧ポイントを保管するコンテナー（金庫）と、頻度・保持を決めるポリシー（預け方のルール）。
- 基本の流れ：有効化 → 自動でスケジュール実行 → 危険な作業前はオンデマンド → 復旧ポイントから復元。「戻せるか」を必ず試す。
- GFS保持：写真整理と同じで「古いものほど間引く」。要件とコストを両立する保持設計。
- ランサムウェア対策：論理削除・不変性・MUAの三重で、中身だけでなく金庫そのものを守る。ここが現代の最重要。
- CRR：GRSコンテナーでペアリージョンから復元。地域災害への備え。
- Backup Center＋RBAC：横断監視と最小権限の委任。
- コスト：保護インスタンス＋ストレージ。冗長性と保持期間を要件から逆算する。
ここまで押さえれば、「何を守るために、どこをどう設定すればいいか」を自分で組み立てられるはずです。まずは検証用のVMを1台、LRS＋日次30日あたりの軽い設定でバックアップ有効化 → 復元まで一周してみてください。手を動かすと、用語の霧が一気に晴れます。
あわせて読みたい：
