物理サーバーの Windows Server 2008 R2 を 2012 R2 へインプレースアップグレードする際、最大の不安は「失敗したら元に戻せるか」です。VM のようなスナップショットが使えない環境でも、Windows Server Backup（WSB）でベアメタル回復を含む完全バックアップを取っておけば、アップグレード前の 2008 R2 へ復元できます。本記事では“戻せるバックアップ”の条件と、実務でハマりやすい注意点までまとめます。
結論：WSBで「ベアメタル回復（Bare Metal Recovery）」を含む完全バックアップを取っておけば、失敗時に 2008 R2 へ復元できる
Windows Server Backup（WSB）は、サーバー全体（全ボリューム）やシステム状態などをバックアップでき、災害時には Windows 回復環境（Windows RE）から「システム イメージ回復（System Image Recovery）」を使って OS ごと復元できます。つまり、アップグレード後に起動不能になっても、アップグレード前に取得した“ベアメタル回復を含むバックアップ”があれば、2008 R2 の状態へ戻すことが可能です。
ここで重要なのは、一般に言う「ロールバック（元に戻す）」を、Windows セットアップの自動巻き戻し機能に期待しないことです。現場で“確実に戻せる”手段としては、バックアップからの復元（＝バックアップ取得時点の状態に戻す）が最も強い保険になります。
そもそも、物理サーバーのインプレースアップグレードが怖い理由
Windows Server 2008 R2 → 2012 R2 のインプレースアップグレードは「できるケースがある」一方で、失敗したときの影響が大きい作業です。特に物理サーバーでは、仮想環境のようなスナップショットで即時に戻すことができません。
- OSが起動しなくなる（ブート領域・ドライバー・サービスの不整合）
- 役割/アプリが動かない（IIS、ファイル共有、RDS、独自アプリ、バックアップエージェントなど）
- 復旧が長時間化（夜間作業でも朝までに復旧できない）
- 後戻りができない状態に陥る（途中まで進んだ OS をどうにもできない）
このリスクを現実的に下げる方法が、「アップグレード前に“サーバー丸ごと戻せるバックアップ”を用意しておく」ことです。
「戻せるバックアップ」の条件：WSBで何を取ればいいのか
WSB で “元の 2008 R2 へ戻す” には、最低限 ベアメタル回復に使えるバックアップ（＝OS の状態を含む、クリティカル ボリュームを含んだバックアップ）が必要です。WSB は「サーバー全体」や「ベアメタル回復」用のバックアップを作成でき、災害時には Windows RE から完全復元できます。
コマンドで実施する場合は、-allCritical を指定すると「OS の状態を含むクリティカル ボリューム」を含めたバックアップになり、ベアメタル回復向けのバックアップを作る用途で有効です。
| バックアップの種類（考え方） | 含まれるもの（目安） | 「アップグレード失敗時にOSごと戻す」用途 | コメント（実務目線） |
|---|---|---|---|
| サーバー全体（フル） | 全ボリューム（OS領域＋データ領域） | 最も安心 | 時間/容量は増えるが、戻し作業が単純になりやすい |
| ベアメタル回復（クリティカル ボリューム） | OS の状態を含む “必要最低限の領域” | 可能 | OS復旧を最短で狙うときに有効。データ領域は別で確保する判断もあり |
| システム状態のみ | レジストリやブート関連など（構成情報中心） | 不足しがち | 「OS丸ごと戻す」には不十分になりやすい（用途を誤解しやすい） |
| ファイル/フォルダのみ | 指定したファイル/フォルダ | 不可 | データ保全には使えるが、OS復元の保険にはならない |
結論として、アップグレード前の“保険”としては、「サーバー全体」または「ベアメタル回復（クリティカル ボリューム）」が含まれるバックアップを選びましょう。
インプレースアップグレードの前提：2008 R2 → 2012 R2 で押さえるべき条件
バックアップ以前に、インプレースアップグレードにはエディションや前提条件があります。Windows Server 2012 R2 へのアップグレードでは、Windows Server 2008 R2 は SP1 が前提で、アップグレードできる先のエディションにもマッピングがあります。また、言語を跨いだインプレースアップグレードはサポートされません。
| 2008 R2 側（開始点） | 2012 R2 側（アップグレード先） | 実務メモ |
|---|---|---|
| Windows Server 2008 R2 Standard（SP1） | Windows Server 2012 R2 Standard / Datacenter | ライセンスや媒体（評価版など）で引っかかる事例があるため事前確認推奨 |
| Windows Server 2008 R2 Enterprise（SP1） | Windows Server 2012 R2 Standard / Datacenter | 移行先のエディションを決めてから作業設計 |
| Windows Server 2008 R2 Datacenter（SP1） | Windows Server 2012 R2 Datacenter | 同等以上への移行が基本 |
| Windows Web Server 2008 R2（SP1） | Windows Server 2012 R2 Standard | 用途がWeb特化の場合、役割・IIS移行も含めて検討 |
さらに、サポートされるアップグレードパスでも一般的なガイドラインとして、言語を跨ぐアップグレード不可などの制約があります。これを見落とすと、アップグレード途中で止まりやすいポイントになります。
バックアップ先の選び方：外付けHDDとネットワーク共有、どっちが良い？
WSB のバックアップ先は大きく「外付けディスク」と「ネットワーク共有（NAS / ファイルサーバーの共有）」が現実的です。結論から言うと、運用・保全のしやすさは ネットワーク共有が強いことが多いですが、共有先には“上書き”の落とし穴があります。
| 保存先 | メリット | デメリット | アップグレード前バックアップとしてのおすすめ |
|---|---|---|---|
| 外付けHDD/SSD（USB等） | ネットワーク不要で復元できる／速度が出やすい | 接続ミス・認識不良・ケーブル問題が起きる／物理管理が必要 | 強い（“当日その場で確実に接続できる”運用ができるなら） |
| ネットワーク共有（\\server\share） | 保管が楽／機器持ち運び不要／共有側で冗長化できる | 同一フォルダへ取り続けると上書きされる／復元時にNICドライバーが必要な場合あり | 強い（ただし “上書き対策” を必ず入れる） |
WSB は、同じリモート共有フォルダへ同じサーバーのバックアップを取り続けると、以前のバックアップを上書きする動作になります。さらに、バックアップが失敗した場合「古いバックアップは上書き済みだが、新しいバックアップは壊れていて使えない」という最悪の状態も起こり得ます。対策として、共有側で サブフォルダを分けて管理する方法が推奨されます（ただし容量は余裕を見て確保が必要）。
実務での落としどころとしては、アップグレード前の“一発勝負の保険”なら、次のどちらかが堅いです。
- 外付けディスクへ 1 世代のフルバックアップ（作業当日に確実に接続できるよう保管）
- ネットワーク共有へ取得したあと、共有側でフォルダごと別名コピーして “アップグレード前世代” を固定保存
アップグレード前にやっておくべき準備チェックリスト
「バックアップを取ったつもりでも戻せない」を避けるには、復元の実行環境まで含めて準備しておく必要があります。特に物理サーバーは RAID/NIC まわりがボトルネックになりやすいです。
| カテゴリ | チェック内容 | 理由 |
|---|---|---|
| 回復手段 | Windows Server 2008 R2 のインストールメディア（または回復メディア）を用意 | Windows RE で「システム イメージ回復」を起動するため |
| ドライバー | RAID/ストレージ、NIC のドライバー（inf形式）をUSB等に保存 | 回復環境でディスクやネットワーク共有が見えないと復元できない |
| バックアップの健全性 | バックアップ完了ログを確認／バックアップが参照できることを確認 | “取れた”ではなく“読める”ことが重要 |
| 保存先の到達性 | 外付けディスクの認識、共有パスへのアクセス（資格情報含む） | 復元時に同じ経路で参照できないと詰む |
| 時間 | バックアップ/復元の所要時間を見積もる（容量・I/O） | 復旧が朝に間に合わないリスクを減らす |
| 作業設計 | アップグレード手順の手順書化、戻し手順の手順書化 | トラブル時ほど手順が必要（判断ミスを減らす） |
WSB は Windows 回復環境（Windows RE）と組み合わせて、OS やサーバー全体を復元できます。回復環境側に入れれば、「システム イメージ回復」やコマンドプロンプトなどが利用できます。
手順：Windows Server 2008 R2 に WSB を入れて完全バックアップを取得する
WSB（Windows Server Backup）機能のインストール
- サーバー マネージャーを開く
- 「機能の追加」から Windows Server バックアップ を追加
- インストール後、管理ツールに「Windows Server バックアップ」が追加されることを確認
GUIで「サーバー全体」または「ベアメタル回復」を含むバックアップを作る
- 「Windows Server バックアップ」を起動
- 右ペインから「バックアップ 1 回（Backup Once）」または「バックアップ スケジュール（Schedule Backup）」を選択
- バックアップの構成で、可能なら 「サーバー全体」 を選択（容量と時間は増えるが戻しが簡単）
- 保存先を選択（外付けディスク or リモート共有）
- 実行し、完了ステータスとイベントログを確認
アップグレード前の保険としては、スケジュールよりも「バックアップ 1 回」で直前に取得しておく運用が分かりやすいです（もちろん、日常運用としてはスケジュールバックアップも有効です）。
コマンドで一発取得する（wbadmin）
GUIが使いづらい環境や、作業手順を固定化したい場合は wbadmin が便利です。ベアメタル回復に使えるバックアップを作るなら、-allCritical がポイントになります。
外付けディスク（例：F:）へクリティカル ボリュームをバックアップ
wbadmin start backup -backupTarget:F: -allCritical -quietネットワーク共有へバックアップ（例：\\NAS\WSB）
wbadmin start backup -backupTarget:\\NAS\WSB -allCritical -user:DOMAIN\backupuser -password:******** -quietネットワーク共有先に保存する場合、同一共有・同一フォルダで繰り返すと上書きになる点には注意してください。必要なら日付フォルダを切る、作業直後にコピーして保全するなど、“アップグレード前世代を固定で残す”運用を必ず入れましょう。
復元手順：アップグレードに失敗したら、バックアップから 2008 R2 に戻す
アップグレードが失敗して OS が起動しない場合でも、WSB のバックアップがあれば Windows 回復環境から復元できます。WSB で作成したバックアップは、災害時に Windows RE の「システム イメージ回復」で OS/サーバー全体を復元できます。
復元の基本フロー（GUI：システム イメージ回復）
- Windows Server 2008 R2 のインストールメディアで起動する（または回復環境で起動）
- 「コンピューターを修復する（Repair your computer）」を選ぶ
- 「システム イメージ回復（System Image Recovery）」を選ぶ
- バックアップの保存場所を指定する（外付けディスク、またはネットワーク）
- 対象のバックアップ（アップグレード前に取得した日時）を選択して復元を実行
注意点として、ベアメタル回復はディスク構成を作り直して復元する動きになるため、対象ディスクのデータは基本的に置き換わります。復元対象・ディスク選択は慎重に行ってください。
コマンドで復元する（wbadmin start sysrecovery）
回復環境のコマンドプロンプトから実行する方法です。wbadmin start sysrecovery は Windows 回復コンソール（Windows RE）から実行する必要がある点がポイントです。
バックアップのバージョン（日時）を確認
wbadmin get versions -backupTarget:\\NAS\WSB復元（例）
wbadmin start sysrecovery -version:MM/DD/YYYY-HH:MM -backupTarget:\\NAS\WSB -machine:SERVERNAME -quietまた、sysrecovery では、指定しない場合はクリティカル ボリュームのみが復元対象になり、必要に応じて全ボリューム復元（restoreAllVolumes）などの指定も検討します。
復元で詰まりやすいポイントと対策
| 症状 | 原因の例 | 対策 |
|---|---|---|
| 回復環境でディスクが見えない | RAID/ストレージドライバーがない | RAID ドライバー（inf）を USB 等で用意し、回復環境で読み込む |
| ネットワーク共有が見えない/接続できない | NIC ドライバーがない、認証情報が不足 | NIC ドライバーを用意／共有アクセス手順と資格情報を事前に確認 |
| バックアップが見つからない | 保存先のフォルダ構造が変わった、上書きされて消えた | アップグレード前世代は別フォルダへコピーし固定保存。上書きリスクを前提に運用する |
| 復元先ディスクが小さくて失敗 | 交換ディスクの容量不足 | 同容量以上のディスクを用意。特にシステム領域は余裕を持つ |
| 復元後に起動するが不安定 | ハードウェア差分、ファームウェア/ドライバー差 | 可能なら同一構成で復元。異なる機器で戻す可能性があるなら事前テストを推奨 |
「戻せる」を確実にするためのテストと、当日の運用のコツ
バックアップは “取った” だけでは不十分で、いざという時に戻せることが重要です。理想は検証機（同一機種、同一 RAID 構成）で実際に復元を一度通すことですが、難しい場合でも次の最低限はやっておくと成功率が上がります。
- 回復環境まで起動できることを事前に確認（BIOS/UEFI、起動順、メディア起動）
- 回復環境から保存先が見えることを確認（外付けの認識、共有への到達）
- 必要なドライバー（RAID/NIC）を USB にまとめ、手順書に添付
- 復元に要する時間（目安）を把握し、メンテナンス時間を現実的に確保
特にネットワーク共有に保存する場合、上書き仕様を理解したうえで「アップグレード前の世代は固定保存」を徹底してください。リモート共有は同一フォルダで上書きされるため、失敗時にバックアップが消えるリスクをゼロにする設計が必要です。
よくある質問
Q：WSBのフルバックアップがあれば、アップグレード失敗後でも本当に 2008 R2 に戻せますか？
A：はい。アップグレード前に取得したバックアップを使って、Windows 回復環境から「システム イメージ回復」を実行すれば、バックアップ取得時点の OS（2008 R2）へ戻せます。WSB はフル サーバー/ベアメタル回復用のバックアップと Windows RE を使って完全復元できる旨が示されています。
Q：ネットワーク共有にバックアップを取れば安心ですか？
A：運用面では便利ですが、同じ共有フォルダへ取り続けると上書きされます。さらに失敗時にバックアップが消えるリスクもあるため、共有上でフォルダを分ける・取得直後に別フォルダへコピーするなど、世代固定の運用が必要です。
Q：ベアメタル回復は、どの範囲まで戻りますか？データ領域も戻せますか？
A：ベアメタル回復は“OSが起動しない状況でもサーバーを動く状態に戻す”ための復旧手段です。コマンド復元では、既定ではクリティカル ボリュームが対象になり、必要に応じて全ボリュームを復元する指定もあります。運用としては「OS復旧」と「データ復旧」をどう分けるか（フルで丸ごと戻すか、データは別系統で守るか）を事前に決めるのが安全です。
Q：インプレースアップグレードはそもそも推奨ですか？
A：一般論としては、新サーバーへ移行（クリーンインストール＋役割/データ移行）のほうがトラブル切り分けや巻き戻しが容易で推奨されやすいです。ただし、制約（ハードウェアやアプリの事情、時間、予算）でインプレースアップグレードを選ぶケースもあります。その場合は、今回のように「戻せるバックアップ」を確実に作ることが最低条件になります。
まとめ：物理サーバーのアップグレードで後悔しないために
Windows Server 2008 R2 → 2012 R2 のインプレースアップグレードは、物理サーバーだと“戻す手段”が弱くなりがちです。しかし、Windows Server Backup（WSB）で ベアメタル回復を含む完全バックアップ（サーバー全体、または -allCritical を含むバックアップ）をアップグレード前に取得し、回復環境での復元手順まで準備しておけば、失敗時に 2008 R2 の状態へ復元できます。
特に、ネットワーク共有へのバックアップは上書き仕様を必ず理解し、アップグレード前の世代を固定保存する運用にしてください。バックアップは「取った」ではなく「戻せる」ことが価値です。その一点だけは、作業当日までに必ず固めておきましょう。
コメント