Azure Backupとは？VMのバックアップ・復元・コンテナー/ポリシーを実務目線で解説【入門編】

Azureで仮想マシンを立てて動かしていると、遅かれ早かれ突き当たるのが「もしこのVMが壊れたら、データはどうなるんだろう」という不安です。オペミスで大事なディスクを消してしまった、更新プログラムを当てたらOSが起動しなくなった、あるいはVM内のファイルをうっかり削除してしまった——こういう「いざという時」の保険がAzure Backupです。

ところが、いざMicrosoft Learnの公式ドキュメントを開くと、「Recovery Servicesコンテナー」「バックアップポリシー」「復旧ポイント」といった聞き慣れない用語が次々に出てきて、「結局どこをどう設定すれば守れるの？」と手が止まってしまいます。私自身、Azureのバックアップを初めて任されたときにまさにここで戸惑いました。

「バックアップって、とりあえず有効化しておけばいいの？そもそも何を守れるの？ VMを実際に戻すにはどうすればいいの？」

この記事はAzure Backupシリーズの入門編（ハブ）です。Azure Backupを「いざという時の保険」＝「クラウドの貸金庫」というたとえで一本筋を通しながら、Backupとは何か、登場人物であるコンテナーとポリシー、何を守れるのか（対応ワークロード）、そしてVMを実際にバックアップして復元するまでの手順、最後にスケジュールと保持の考え方までを、公式の正確さは押さえつつ日本語で噛み砕いて解説します。読み終わるころには、検証用のVMを1台、自力でバックアップ→復元まで一周できるようになります。

なお、GFS保持の設計・ランサムウェア対策（論理削除／不変性／MUA）・クロスリージョン復元・Backup Centerでの一元管理・コスト最適化といった応用テーマは、この記事の続編にあたる保護・運用編（Azure Backupの保護・運用編）で扱います。まずは本記事で土台を固めましょう。

Azure Backupとは？——インフラ不要の「クラウドの金庫」
登場人物を整理する：コンテナーとバックアップポリシー
何を守れるのか？——対応ワークロード
実践：VMのバックアップを有効化して復元するまで
スケジュールと保持：どれだけの頻度で、いつまで残すか
まとめ
さらに深く学ぶ：Azure Backup 保護・運用編
Azureのスキルを「年収」に変えるなら

Azure Backupとは？——インフラ不要の「クラウドの金庫」

Azure Backupは、Azure上のVMやデータをクラウドに複製して保護してくれるマネージドバックアップサービスです。ポイントは「マネージド」という言葉です。従来オンプレでバックアップをやろうとすると、テープ装置やバックアップ専用サーバー、保管用のストレージ、それを守るためのソフトウェア……と、けっこうな設備が必要でした。Azure Backupはこうしたバックアップ基盤を自前で持たなくていいのが最大の魅力です。

たとえるなら、貴重品を守るために自宅に金庫室を作るのではなく、銀行の貸金庫を借りるようなものです。金庫室の建築も、警備員の雇用も、耐火設計も全部銀行（Azure）任せ。あなたは「何を、どのくらいの頻度で、どのくらいの期間預けるか」を決めるだけ。預けたデータの保管や冗長化はAzureが面倒を見てくれます。

ここで大事なのが、バックアップは「保険」であって「高可用性」とは別物だという点です。可用性ゾーンやロードバランサーは「今動いているものを止めないための仕組み」ですが、バックアップは「壊れた・消えた後で、過去のある時点に巻き戻すための仕組み」です。両方あって初めて安心できる、という関係だと覚えておいてください。

登場人物を整理する：コンテナーとバックアップポリシー

手を動かす前に、Azure Backupの2つの主役を頭に入れておくと、以降がぐっと分かりやすくなります。

Recovery Servicesコンテナー＝金庫本体

Recovery Servicesコンテナー（Vault）は、バックアップした復旧ポイント（過去のスナップショット）を保管する入れ物です。さきほどのたとえでいう「貸金庫そのもの」にあたります。VMをバックアップすると、その中身は毎回このコンテナーに溜まっていきます。

コンテナーを作るときに1つ重要な選択があります。ストレージの冗長性です。これは「金庫を何か所に分けて置くか」の設定で、コストにも復元の柔軟性にも効いてきます。ここでは「LRS（同一データセンター内で3重）／GRS（別リージョンにも複製）」という選択肢がある、とだけ押さえておきましょう。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だけ数分前に戻したい」のかで、選ぶ守り方が変わる——この感覚を持っておくと設計で迷いません。

なお、Azure Filesの保護対象や使いどころは Azure File Storage完全ガイドで深掘りしているので、ファイル共有を守りたい方はあわせて読むと具体像がつかめます。

実践：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日間残す」といった日次スケジュール＋日次保持です。

スケジュールは「毎日この時間に取る」「週に何回取る」といった取るタイミングを、保持は「取ったものを何日／何週／何か月残すか」という残す長さを決めます。この2つはセットで、たとえば「日次で取り30日保持」なら、常に直近30日ぶんの復旧ポイントが金庫に並んでいる状態になります。31日目には最古の1つが自動で消えていく、というイメージです。

ここで初心者がやりがちなのが、「不安だから全部365日残す」という設定です。気持ちは分かりますが、これはコストの観点で悪手になりがちです。バックアップは残す量と期間に比例して料金がかかるので、「毎日分を1年間フルで残す」と保管データが膨れ上がります。かといって短くしすぎると、「先月末時点に戻したい」に応えられません。

この「細かさ」と「長さ」のジレンマを賢く両立するのがGFS保持（祖父-父-子）という考え方ですが、これは設計の話が一段深くなるので、続編の保護・運用編でじっくり扱います。入門段階では、まず「日次で取って30日残す」くらいの軽い設定で一度動かしてみるのが正解です。要件が見えてきてから保持を伸ばす・間引く、という順番で十分間に合います。

まとめ

この記事では、Azure Backupの入門として「いざという時の保険」＝「クラウドの貸金庫」という軸で、基本の流れを見てきました。要点を振り返ります。

Azure Backup：バックアップ基盤を自前で持たずに済むマネージドサービス。可用性とは別物の「巻き戻すための保険」。
2つの主役：復旧ポイントを保管するコンテナー（金庫）と、頻度・保持を決めるポリシー（預け方のルール）。
対応ワークロード：Azure VM・Azure Files・VM内SQL Server・SAP HANA。「箱ごと」か「アプリ単位」かで守り方が変わる。
基本の流れ：有効化 → 自動でスケジュール実行 → 危険な作業前はオンデマンド → 復旧ポイントから復元。「戻せるか」を必ず試す。
スケジュールと保持：まずは「日次で取り30日保持」の軽い設定から。要件が見えたら調整する。

ここまで押さえれば、Azure Backupの土台は固まりました。まずは検証用のVMを1台、日次30日あたりの軽い設定でバックアップ有効化 → 復元まで一周してみてください。手を動かすと、用語の霧が一気に晴れます。