災害復旧技術とは、バックアップシステム、複製されたインフラ、待機環境、復旧手順、監視ツール、運用計画を組み合わせ、重大な障害後に業務サービスを復旧するための仕組みです。ハードウェア故障、データ破損、ランサムウェア、火災、洪水、停電、クラウドサービス停止、ネットワーク障害、誤削除、拠点全体の停止などから組織を回復させます。

目的は単に「データを保存する」ことではありません。完全な復旧設計では、アプリケーション、データベース、サーバー、IDシステム、通信プラットフォーム、ネットワーク経路、ユーザーアクセス、セキュリティポリシー、業務フローを利用可能な状態へ戻す必要があります。そのため、災害復旧は技術アーキテクチャであると同時に、事業継続のための管理領域でもあります。

業務影響から始める

信頼できる復旧計画は、どのサービスが本当に重要かを把握するところから始まります。メール、ERP、CRM、顧客ポータル、決済システム、クラウドワークロード、ファイルストレージ、通話プラットフォーム、製造制御システム、病院情報システム、物流プラットフォーム、セキュリティ監視は、それぞれ異なる復旧優先度を持つ場合があります。

すべてのシステムに同じ復旧速度が必要なわけではありません。一般向けの取引システムは数分以内の復旧が必要な一方、アーカイブシステムは数時間の停止を許容できる場合があります。すべてのワークロードを同じ緊急度として扱うと、コストと複雑さが増します。重要なワークロードを軽く扱うと、事業リスクが高まります。

計画では二つの概念がよく使われます。Recovery Time Objective、つまり RTO は、サービスをどれだけ早く復旧すべきかを定義します。Recovery Point Objective、つまり RPO は、許容できるデータ損失量を時間で定義します。たとえば RPO が 15 分であれば、障害発生の 15 分前以内の時点までデータを戻せる必要があります。

技術を支える中核レイヤー

データ保護レイヤー

最初の技術レイヤーはデータを保護します。これには、フルバックアップ、増分バックアップ、差分バックアップ、スナップショット、継続的データ保護、イミュータブルバックアップ、データベースダンプ、オブジェクトストレージのバージョニング、オフサイトレプリケーションなどが含まれます。

優れたデータ保護では、複数の復元ポイントを用意する必要があります。最新のバックアップに破損データや暗号化されたデータが含まれている場合、より古いクリーンなバージョンから復旧しなければならないことがあります。これはランサムウェアや誤削除の際に特に重要です。

コンピュート復旧レイヤー

データだけでは不十分です。アプリケーションには、サーバー、仮想マシン、コンテナ、OS、ランタイム環境、ミドルウェア、ライセンス、設定ファイルが必要です。コンピュートレイヤーは、主環境が停止した後にワークロードをどこで実行するかを定義します。

復旧用のコンピュート環境は、別のデータセンター、クラウドリージョン、待機クラスター、仮想化基盤、またはマネージド復旧環境に用意できます。環境の準備が進んでいるほど、復旧は速くなります。

ネットワーク継続レイヤー

システムが復旧した後、ユーザーや他のシステムがそこへ到達できなければなりません。そのためには、ネットワーク経路、DNS 更新、VPN アクセス、ファイアウォールルール、ロードバランサー、IP アドレス設計、証明書、NAT ポリシー、安全なリモートアクセスが必要です。

ネットワーク復旧は軽視されがちです。アプリケーションが復旧サイトで稼働していても、DNS レコード、ルーティングテーブル、ID 経路、ファイアウォールルールが更新されていなければ、ユーザーはアクセスできません。

IDとアクセスレイヤー

障害後も、ユーザー、管理者、アプリケーション、サービスアカウントには認証と認可が必要です。ID サービスが利用できない場合、多くの復旧済みアプリケーションはまだ使用できません。

ディレクトリサービス、MFA システム、認証局、特権アクセスツール、パスワード保管庫、SSO プラットフォームは復旧計画に含めるべきです。機能する ID 制御がない復旧サイトは、セキュリティと運用の問題になり得ます。

運用オーケストレーションレイヤー

復旧では正しい順序で作業する必要があります。データベースはアプリケーションより先に起動する必要があるかもしれません。ユーザー接続の前にネットワークルールを変更する必要がある場合もあります。サービス実行前にはストレージをマウントし、監視で復旧後のシステムが正常であることを確認します。

オーケストレーションツールはこれらの手順を自動化します。ワークロードの起動、スクリプト適用、設定更新、フェイルオーバー実行、依存関係検証、復旧レポート作成を行えます。自動化は、緊張したインシデント対応中の人的ミスを減らします。

復旧プロセスの一般的な流れ

検知とインシデント確認

