Azureスナップショットでディスクをバックアップしているサーバー管理者は多いですが、実際にスナップショットから復元して「何分で元に戻せたか」を計測したことがある人は多くありません。RTO(Recovery Time Objective:目標復旧時間)を設計しているチームでも、実測値と目標値がどれだけ乖離しているかを把握していないケースがほとんどです。
この記事では、Rocky Linux 9系/Ubuntu 24.04 LTSを想定環境として、AzureスナップショットとazコマンドでLinux VMのDR訓練を実施し、復元RTOを計測する手順を解説します。OSディスクスワップによる既存VM復旧の流れ、時刻記録スクリプトによるRTO可視化、訓練中に起きやすいトラブルへの対処まで網羅します。
この記事のポイント
・az snapshot createとaz disk createでスナップショット復旧を再現できる
・date +%s でDR開始・完了の時刻を記録してRTOを秒単位で計測する
・OSディスクスワップでVMを削除せずにスナップショット時点に戻せる
・計測結果を記録して月次訓練のRTO改善サイクルを回す
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜDR訓練でRTOを計測するのか
障害時の復旧計画(DRP)には必ずRTO(目標復旧時間)が設定されています。「2時間以内にサービスを再開する」という目標が実際に達成可能かどうかは、訓練で実測するまでわかりません。スナップショットの作成に7分、ディスク作成に10分、VM再起動の確認に5分、設定確認に15分——合計37分かかっていた、という結果が出て初めて「手順を自動化すれば20分に短縮できる」という改善方針が立てられます。
・RTOを実測するメリット:目標時間との乖離を数値で把握できる
・定期訓練のメリット:スタッフが手順に慣れ、緊急時の判断ミスが減る
・訓練記録のメリット:改善履歴が残り、監査・コンプライアンス対応にも使える
Azureスナップショットはマネージドディスクのポイントインタイムコピーで、同一リージョン内であれば数分で取得でき、訓練シナリオの起点として扱いやすいのが特徴です。
訓練前準備:スナップショットの取得
DR訓練は「訓練用スナップショットを取得 → 障害シナリオを実施 → スナップショットで復元 → RTO記録」の流れで行います。まず訓練用スナップショットを取得します。1. 対象VMのOSディスクIDを取得する
スナップショットの作成元となるOSディスクのリソースIDを取得します。# リソースグループ名とVM名を変数に設定する RG="myResourceGroup" VM="myLinuxVM" # OsディスクのリソースIDを取得する DISK_ID=$(az vm show \ --resource-group "$RG" \ --name "$VM" \ --query "storageProfile.osDisk.managedDisk.id" \ --output tsv) echo "OS Disk ID: $DISK_ID"
OS Disk ID: /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.Compute/disks/myLinuxVM_OsDisk_1
2. スナップショットを作成する
取得したディスクIDを使い、訓練用スナップショットを作成します。スナップショット名には日付と「dr-drill」を含めると管理しやすくなります。# スナップショット名に日付を含める SNAP_NAME="dr-drill-$(date +%Y%m%d)" az snapshot create \ --resource-group "$RG" \ --name "$SNAP_NAME" \ --source "$DISK_ID" \ --output table
Location Name ProvisioningState ResourceGroup ---------- -------------------- ------------------- --------------- japaneast dr-drill-20261103 Succeeded myResourceGroup
DR訓練の実施手順(OSディスクスワップで復元)
ここではVMを削除せずにOSディスクだけをスワップする方法でDR復旧を再現します。既存VMのリソース(NIC・パブリックIP・NSGルール)がそのまま再利用できるため、本番障害に近いシナリオを再現しやすい手法です。1. 訓練開始時刻を記録する
RTOの計測はUNIXタイムスタンプで行います。変数に格納しておけばスクリプト化しやすくなります。# 訓練開始時刻を記録する DR_START=$(date +%s) echo "DR訓練開始: $(date '+%Y-%m-%d %H:%M:%S')"
2. 障害シナリオを実施する(VM停止)
実際の障害を想定してVMを割り当て解除(deallocate)します。stopコマンドとは異なり、deallocateは課金対象のコンピューティングリソースを解放します。# VMを停止・割り当て解除する(OSディスクスワップに必須) az vm deallocate \ --resource-group "$RG" \ --name "$VM" echo "VM割り当て解除完了: $(date '+%H:%M:%S')"
3. スナップショットから復元ディスクを作成する
訓練用スナップショットのIDを取得し、新しいマネージドディスクを作成します。# スナップショットのリソースIDを取得する SNAP_ID=$(az snapshot show \ --resource-group "$RG" \ --name "$SNAP_NAME" \ --query "id" \ --output tsv) # スナップショットから復元用ディスクを作成する RESTORE_DISK="restore-disk-$(date +%Y%m%d)" az disk create \ --resource-group "$RG" \ --name "$RESTORE_DISK" \ --source "$SNAP_ID" \ --output table echo "復元ディスク作成完了: $(date '+%H:%M:%S')"
4. OSディスクをスワップする
VMのOSディスクを、スナップショットから作成した復元ディスクに差し替えます。# VMのOSディスクをスワップする az vm update \ --resource-group "$RG" \ --name "$VM" \ --os-disk "$RESTORE_DISK" echo "OSディスクスワップ完了: $(date '+%H:%M:%S')"
5. VMを起動して復旧確認する
OSディスクを差し替えたVMを起動します。# VMを起動する az vm start \ --resource-group "$RG" \ --name "$VM" echo "VM起動完了: $(date '+%H:%M:%S')"
6. 復旧完了時刻を記録してRTOを算出する
サービスの正常稼働を確認したら、RTOを算出します。# 復旧完了時刻を記録してRTOを算出する DR_END=$(date +%s) RTO_SEC=$((DR_END - DR_START)) RTO_MIN=$((RTO_SEC / 60)) echo "DR訓練完了: $(date '+%Y-%m-%d %H:%M:%S')" echo "実測RTO: ${RTO_MIN}分${((RTO_SEC % 60))}秒(${RTO_SEC}秒)"
DR訓練完了: 2026-11-03 15:42:18 実測RTO: 24分38秒(1478秒)
RTO計測をスクリプト化する
毎月の定期訓練をスムーズに実施するために、一連の手順をシェルスクリプトにまとめておくと便利です。訓練ログをファイルに残すことで、月次レポートの作成も簡単になります。#!/bin/bash # dr-drill.sh — AzureスナップショットDR訓練スクリプト set -euo pipefail RG="${1:?使い方: $0
}" VM="${2:?使い方: $0 }" SNAP_NAME="dr-drill-$(date +%Y%m%d)" RESTORE_DISK="restore-disk-$(date +%Y%m%d)" LOG_FILE="dr-drill-$(date +%Y%m%d).log" log() { echo "$(date '+%H:%M:%S') $*" | tee -a "$LOG_FILE"; } log "=== DR訓練開始 ===" DR_START=$(date +%s) # OsディスクID取得 log "OSディスクID取得中..." DISK_ID=$(az vm show -g "$RG" -n "$VM" \ --query "storageProfile.osDisk.managedDisk.id" -o tsv) # スナップショット取得 log "スナップショット取得中: $SNAP_NAME" az snapshot create -g "$RG" -n "$SNAP_NAME" --source "$DISK_ID" -o none log "スナップショット取得完了" # VM停止 log "VM停止中: $VM" az vm deallocate -g "$RG" -n "$VM" log "VM割り当て解除完了" # 復元ディスク作成 SNAP_ID=$(az snapshot show -g "$RG" -n "$SNAP_NAME" --query "id" -o tsv) log "復元ディスク作成中: $RESTORE_DISK" az disk create -g "$RG" -n "$RESTORE_DISK" --source "$SNAP_ID" -o none log "復元ディスク作成完了" # OSディスクスワップ log "OSディスクスワップ中..." az vm update -g "$RG" -n "$VM" --os-disk "$RESTORE_DISK" -o none log "OSディスクスワップ完了" # VM起動 log "VM起動中: $VM" az vm start -g "$RG" -n "$VM" log "VM起動完了" # RTO算出 DR_END=$(date +%s) RTO_SEC=$((DR_END - DR_START)) log "=== DR訓練完了 ===" log "実測RTO: $((RTO_SEC / 60))分$((RTO_SEC % 60))秒(合計 ${RTO_SEC}秒)" log "ログ保存先: $LOG_FILE"
# 実行権限を付与して実行する chmod +x dr-drill.sh ./dr-drill.sh myResourceGroup myLinuxVM
set -euo pipefail を先頭に置いているため、いずれかのazコマンドが失敗した時点でスクリプトが停止し、中途半端な状態でRTOが記録されることを防ぎます。DR訓練でよくある問題と対処法
「OSディスクのスワップ後にVMが起動しない」
原因:スナップショット取得後にVMのfstabやcloud-initに変更が入り、スワップ先のディスクと設定が食い違っている場合があります。対処:Azureポータルの「ブート診断」→「シリアルコンソール」でエラーメッセージを確認します。fstabの問題であれば、シリアルコンソールからrootとしてログインして修正できます。
# ブート診断ログを確認するコマンド az vm boot-diagnostics get-boot-log \ --resource-group "$RG" \ --name "$VM" | tail -50
「az disk create に5分以上かかる」
原因:スナップショットのサイズが大きい場合(128GB以上)や、アジアリージョンの混雑時間帯に発生しやすい問題です。対処:ディスク作成完了をポーリングで待機する場合は
az disk wait コマンドを使います。スクリプト化するとタイムアウトを制御しやすくなります。# ディスク作成完了を待機する az disk wait \ --resource-group "$RG" \ --name "$RESTORE_DISK" \ --created
「スナップショットが古くて復元後のデータに差分がある」
原因:最後のスナップショット取得からDR訓練実施まで日数が開いている場合、復元後のデータは古い状態になります。対処:本記事の手順のように、DR訓練の直前に訓練専用スナップショットを取得することで差分を最小限に抑えられます。本番運用では前日夜間スナップショットを使う場合、「前日データまでの復旧を確認する」というRTO目標に変更します。
本記事のまとめ
| 手順 | コマンド | 目安時間 |
|---|---|---|
| OSディスクID取得 | az vm show --query "storageProfile.osDisk.managedDisk.id" |
1分未満 |
| スナップショット取得 | az snapshot create --source <disk-id> |
2~5分 |
| VM割り当て解除 | az vm deallocate |
2~4分 |
| 復元ディスク作成 | az disk create --source <snapshot-id> |
3~10分 |
| OSディスクスワップ | az vm update --os-disk <disk-name> |
1分未満 |
| VM起動 | az vm start |
2~4分 |
| RTO算出 | echo $((DR_END - DR_START)) |
即時 |
・訓練直前にスナップショットを取得:名前に日付と「dr-drill」を含めると管理しやすい
・OSディスクスワップを使う:VM削除不要でNICやパブリックIPを維持したまま復元できる
・RTOはdate +%sで計測:UNIX時刻の差分で秒単位のRTOを算出する
・スクリプト化して月次訓練を定着:ログファイルに記録することで改善履歴が残る
・訓練後は不要リソースを削除:復元ディスクや訓練用スナップショットは訓練後にaz deleteで削除してコストを抑える
スナップショットがあっても、復元手順が機能しなければバックアップの意味がありません。定期的なDR訓練とRTO計測を組み合わせることで、障害時に落ち着いて動ける体制を整えてください。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:Azure可用性を高めるTraffic ManagerをAZ CLIで構築する|AWS Route 53との機能比較
- この記事の属するカテゴリ:Azureへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます