インフラでいうリカバリーとは？初心者向けにリストアとの違いや障害復旧の流れをわかりやすく解説
結論
インフラでいうリカバリー（Recovery）とは、障害やトラブルが発生したシステムを正常な状態へ復旧させる一連の作業を指します。
リストアはバックアップデータを復元する作業ですが、リカバリーは原因調査・修復・リストア・動作確認までを含めた復旧全体を意味します。
リカバリーとは？
リカバリーとは、サーバーやネットワーク、データベースなどに障害が発生した際に、システムを再び正常に利用できる状態へ戻すことです。
例えば、サーバーが故障した場合は、故障した部品の交換だけではなく、OSの復旧やデータのリストア、サービスの起動確認、利用者が正常に利用できることの確認まで行います。
つまり、「システムを元どおりに利用できる状態へ戻す活動全体」がリカバリーです。
どんな場面で使われる？
リカバリーは、あらゆる障害対応で実施されます。
| 障害内容 | リカバリー内容 |
|---|---|
| サーバー障害 | サーバー交換・OS復旧・サービス再開 |
| ファイル削除 | バックアップからリストア |
| データベース障害 | データベース復旧・整合性確認 |
| ランサムウェア感染 | システム初期化・バックアップ復元 |
| 災害発生 | DRサイトへの切り替え・システム復旧 |
なぜ重要なのか
システム障害は完全に防ぐことはできません。
そのため、障害が発生した後にどれだけ早く、安全に復旧できるかが企業の業務継続に大きく影響します。
復旧が遅れると、業務停止や売上減少、顧客からの信頼低下につながる可能性があります。
リカバリーとリストアの違い
| 項目 | リカバリー | リストア |
|---|---|---|
| 意味 | システム全体の復旧 | バックアップデータの復元 |
| 対象 | サーバー・OS・アプリ・データなど | データやシステムイメージ |
| 範囲 | 原因調査から動作確認まで | 復元作業のみ |
リストアは、リカバリーを実施する際の作業の1つです。
リカバリーの流れ
- 障害を検知する
- 影響範囲を確認する
- 原因を調査する
- 必要に応じてバックアップからリストアする
- サービスを起動する
- 動作確認を行う
- 利用者へ復旧を案内する
単にデータを戻すだけではなく、システム全体が正常に動作していることを確認して初めてリカバリー完了となります。
実際のIT現場での利用例
Windows Server
Windows Server Backupを利用してシステムを復元し、Active Directoryや共有フォルダーが正常に動作することを確認します。
仮想化環境
VMwareやHyper-Vでは、仮想マシンをバックアップからリストアし、ネットワークやアプリケーションの動作確認まで実施します。
クラウド環境
AWSやAzureでは、スナップショットやバックアップからインスタンスを復元し、必要に応じて別リージョンや別アベイラビリティゾーンへ切り替えます。
業務でよくあるトラブル例
リカバリー後もシステムが正常に動作しない
主な原因
- 設定ファイルが復元されていない
- サービスが起動していない
- ネットワーク設定が異なる
- データベースの整合性が取れていない
復旧に時間がかかる
主な原因
- バックアップ容量が大きい
- 復旧手順が整備されていない
- 障害原因が特定できていない
- リストア後の確認作業が多い
障害発生時の確認する順番
- 利用者への影響範囲を確認する
- 障害原因を調査する
- リカバリー方法を決定する
- バックアップの状態を確認する
- リストアや修復作業を実施する
- サービスの動作確認を行う
- 利用者への復旧確認を実施する
障害対応では、慌てて復元作業を始めるのではなく、原因や影響範囲を確認してから対応することが重要です。
GUIでの確認方法
Windows環境では、次のツールを利用します。
- Windows Server Backup
- サーバーマネージャー
- イベントビューアー
- サービス管理ツール
- フェールオーバークラスターマネージャー
復旧後は、エラーログやサービス状態も必ず確認しましょう。
CUI（コマンド）での確認方法
Windowsでは、次のようなコマンドが利用されます。
- wbadmin（バックアップ・リストア）
- Get-Service（サービス状態確認）
- Get-WinEvent（イベントログ確認）
- systeminfo（システム情報確認）
- ping（通信確認）
Linuxでは、systemctl、journalctl、tar、rsyncなどを利用して復旧や状態確認を行います。
確認結果の見方
- サービスが正常に起動しているか
- 利用者が正常にログインできるか
- イベントログに重大なエラーがないか
- データが正常に復元されているか
- ネットワーク通信に問題がないか
原因の切り分け
| 確認項目 | 確認内容 |
|---|---|
| サーバー | OSやハードウェアに異常はないか |
| ストレージ | ディスク障害や容量不足はないか |
| ネットワーク | 通信やDNS設定は正常か |
| アプリケーション | サービスは正常起動しているか |
| バックアップ | 正常なバックアップから復元できているか |
初心者がやりがちなミス
- リストアだけで復旧完了だと思う
- 原因を調査せず復元する
- 復旧後の動作確認を行わない
- イベントログを確認しない
- 利用者への確認を忘れる
上司へ報告するポイント
- 障害発生日時
- 障害原因
- 影響範囲
- 実施したリカバリー内容
- 復旧完了時刻
- 動作確認結果
- 再発防止策
エスカレーションするタイミング
- リカバリー方法が判断できない
- バックアップから復元できない
- データ損失の可能性がある
- 復旧後もサービスが正常に動作しない
- 障害原因が特定できない
応用知識
企業では、障害発生時の対応を標準化するために「障害対応手順書」や「ディザスタリカバリープラン（DR計画）」を整備していることが一般的です。また、復旧時間の目標であるRTO（Recovery Time Objective）と、どの時点までデータを戻せればよいかを示すRPO（Recovery Point Objective）を定めることで、迅速かつ適切なリカバリーを実現しています。
関連するIT用語
- リストア
- バックアップ
- フェールオーバー
- ディザスタリカバリー（DR）
- 可用性
- 耐障害性
- RTO（目標復旧時間）
- RPO（目標復旧時点）
- BCP（事業継続計画）
よくある質問（FAQ）
リカバリーとは簡単に言うと何ですか？
障害が発生したシステムを、再び正常に利用できる状態へ戻すための一連の復旧作業です。
リストアとの違いは何ですか？
リストアはバックアップデータを復元する作業です。一方、リカバリーは原因調査、修復、リストア、動作確認までを含めた復旧全体を意味します。
リカバリーではバックアップが必ず必要ですか？
障害内容によります。設定ミスの修正やサービスの再起動だけで復旧できる場合もありますが、データ消失やシステム破損が発生した場合は、バックアップからのリストアが必要になることがあります。
リカバリーを早く行うためには何が重要ですか？
最新のバックアップ取得、復旧手順書の整備、定期的なリストアテスト、監視体制の構築、そしてRTO・RPOを意識した運用が重要です。
まとめ
リカバリーとは、障害が発生したシステムを正常な状態へ復旧させる一連の作業です。データの復元だけではなく、原因調査やシステム修復、サービス再開、動作確認まで含めて実施します。
また、「バックアップはデータを保存する」「リストアはバックアップからデータを復元する」「リカバリーはシステム全体を正常な状態へ戻す」という違いを理解しておくことが重要です。IT現場では、迅速なリカバリーを実現するために、バックアップ運用やリストアテスト、障害対応手順の整備を日頃から行っています。