プロセスは、監視ツール、ユーザー、管理者、セキュリティシステムが異常を検知したときに始まります。サーバー障害、データベースエラー、ストレージ停止、ランサムウェア警告、アプリケーション停止、拠点停電、クラウドリージョン障害などが該当します。

チームは、その事象が完全復旧、部分復元、ローカル修復のどれを必要とするかを確認します。すべての障害で完全なフェイルオーバーを行うべきではありません。小さなアプリケーション問題は、二次環境を起動するより早く解決できる場合があります。

判断と起動

インシデントが確認されると、権限を持つ担当者が復旧計画を起動するかを判断します。判断は、業務影響、想定停止時間、安全リスク、顧客影響、データ整合性、主サイトを短時間で復旧できるかに基づくべきです。

明確な意思決定権限は重要です。誰がフェイルオーバーを承認できるのか不明な場合、重大インシデント中に貴重な時間を失います。

データ復元またはレプリケーション切替

復旧環境には利用可能なデータが必要です。設計がバックアップを使う場合、チームは選択した復元ポイントからデータを戻します。レプリケーションを使う場合、待機コピーをアクティブ用途へ昇格させることがあります。

データの選択は非常に重要です。破損やマルウェアが最新コピーに到達している場合、最新コピーを復元することが正しいとは限りません。最後のクリーンな復旧ポイントを特定する必要があります。

サービス再起動と依存順序

アプリケーションは依存関係に従って再起動されます。データベース、ストレージ、ID サービス、ミドルウェア、アプリケーションサーバー、Web フロントエンド、API、連携システムには決められた順序が必要な場合があります。

依存順序を無視すると、原因が分かりにくい障害が発生します。復旧済みアプリケーションが壊れて見えても、実際にはデータベース、ライセンスサーバー、メッセージキュー、DNS レコードが未準備なだけかもしれません。

引き渡し前の検証

ユーザーがサービスに戻る前に、チームは復旧環境が動作することを検証する必要があります。ログインテスト、データ整合性チェック、取引テスト、通話テスト、API チェック、レポート生成、セキュリティ確認、監視確認などが含まれます。

検証後にのみ、復旧環境を本番サービスとして扱うべきです。速くても検証されていない復旧は、データ損失、セキュリティギャップ、ユーザー混乱を生む可能性があります。

災害復旧は、単一のバックアップ作業ではなく、データ、システム、ネットワーク、ID、ユーザー、業務プロセスを連携して再起動するものとして扱うと最も効果を発揮します。

主なアーキテクチャモデル

バックアップとリストア

最も単純なモデルは、バックアップを保管し、必要時に復元する方式です。通常は低コストですが、サーバー、アプリケーション、データ、設定を手動で再構築または復元する必要があるため遅くなります。

このモデルは、非重要システム、小規模企業、アーカイブワークロード、長めの停止を許容できるアプリケーションに適しています。それでも、未検証のバックアップは実際の復旧で失敗する可能性があるため、テストは必要です。

パイロットライト環境

パイロットライト設計では、最小限の復旧環境を稼働させ続けます。データベース、ネットワーク基盤、ID サービス、設定テンプレートなどの中核要素は既に存在し、アプリケーションサーバーは復旧時だけ拡張します。

この方法はコストと速度のバランスを取ります。すべてをゼロから構築するより速く、完全な複製環境を常時稼働させるより安価です。

ウォームスタンバイ

ウォームスタンバイ環境では、より多くのシステムを事前に稼働させます。データは定期的にレプリケーションされ、アプリケーションサービスはインストール済みで部分的にアクティブな場合があります。インシデント時には、環境を拡張、昇格、再設定して本番トラフィックを処理します。

停止時間を短縮したいが、完全にアクティブな二次サイトは高すぎる場合に有効なモデルです。

ホットスタンバイまたはアクティブアクティブ

最速の設計では、二次環境を常時同期し、いつでもユーザーにサービス提供できる状態にします。アクティブアクティブ設計では、複数拠点が同時に本番トラフィックを処理し、ロードバランシングと拠点間レプリケーションを利用します。

これらのモデルは停止時間を短縮しますが、慎重な設計が必要です。データ整合性、ネットワークルーティング、スプリットブレイン防止、ライセンス、セキュリティ、監視、運用制御はより複雑になります。

重要な技術機能

自動バックアップスケジュール

自動スケジュールは手動バックアップへの依存を減らします。システムは必要な RPO に応じて、毎時、毎日、毎週、または継続的にバックアップを作成できます。

スケジュールはワークロードの動作に合わせるべきです。毎分変化するデータベースには、静的な文書アーカイブとは異なる保護戦略が必要です。

イミュータブルコピーとオフラインコピー

イミュータブルバックアップは、定められた期間、変更や削除ができません。オフラインコピーやエアギャップコピーは本番環境から分離されます。これらは、ランサムウェア、内部脅威、誤削除、侵害された管理者アカウントへの対策として重要です。

