固定タイトルには「無料だし標準機能で十分」とありますが、Windows Server Backupだけで十分なのは限定されたケースです。小規模な単体サーバーやファイルサーバーで、日次程度のRPO、短い保持、手動運用、ローカルの素早い復旧が要件に合い、さらに別筐体・別資格情報・オフサイトまたはイミュータブルなコピーを別手段で確保できる場合には有用です。長期保持、集中監視、ランサムウェア耐性、アプリ固有整合、厳しいRTO/RPOが必要なら標準機能だけでは不足します。
バックアップの成功表示は復元可能性の証明ではありません。別フォルダーへのファイル復元、System State、Windows回復環境からのBare Metal Recoveryを、要件に応じて実際に試します。
十分な場合と不足する場合
Windows Server Backupを中核または補助にできる場合
- 一台または少数サーバーで、担当者が毎日結果と容量を確認できる。
- ファイル/フォルダー、ボリューム、System State、重要ボリュームのBMRが主な復旧対象。
- 日次の固定時刻で足り、世代数をストレージ容量に任せる運用を許容できる。
- 専用ディスクや別共有に加え、別製品または運用でオフサイト/オフライン/イミュータブルコピーを持つ。
- 実機または隔離環境で定期復元し、目標時間内に戻せることを証明できる。
標準機能だけでは不足しやすい場合
- 15分単位など短いRPO、複雑なGFS保持、月次/年次の法定保存、訴訟ホールドが必要。
- 多数サーバーを集中監視し、SLA、レポート、重複排除、帯域制御、セルフサービス復元が必要。
- バックアップ管理者からも削除できないイミュータブル保管、別リージョン、エアギャップが必須。
- Exchange、SQL Server、第三者DB、クラスタ、Hyper-Vの製品固有バックアップとログ管理が必要。
- 同じドメイン管理者資格情報で本番とバックアップ共有の両方を削除でき、ランサムウェア分離ができていない。
先に対象、RPO、RTO、保持、暗号化、オフサイト、復元粒度、アプリ整合、責任者を表にし、一項目でも標準機能で実証できなければ企業向けバックアップ、Azure Backup等を組み合わせます。「追加費用がない」ことと「要件を満たす」ことは別です。
1. Windows Server Backupをインストールする
Windows Server Backupは既定では未導入です。Server Manager→Add roles and features→Role-based or feature-based installation→Features→Windows Server Backupを選びます。PowerShellでは昇格して次を実行し、InstalledがTrueであることを確認します。
Install-WindowsFeature Windows-Server-Backup
Get-WindowsFeature Windows-Server-Backup
機能導入だけでは保護対象、保存先、通知、保持は設定されません。Backup OperatorsまたはAdministratorsの必要な権限でWindows Server Backupコンソールまたは wbadmin を使用し、日常アカウントへ管理者権限を追加しません。
2. 本番と障害領域を分けた保存先を選ぶ
同一サーバーの別ボリュームは誤削除や一部障害には役立っても、筐体全損、管理者侵害、ランサムウェア、災害から分離できません。専用バックアップディスク、別サーバーの共有、オフライン媒体、別拠点/クラウドを組み合わせ、少なくとも本番と別の故障領域、別資格情報を持たせます。
wbadmin enable backup でディスクをターゲットに追加すると、対象ディスクがフォーマットされる場合があります。ディスクIDを wbadmin get disks で確認し、既存データがないことを二者確認します。リモート共有は一度に一つだけ指定でき、同じコンピューターを同じ共有フォルダーへ再度バックアップすると前のバックアップが上書きされます。失敗時に旧版も失う可能性があるため、世代保持が必要なら共有の分離や別製品を設計します。
3. 保護方式を分ける
ファイル/フォルダーとボリューム
業務データを含むボリュームを明示します。Bare Metal用の -allCritical は起動に必要な重要ボリュームを含めますが、別データボリュームの全ファイルを自動的に含む意味ではありません。BMRとデータバックアップを別々に不足なく構成します。
System State
System Stateはレジストリ、ブート、役割依存コンポーネントを保護します。ドメインコントローラーではAD DSとSYSVOL等が対象になりますが、ファイル共有の全データや他ボリュームの業務ファイルを代替しません。DCの復元は単体コマンドだけでなく、複数DC、FSMO、DNS、DSRM、権威/非権威復元を含むフォレスト回復計画に従います。
Bare Metal Recovery
BMRはOSが起動しない全損で、Windows回復環境から重要ボリュームを戻すためのものです。MicrosoftのADフォレスト回復資料はWindows Server BackupでBMRを準備できると説明しています。対象ハードウェア/VMのディスク数と容量、UEFI、ストレージ/NICドライバー、BitLocker回復キー、ネットワーク共有到達を事前に検証します。
4. 最初は単発バックアップで確認する
保存先と対象を確認してから、非機密の試験ファイルを含む単発バックアップを実行します。次の例はF:が専用ターゲット、C:とD:が対象という説明用です。実環境のディスク一覧を確認せずコピー実行しません。
wbadmin get disks
wbadmin start backup -backupTarget:F: -include:C:,D: -allCritical -systemState -vssCopy
-vssCopy は他のバックアップ製品の履歴へ影響させないコピー用途で検討します。アプリの増分/差分履歴をWindows Server Backupが所有する設計なら -vssFull の意味を製品資料と合わせます。二製品が同時にVSS履歴を変更しないよう、ジョブ時間と責任を分離します。
実行中は空き容量、I/O、VSS Writers、イベントログ、アプリ応答を監視します。終了後は wbadmin get versions と wbadmin get items で版と含まれる項目を読み、想定ボリューム、System State、重要ボリューム、データが実際に列挙されることを確認します。
5. スケジュールと保持の限界
GUIのBackup Scheduleまたは wbadmin enable backup は日次の固定時刻を一つ以上設定できます。次は説明用で、対象・時刻・ターゲットを環境に合わせます。
wbadmin enable backup -addtarget:F: -schedule:01:00 -include:C:,D: -allCritical -systemState
Windows Server Backupは企業向け製品のような日次30世代+月次12世代+年次7世代というポリシーベース保持を標準で設計する機能ではありません。専用ディスクでは容量に応じて古い版が整理され、リモート共有では同一フォルダー上書きの制約があります。必要保持期間を「空き容量があるはず」で済ませず、wbadmin get versions で最古/最新、版数、容量増加を毎週確認します。
Last backup、Next backup、結果コード、Windows Backupイベント、VSS、保存先到達、版数を監視し、失敗を通知します。新しいボリュームや共有が追加されたのにジョブへ含まれない構成ドリフトも検知します。標準コンソールだけで多数台のSLA監視ができないなら監視基盤または別製品を選びます。
6. ファイルを実際に別場所へ復元する
本番パスへ直接上書きせず、まず空の隔離フォルダーへ復元します。版IDと項目は読み取り結果から選び、-overwrite:CreateCopy で既存ファイルを保護します。
wbadmin get versions -backupTarget:F:
wbadmin get items -version:MM/DD/YYYY-HH:MM -backupTarget:F:
wbadmin start recovery -version:MM/DD/YYYY-HH:MM -itemType:File -items:D:\Data\RestoreProbe.txt -recoveryTarget:C:\RestoreTest -overwrite:CreateCopy
復元したファイルの内容、ハッシュ、サイズ、更新時刻、ACL、所有者、アプリでの開封を確認し、目標時間を記録します。テスト用コピーにも本番と同じ機密性があるため、アクセス権と廃棄期限を設定します。ファイル復元が成功してもSystem StateやBMRが成功するとは限りません。
7. System StateとBMRの復旧訓練
System Stateは隔離した同等環境で、役割固有の復旧手順と再起動、サービス、イベント、認証を確認します。DCではフォレスト回復計画の一部として訓練します。本番DCへ演習目的でSystem Stateを上書きしません。
BMRはWindows Serverインストールメディア/回復環境から起動し、バックアップディスクまたは共有へ到達して回復点を認識できるところまで定期確認し、隔離VMや予備機で完全復旧を試します。復旧後にOS起動、ボリューム、NIC、BitLocker、役割、DNS、管理、バックアップ再登録を確認します。BMRに含まれないデータボリュームは別のファイル/ボリューム復元が必要です。
オフサイト/イミュータブルの不足を補う
Windows Server Backupのローカル専用ディスクや通常のSMB共有だけでは、同一拠点災害や侵害された管理者による削除に耐えられません。別拠点、オフラインローテーション、イミュータブルなクラウドVault、企業向け製品を追加し、バックアップ削除権限と本番管理権限を分離します。Microsoft Azure BackupにはWindows Serverのファイル/フォルダー/System Stateをクラウドへ保護する選択肢があり、要件・ライセンス・ネットワークを比較できます。
3-2-1はコピー数だけでなく、同じ資格情報や同じ管理面で同時に消されないことが重要です。オフサイトコピーの復元速度と回線、暗号鍵、退職者、Vault削除保護、災害時の認証も試験します。
安全な変更取消とフォールバック
誤った対象や保存先を見つけた場合、既存バックアップを削除して作り直さず、まず新規ジョブを止めます。代替の正常な保護が動いていることを確認した後に wbadmin disable backup でスケジュールを無効化し、保存済み版は保持期限まで読み取り可能な状態で隔離します。正しい対象/ターゲットで単発バックアップと復元試験を通してから新スケジュールを有効化します。
Windows Server BackupがRPO、保持、アプリ整合、監視、オフサイト、イミュータブルのいずれかを満たせない場合は、標準機能を短期ローカル復旧の補助に下げ、Azure Backupまたは要件適合製品へ切り替えます。切替後も旧バックアップを即時消去せず、重複期間に両方から復元し、業務オーナーが新経路を承認してから旧スケジュールと資格情報を廃止します。

コメント