「オンプレではテープバックアップとストレージスナップショットで守っていたけれど、Azure上のVMはどうやってバックアップすればいいのか？」
クラウド移行を進めると、こういう疑問がすぐに出てきます。オンプレ時代に慣れ親しんだ運用をそのまま持ち込もうとすると、クラウドの仕組みとかみ合わずに戸惑うことも多いです。
この記事では、Azure Backupについて、オンプレ経験者にもわかりやすく解説します。Azure VMのバックアップ設定からAzure Filesのバックアップ、RPO・RTO設計の考え方、料金の仕組み、実務でよく踏むトラブルまで、現場で使えるレベルで体系的にまとめました。
なぜAzure Backupなのか？オンプレとの違いを理解する
オンプレミスのバックアップ運用では、専用のバックアップソフト（Veeam、Symantec BackupExec、IBM Spectrum Protectなど）を導入し、バックアップサーバーとメディア（テープやNAS）を自前で管理するのが一般的でした。初期投資が大きく、メディアの管理・世代管理・オフサイト保管なども全て自分たちでやる必要がありました。
Azure Backupはこの面倒をまるごとマネージドサービスとして提供します。
・専用バックアップサーバー不要: バックアップデータはAzure上の「Recovery Services コンテナー」に格納されます
・無制限のスケール: バックアップデータのストレージ容量を事前に確保する必要がありません
・ジオ冗長ストレージ対応: 既定でGRS（地理冗長ストレージ）が使え、リージョン障害にも備えられます
・ランサムウェア対策: 不変ストレージ（Immutable Vault）機能があり、バックアップデータへの上書き・削除を防止できます
・一元管理: Azure PortalやAzure MonitorからVM・Files・SQL・SAP HANAのバックアップを一元管理できます
オンプレの延長線でなく、クラウドネイティブなバックアップ設計として考えるのがコツです。
Azure Backupの基本概念を整理する
設定に入る前に、登場する用語を整理しておきます。
| 用語 | 意味 | オンプレ相当 |
|---|---|---|
| Recovery Services コンテナー | バックアップデータと復元ポイントを格納するAzureリソース | バックアップサーバー＋メディアの倉庫 |
| バックアップポリシー | バックアップ頻度・時刻・保持期間を定義するルール | バックアップスケジュール設定 |
| 復元ポイント | 特定時点のスナップショット。この時点に戻せる | バックアップ世代 |
| インスタントリストア | スナップショットから素早くファイル単位で取り出せる機能 | ディスクスナップショットからのファイル取り出し |
| GRS / LRS | 地理冗長ストレージ / ローカル冗長ストレージ（コンテナーの冗長設定） | オフサイト保管あり / ローカル保管のみ |
Recovery Services コンテナーはリージョン単位で作成します。東日本リージョン（japaneast）のVMをバックアップするには、同じ東日本リージョンにコンテナーを作成するのが基本です。
Azure VMのバックアップ設定（基本的な使い方）
ここからは実際の設定手順を順番に説明します。Azure PortalとAzure CLIの両方を紹介します。
1. Recovery Services コンテナーを作成する
まずバックアップデータの格納先を作ります。
Azure Portal操作:
「Recovery Services コンテナー」で検索 → 「作成」→ サブスクリプション・リソースグループ・コンテナー名・リージョンを入力して作成します。
Azure CLIの場合:
# リソースグループ作成（既存があればスキップ） az group create --name rg-backup --location japaneast # Recovery Services コンテナーを作成 az backup vault create \ --resource-group rg-backup \ --name myRecoveryVault \ --location japaneast
コンテナーのストレージ冗長性はデフォルトがGRS（地理冗長）です。コスト優先でLRS（ローカル冗長）に下げることもできますが、最初のバックアップ保護を有効にする前にしか変更できません。後から変更できないので要注意です。
2. バックアップポリシーを設計する
ポリシーはバックアップの頻度・時刻・保持期間を定義します。Azureのデフォルトポリシーは以下の設定です。
・頻度: 毎日 1回
・時刻: 午後 11:30（UTC）
・即時復元（スナップショット）保持: 2日間
・日次バックアップ保持: 180日間
これをRPO・RTOの要件に合わせてカスタマイズします。RPOとRTOについては後の章で詳しく説明します。
# バックアップポリシーの確認（既定ポリシーを表示） az backup policy show \ --resource-group rg-backup \ --vault-name myRecoveryVault \ --name DefaultPolicy
3. Azure VMのバックアップを有効化する
バックアップしたいVMに対してバックアップ保護を有効にします。
Azure Portal操作:
Recovery Services コンテナー → 「バックアップ」→ ワークロードの場所「Azure」・バックアップ対象「仮想マシン」→ 対象VMを選択 → 「バックアップの有効化」
Azure CLIの場合:
# VMのバックアップ有効化 az backup protection enable-for-vm \ --resource-group rg-backup \ --vault-name myRecoveryVault \ --vm /subscriptions/{サブスクリプションID}/resourceGroups/rg-vm/providers/Microsoft.Compute/virtualMachines/myVM \ --policy-name DefaultPolicy # 今すぐバックアップを実行（初回） az backup protection backup-now \ --resource-group rg-backup \ --vault-name myRecoveryVault \ --container-name myVM \ --item-name myVM \ --retain-until 2026-12-31 \ --backup-management-type AzureIaasVM
初回バックアップはVMのディスクサイズによって数十分かかる場合があります。Azure Portalの「バックアップジョブ」で進捗を確認できます。
Azure FilesとSQLデータベースのバックアップ
Azure BackupはVMだけでなく、複数のワークロードに対応しています。
Azure Filesのバックアップ
Azure Files（ファイル共有）のバックアップもRecovery Services コンテナー経由で設定できます。バックアップはスナップショットベースで動作し、ファイル単位の復元が可能です。
# Azure Filesのバックアップ有効化 az backup protection enable-for-azurefileshare \ --resource-group rg-backup \ --vault-name myRecoveryVault \ --policy-name DefaultPolicy \ --storage-account myStorageAccount \ --azure-file-share myFileShare
Azure Filesのバックアップはストレージアカウントと同じリージョンのコンテナーに格納されます。GRSのコンテナーを使っていてもAzure Filesのバックアップデータ自体はLRS/ZRS相当の保護です（2026年3月時点）。設計時に注意してください。
Azure SQL DatabaseのバックアップとPITR
Azure SQL Databaseは自動バックアップが標準で有効になっており、追加設定なしにポイントインタイムリストア（PITR）が使えます。
・完全バックアップ: 毎週 1回
・差分バックアップ: 12時間ごと
・トランザクションログバックアップ: 5～10分ごと
デフォルトで7日間保持（DTUモデル）、最大35日間まで延長可能です。Azure SQL DatabaseのバックアップはAzure Backupとは別の仕組みで動いていますが、Azure Portalからバックアップ保持期間の設定変更ができます。
RPO・RTOの考え方とバックアップポリシー設計
オンプレ時代のBCP（事業継続計画）でも使われていたRPOとRTOですが、クラウド移行後もこの考え方は変わりません。
・RPO（Recovery Point Objective）: 障害発生時に許容できるデータ損失の最大時間。「直近1時間前のバックアップまで許容」ならRPO = 1時間
・RTO（Recovery Time Objective）: 障害発生からサービス復旧までの目標時間。「4時間以内に復旧」ならRTO = 4時間
| 要件 | 推奨設定 |
|---|---|
| RPO = 24時間（業務データ） | 日次バックアップ（デフォルト設定で対応可） |
| RPO = 4時間（基幹系） | 強化ポリシー（Enhanced Policy）で1日複数回バックアップ |
| RPO = 数分（DBデータ） | Azure SQL PITR（5～10分間隔のログバックアップ）を活用 |
| RTO = 4時間以内 | インスタントリストア（スナップショット）の保持期間を5～7日に延長 |
| RTO = 24時間以内 | 標準バックアップ（コンテナーからの復元）で対応可 |
インスタントリストアとコンテナー復元の違いを理解しておくことが重要です。インスタントリストアはVMのローカルスナップショットから復元するため数分～数十分で完了しますが、スナップショットの保持期間（デフォルト2日）を過ぎると、コンテナーに転送されたバックアップデータからの復元になり、復元時間が長くなります。RTOが厳しいシステムはスナップショット保持期間を長めに設定してください。
料金の仕組みとコスト計算
Azure Backupの料金は主に2つの要素で構成されます（2026年3月時点）。
・保護されたインスタンス料金: バックアップ対象リソースのサイズに応じた月額固定費
・バックアップストレージ料金: 実際に使用したバックアップストレージ容量に応じた従量課金
| VMサイズ（フロントエンドストレージ） | インスタンス料金（概算・USD） |
|---|---|
| 50 GB 未満 | 約 $5/月 |
| 50 GB ～ 500 GB | 約 $10/月 |
| 500 GB 超 | 約 $10 + 超過分 $5/500GB |
これにバックアップストレージ料金（GRSなら約 $0.027/GB など）が加算されます（2026年3月時点）。実際のコストはAzure料金計算ツール（Azure Pricing Calculator）で試算することを強くお勧めします。
コスト削減のポイントは以下の3つです。
・不要な世代を削除する: デフォルトの180日保持は過剰なケースも多い。業務要件を確認して短縮する
・LRS vs GRS を使い分ける: 開発・検証環境はLRS（約50%安）、本番だけGRSというメリハリをつける
・インスタントリストアの保持を適切に設定: 保持期間が長いほどスナップショットのストレージコストが増える
応用・実務Tips
クロスリージョン復元（Cross Region Restore）
GRSコンテナーを使っていると、セカンダリリージョン（東日本→西日本など）へのクロスリージョン復元が可能になります。リージョン全体の障害に備えるDR設計として有効ですが、追加コストがかかります。クロスリージョン復元を有効にすると、バックアップストレージのコストが約1.5倍になる点に注意してください。
バックアップセンターで一元管理
複数のサブスクリプション・コンテナーにまたがるバックアップを一元管理するには、バックアップセンターを活用します。Azure Portalの「バックアップセンター」から全リソースのバックアップジョブ状況・アラート・ポリシーコンプライアンスを横断的に確認できます。マルチアカウント環境では必ず設定しておくことをお勧めします。
Soft Deleteで誤削除を防ぐ
Azure Backupにはソフトデリート（Soft Delete）機能があり、誤ってバックアップ保護を解除してもデータが14日間は保持されます。デフォルトで有効になっていますが、意図的に無効化してしまっているケースがあるので、確認しておきましょう。
Azure PolicyでBackup強制適用
組織のセキュリティポリシーとして「全VMにバックアップを必須化」したい場合、Azure Policyで「バックアップが構成されていないVMにはDefaultPolicyを適用する」ルールを設定できます。これにより、バックアップ設定漏れを自動修正できます。
よくあるトラブルと対処法
「バックアップジョブが失敗する」
最も多いのはVMエージェント（Azure VM Agent）が古いか壊れているケースです。VMにSSHまたはRDPで接続してエージェントの状態を確認してください。Linux VMならwaagent --version、Windows VMならサービス一覧で「Windows Azure Guest Agent」が実行中かを確認します。エージェントを最新版に更新すると解消することがほとんどです。
「復元先に十分なクォータがない」
VM復元時に「コアクォータが不足している」エラーが出ることがあります。AzureサブスクリプションにはリージョンごとにvCPUのクォータ上限があります。Azureサポートに増量申請が必要です。DR訓練の前にクォータを確認しておくことを強くお勧めします。
「インスタントリストアの選択肢がグレーアウトしている」
バックアップ時のスナップショット保持期間（デフォルト2日）を過ぎた復元ポイントはインスタントリストアが使えません。コンテナー経由の通常復元（時間がかかる）になります。RTOが厳しいシステムは保持期間を延長しておきましょう。
「Azure FilesのバックアップがSoft Deleteで削除できない」
Azure Filesのソフトデリートはストレージアカウント側の設定とAzure Backup側の設定が絡みます。保護を解除した後もソフトデリート保持期間（14日間）はコストが発生します。期間終了を待つか、Azure Portalから強制削除が必要です。
本記事のまとめ
Azure Backupは、オンプレミスでは自前で担っていたバックアップサーバー・メディア管理・世代管理をすべてマネージドサービスとして提供します。
・Recovery Services コンテナーがバックアップの格納先。GRS/LRSはバックアップ開始前にしか変更できない
・バックアップポリシーでRPO要件に合わせた頻度・保持期間を設計する
・インスタントリストアを活用してRTOを短縮する。保持期間の設定が鍵
・Azure SQLは自動バックアップ＋PITRで数分単位の復元が可能
・コスト削減はGRS/LRS使い分けと保持期間の見直しから
・バックアップセンターで複数環境を一元管理する
バックアップはいざという時にしか使わないからこそ、障害が発生する前に設計・テストを済ませておくことが大切です。年に1回はDR訓練として実際に復元テストを実施する運用サイクルを組み込むことをお勧めします。
Linuxサーバーの管理や監視の基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。Azure VM上のLinux運用に役立ててください。
Azure Backupの設計、もっと深掘りしたいですか？
クラウド移行後のバックアップ設計やDR構成は、オンプレの常識をそのまま持ち込むと落とし穴にはまります。
オンプレの経験を活かしながら、現場で使えるクラウドスキルを体系的に身につけたい方へ、メルマガで実践的なクラウド活用ノウハウをお届けしています。
