Windows Serverを運用していると、「バックアップは毎日取った方がいいのか？」「何世代残せばいいのか？」と迷うことがあります。
結論からいうと、すべてのWindows Serverで「1日1回」が正解というわけではありません。
重要なのは、障害が発生したときに「どの時点まで戻れればよいのか」「最大でどれくらいのデータ消失を許容できるのか」を考えてバックアップ頻度を決めることです。
Windows Serverのバックアップは毎日必要？
例えば、ほとんどデータが変更されない検証サーバーと、利用者が毎日ファイルを保存するファイルサーバーでは、必要なバックアップ頻度は違います。
毎日大量にデータが更新されるサーバーなら、1日1回でも十分ではない場合があります。
逆に変更がほとんどないサーバーなら、業務要件によっては毎日バックアップする必要性が低い場合もあります。
つまり、バックアップ頻度はサーバーの役割とデータの重要度から考えます。
「何日分失っても大丈夫か」で考える
バックアップ頻度を決めるときに分かりやすい考え方が、どこまでデータを失っても業務上許容できるかです。
例えば毎日午前0時にバックアップしているサーバーが、その日の23時に故障したとします。
バックアップから復元すると、最大で約23時間分の変更を失う可能性があります。
0:00 バックアップ
↓
日中にファイルを更新
↓
23:00 サーバー障害
↓
0:00時点へ復元
↓
日中の変更が失われる可能性「1日分失っても問題ない」のであれば日次バックアップが候補になります。
しかし「1時間分でも失うと困る」システムなら、1日1回では要件を満たせません。
RPOとRTOを考える
バックアップ設計では、RPOとRTOという考え方があります。
RPO（Recovery Point Objective）は、障害時にどの程度過去のデータまで戻ることを許容できるかという目標です。
RTO（Recovery Time Objective）は、障害発生からどのくらいの時間でサービスを復旧させる必要があるかという目標です。
例えば、
- RPO：24時間 → 1日分程度のデータ消失を許容
- RPO：1時間 → 最大1時間程度までに抑えたい
- RTO：4時間 → 4時間以内のサービス復旧を目指す
という考え方です。
バックアップ頻度だけでなく、実際に復元する時間まで考えておく必要があります。
Windows Server Backupは1日に複数回設定できる
Windows Server Backupでは、wbadmin enable backup を使ってスケジュールバックアップを構成できます。
例えば午前9時と午後6時にバックアップする場合は、Microsoftのコマンド例と同様に複数の時刻を指定できます。
wbadmin enable backup -addtarget:<BackupTarget> -schedule:09:00,18:00 -include:E:つまり、Windows Server Backupは「1日1回しかバックアップできない」という仕組みではありません。
データの重要度に応じてバックアップ時刻を検討できます。
サーバーの役割によって考え方が変わる
同じWindows Serverでも、役割によってバックアップ対象や頻度の考え方が変わります。
ファイルサーバー
利用者が日中にファイルを作成・更新するため、変更頻度が高いサーバーです。
誤削除や上書きも考慮して、必要な時点へ戻れるよう複数世代を保持することが重要です。
Active Directoryドメインコントローラー
ドメインコントローラーでは、単なるファイルコピーだけではなくSystem Stateのバックアップも重要です。
MicrosoftのActive Directoryフォレスト回復手順でも、DCのSystem StateをWindows Server Backupまたはwbadmin.exeでバックアップする方法が案内されています。
System StateにはActive Directoryデータなど、障害復旧に必要な情報が含まれます。
Web・アプリケーションサーバー
Webコンテンツや設定が別のリポジトリなどで管理されている場合と、サーバー内に重要なデータを保持している場合では必要なバックアップが異なります。
「OSを再構築すれば済むのか」「サーバー内にしか存在しないデータがあるのか」を確認します。
データベースサーバー
データベースでは、Windows Server Backupだけでなく、利用しているデータベース製品のバックアップ・復旧方式も考慮します。
データベースの整合性やトランザクションログなど、製品固有の復旧要件があるためです。
バックアップは複数世代残す
最新のバックアップが1つあれば十分とは限りません。
例えば、ファイルを誤って削除したことに1週間後に気付いた場合を考えます。
最新バックアップしか残っておらず、そのバックアップにも削除後の状態しか記録されていなければ、目的のファイルを復元できません。
そのため、
- 最新
- 1日前
- 数日前
- 1週間前
- 1か月前
など、要件に応じて複数の復元ポイントを保持します。
何世代残せばいい？
世代数にも、すべてのWindows Serverに共通する正解はありません。
例えば日次バックアップを7世代残せば、おおむね1週間程度の範囲から選べます。
30世代なら、日次バックアップという前提ではより長い期間をカバーできます。
ただしバックアップ容量、データ変更量、保存期間、業務要件によって必要なストレージ容量も変わります。
単純に「何世代」という数だけではなく、何日前の状態まで復元できる必要があるかから考えるのがおすすめです。
現在残っているバックアップを確認する
Windows Server Backupで利用可能なバックアップは、次のコマンドで確認できます。
wbadmin get versionsバックアップ時刻、保存場所、バージョン識別子、実行できる回復の種類などを確認できます。
詳しい見方については、以下の記事で解説しています。
▶ wbadmin get versionsでWindows Serverバックアップの世代を確認する方法
「バックアップが成功した」だけでは不十分
バックアップジョブが毎日「成功」と表示されていても、それだけで障害対策が完成したとは言えません。
重要なのは、必要になったときに実際に復元できることです。
定期的に、
- バックアップ世代が存在するか
- 必要なファイルが含まれているか
- 復元操作ができるか
- 別サーバーや検証環境で復旧できるか
などを確認しておくと安心です。
削除したファイルを本当に復元できる？
Windows Server Backupから削除ファイルを復元するときには、注意点があります。
「バックアップを取っているから、いつでも削除ファイルを戻せる」とは限りません。
必要なファイルが存在していた時点のバックアップ世代が残っている必要があります。
実際の復元手順や、バックアップがあるのに復元できないケースについては以下の記事で解説しています。
▶ Windows Serverで削除したファイルをバックアップから復元する方法
バックアップ先を同じサーバーだけにしない
バックアップデータが元サーバーと同じストレージにしか存在しない場合、ストレージ障害やサーバー全体の故障によってバックアップまで失う可能性があります。
また、ランサムウェアや誤操作などを考えると、バックアップデータそのものが影響を受けない構成も重要です。
バックアップ先、別媒体、別サーバー、オフサイトやクラウドなど、障害シナリオに応じた保管方法を検討します。
おすすめの考え方
Windows Serverのバックアップ頻度を決めるときは、次の順番で考えると分かりやすいでしょう。
- 失って困るデータを確認する
- 最大何時間・何日分までデータ消失を許容できるか決める
- 必要なバックアップ頻度を決める
- 何日前まで戻る必要があるか決める
- 必要な世代数と容量を決める
- バックアップを実行する
- 定期的に復元テストを行う
バックアップを取ることそのものではなく、障害時に必要な状態へ復旧できることを目的にします。
まとめ
Windows Serverのバックアップは、すべてのサーバーで「毎日1回」が正解というわけではありません。
更新頻度が高く重要なデータを扱うサーバーなら、1日1回では足りない場合もあります。
逆に変更頻度が低いサーバーでは、業務要件に合わせて頻度を決めることができます。
また、バックアップ頻度だけでなく、複数世代を保持して過去の状態へ戻れるようにすることも重要です。
「毎日バックアップしているから安心」ではなく、「いつの状態まで戻れるのか」「実際に復元できるのか」まで確認することがWindows Serverのバックアップ運用では重要です。
コメント