すべてのバックアップを同じ侵害済み環境に保存する復旧計画は、最も必要なときに失敗する可能性があります。

レプリケーションと同期

レプリケーションは、主環境のデータを別の場所へコピーします。書き込みが両側に確定してから完了する同期方式と、変更後しばらくしてコピーされる非同期方式があります。

同期レプリケーションはデータ損失を減らせますが、低遅延リンクが必要で性能に影響する場合があります。非同期レプリケーションは距離に対して柔軟ですが、主サイトが突然停止すると直近の変更を失う可能性があります。

アプリケーション認識型保護

アプリケーション認識型保護は、保護対象のワークロードを理解します。データベース、メールシステム、仮想マシン、ファイルサーバー、企業アプリケーションは、一貫したバックアップのために特別な手順を必要とする場合があります。

たとえば、変更中のデータベースファイルを単純にコピーしても、クリーンな復元ポイントは得られないことがあります。アプリケーション認識型スナップショットやトランザクションログ処理は、復旧品質を高めます。

復旧自動化

自動化は、仮想マシンの起動、ストレージ接続、ネットワークルール更新、スクリプト実行、DNS 調整、サービス検証、インシデント記録作成を行えます。手作業を減らし、復旧を再現しやすくします。

小規模環境では手動復旧が可能な場合もありますが、複雑なシステムでは、圧力下でのミスを減らすため、文書化された自動ワークフローが通常必要です。

さまざまな環境での用途

企業ITシステム

企業は、ERP、CRM、メール、ID システム、ファイル共有、データベース、イントラネット基盤、業務アプリケーションを保護するために復旧技術を使用します。目的は、大きなインシデント後も中核業務を利用可能に保つことです。

これらの環境では、階層化された復旧が必要なことが多くあります。ミッションクリティカルなアプリケーションにはより速い復旧目標を設定し、緊急度の低いシステムには低コストの保護を適用します。

クラウドとハイブリッドインフラ

クラウド環境は、スナップショット、リージョン間レプリケーション、Infrastructure as Code、マネージドデータベース、オブジェクトストレージのバージョニング、自動フェイルオーバーパターンをサポートします。ハイブリッド環境では、オンプレミスのデータセンターとクラウド復旧リソースを組み合わせることがあります。

クラウドベースの復旧は完全な二次データセンターの必要性を減らせますが、ネットワーク計画、セキュリティ設計、コスト管理、定期テストは依然として必要です。

産業および公益事業の運用

工場、発電所、水処理システム、石油・ガス拠点、物流センターでは、制御システム、ヒストリアン、監視サーバー、通信プラットフォーム、オペレーター端末の復旧計画が必要になる場合があります。

これらの環境では、安全、リアルタイムプロセス制御、レガシープロトコル、現場機器アクセス、厳格な変更管理を考慮する必要があります。復旧が危険な運転状態を生んではなりません。

医療と公共サービス

病院、緊急対応センター、政府サービス、公共施設は、障害中でも記録、通信、スケジュール、セキュリティシステム、運用データへアクセスする必要があります。

復旧計画には、プライバシー、監査証跡、患者や市民への影響、緊急手順、異常時のスタッフアクセスを含めるべきです。

通信およびコミュニケーションサービス

通信プラットフォームでは、通話制御、ルーティング、メディアサービス、録音、ボイスメール、SIP トランク、ゲートウェイ、コンタクトセンタープラットフォーム、ユーザー登録データの復旧が必要です。

通信システムは緊急対応や顧客対応を支えることが多いため、復旧テストにはサーバー起動だけでなく、実際の通話フローを含めるべきです。

データ整合性とサイバーセキュリティ

現代の復旧計画では、サイバー攻撃が本番システムだけでなくバックアップも標的にすることを前提にする必要があります。攻撃者はバックアップを削除し、バックアップリポジトリを暗号化し、認証情報を盗み、複製データを破壊する可能性があります。そのため、バックアップの分離、アクセス制御、イミュータビリティ、暗号化、監視が不可欠です。

復旧データは転送中も保存中も保護されるべきです。暗号鍵は慎重に管理する必要があります。鍵を失うと復旧できなくなる場合があるためです。バックアップリポジトリは、通常の本番アカウントと同じ認証情報や権限を使うべきではありません。

復旧後のセキュリティ検証も重要です。バックアップからシステムを戻すと、古いソフトウェア、脆弱な設定、侵害されたアカウントも一緒に戻る可能性があります。ユーザーにサービスを戻す前に、パッチ、認証情報、ファイアウォールルール、エンドポイントセキュリティを確認すべきです。

テストと準備演習

一度もテストされていない復旧計画は、単なる仮定にすぎません。テストは、バックアップが復元可能か、アプリケーションが正しく起動するか、ユーザーがログインできるか、データが一貫しているか、ネットワーク経路が機能するか、担当者が対応を理解しているかを確認します。

テストには複数のレベルがあります。ファイル復元テストは個別データを復旧できるかを確認します。アプリケーション復旧テストは1つのサービスを復旧できるかを確認します。完全シミュレーションは、拠点全体の障害とフェイルオーバープロセスをテストします。

演習は文書化するべきです。チームは復旧時間、発見された問題、不足したアクセス権、失敗したスクリプト、古い文書、是正措置を記録します。各テストは計画の改善につながるべきです。

よくある失敗ポイント

一度も復元していないバックアップ

多くの組織は、バックアップジョブは完了していたのに、データを正しく復元できないことを遅すぎる段階で発見します。破損ファイル、欠落した依存関係、誤った認証情報、未対応バージョン、不完全なアプリケーションデータが原因になり得ます。

復元テストは、バックアップデータが有用であることを証明する唯一の信頼できる方法です。

設定ファイルの欠落

アプリケーションは、設定ファイル、証明書、環境変数、ルーティングテーブル、ファイアウォールルール、ライセンス、サービスアカウントに依存する場合があります。これらが保護されていなければ、データは戻ってもアプリケーションは動作しません。

設定バックアップは復旧範囲の一部として扱う必要があります。

責任範囲が不明確

インシデント中に誰が意思決定するのか不明だと、復旧が遅れます。IT、セキュリティ、運用、事業責任者、クラウドチーム、ベンダーがすべて関与する場合があります。

危機が起きる前に、計画では役割、承認権限、エスカレーション連絡先、コミュニケーションチャネルを定義しておくべきです。

悪いデータのレプリケーション

レプリケーションは有用ですが、破損、削除、暗号化されたファイルを二次サイトへコピーしてしまうことがあります。そのため、レプリケーションがあっても、ポイントインタイム復旧とイミュータブルバックアップは重要です。

レプリケーションは継続性を高めますが、クリーンな過去の復旧ポイントを置き換えるものではありません。

ネットワークアクセスの未準備

ユーザーが到達できなければ、復旧したアプリケーションは役に立ちません。DNS、VPN、ファイアウォール、ロードバランサー、証明書、ルーティング、ID 依存関係は復旧テストに含める必要があります。

ネットワーク準備は、技術的な復元と実際に使えるサービスの違いを決めることがよくあります。

復旧技術の本当の尺度は、データがどこかに存在するかではありません。適切な人が、必要な時間枠内に、適切なサービスを安全に再開できるかどうかです。

実装チェックリスト

システムを業務優先度で分類します。すべてに同じ一般的な目標を使うのではなく、サービスごとに RTO と RPO を定義します。

適切な保護方法を選びます。バックアップリストア、スナップショット、レプリケーション、待機環境、アクティブアクティブ設計は、それぞれ異なる要件とコストレベルに対応します。

コピーをサイバーリスクから守ります。必要に応じて、イミュータビリティ、分離された認証情報、暗号化、最小権限、バックアップ監視、オフラインまたは隔離コピーを利用します。

復旧手順を文書化します。システム依存関係、起動順序、ネットワーク変更、ログイン方法、ベンダー連絡先、ライセンス要件、検証テストを含めます。

定期的にテストします。復旧プロセスは実際のインシデント前に練習しておくべきです。インフラ変更、クラウド移行、アプリケーション更新、セキュリティポリシー変更後には計画を更新します。

FAQ

クラウドホスティングは自動的に災害復旧を提供しますか？

いいえ。クラウドプラットフォームは有用なツールを提供しますが、顧客側でバックアップ、レプリケーション、リージョン、権限、監視、復旧手順、テストを設定する必要があります。

復旧計画はどのくらいの頻度でテストすべきですか？

頻度は業務リスクとシステムの重要度によって異なります。重要システムでは定期的な演習が必要になる一方、それほど重要でないシステムは予定されたレビュー時や大きな変更後にテストできます。

ランサムウェアはバックアップシステムに影響しますか？

はい。攻撃者はバックアップリポジトリや管理者認証情報を標的にすることがあります。イミュータブルコピー、オフラインコピー、分離された権限、監視はこのリスクを下げます。

高可用性と災害復旧の違いは何ですか？

高可用性は、小規模な障害中もサービスを稼働させ続けることに重点を置きます。災害復旧は、拠点障害、サイバー攻撃、大規模データ損失を含む大きな中断後にサービスを復旧することに重点を置きます。

実際の復旧イベント後に何を見直すべきですか？

復旧時間、データ損失、失敗した手順、コミュニケーションの不足、ユーザー影響、セキュリティ上の発見、ベンダー対応、文書の正確性、次のインシデント前に必要な改善を見直します。