オンプレミス環境で複数の基幹システム（DBインスタンス）を運用されているサーバー管理者の皆様、日々のバックアップ作業、本当にお疲れ様です。
もし貴社のシステムがランサムウェアの被害に遭い、業務停止に陥った場合、最も復旧を困難にする要因の一つが「システム間のトランザクション整合性の不整合」です。
本記事では、複数システム環境で業務全体の整合性を守りながら、迅速な復旧を実現するためのバックアップ設計の核心を解説します。
１. 複数システム復旧の落とし穴：「時間差」がもたらす致命的な不整合
一つの業務プロセス（例：ECの「受注→在庫引当→出荷指示」）が、受注DB、在庫DB、物流DBなど、複数のRDBMSインスタンスに跨って処理されている場合を考えてみましょう。
私の実務経験上、「バックアップソフトウェアやハードウェアの制約で、すべてのインスタンスのバックアップ開始時間を数時間ずらさざるを得なかった」というケースは少なくありません。しかし、これがランサムウェアからの復旧時、致命的な問題を引き起こします。
ランサムウェアがシステムを停止させた瞬間、各DBのバックアップデータは異なる過去の時点を指しています。
【不整合の具体例】
| DB | 復旧後の状態 | 実際の業務との差 |
|---|---|---|
| 受注DB | 停止 5分前 のデータに戻った | 停止直前の注文は存在しない。 |
| 在庫DB | 停止 1分前 のデータに戻った | 停止直前に行われた在庫引当処理が中途半端にコミットされ、在庫が正しく戻っていない。 |
この状態では、システム再開後に「注文が存在しないのに在庫が引かれている」「会計データと在庫データが一致しない」といった論理的な矛盾が生じ、システム復旧後も 手作業での膨大なデータ修正（棚卸し） が必要となり、業務再開が大幅に遅延します。
２. 設計の鉄則：トランザクションレベルで同一時点に戻す仕組み
この問題を回避し、業務全体として整合性が取れた状態に戻すための核心的な設計思想は、 「クラッシュ・コンシステント・リカバリ（Crash-Consistent Recovery）」 をシステム全体で実現することです。
つまり、全システムを、攻撃による停止直前の「論理的に一貫した時点」まで巻き戻せるようにします。
🔑 解決の鍵：SCN（System Change Number）の同期
Oracle DatabaseのようなRDBMSには、データベースの状態を一意に識別する**SCN（システム変更番号）**という内部番号が存在します。
理想的な設計では、以下の手順で時点整合性を確保します。
- 停止時点のSCNの記録: 業務全体が停止した最終トランザクションのSCNを何らかの方法で記録します。（※攻撃時には困難な場合があるため、バックアップ取得時に連携させるのが現実的）
- 復旧の同期点: 復旧時、全DBインスタンスを同一時点のSCNまでリカバリ（ロールフォワード/ロールバック）するよう指示します。
- 結果: すべてのDBがトランザクションレベルで同一の時点に揃うため、システム間のデータの整合性が保証されます。
🔑 復旧の鍵：バックアップ時の「SCN連携」運用を必須に
バックアップシステムが複数のDBインスタンスを同時に処理できない場合でも、リカバリ時の整合性確保を諦めてはいけません。復旧時間を短縮し、データ矛盾を防ぐため、「SCN連携」の運用を必ず組み込んでください。
- SCN一括記録の実施: インスタンスAのバックアップを開始するスクリプトの中で、他のすべての連携DBインスタンス（B、C、D...）の現在のSCNを一括で取得し、物理時刻とともに共通の管理テーブルに記録します。
- 論理的な同期点の作成: この記録されたSCNセットが、物理的なバックアップ開始時間のズレを超えて、 全システムの論理的な整合性を保証する「同期点」 となります。
- リカバリ時の活用: 障害発生時、このSCNセットを基点とし、すべてのインスタンスをそれぞれの記録されたSCNまでリカバリすることで、業務全体のデータ矛盾を排除し、手動でのデータ調整作業を最小限に抑えられます。
- 本番環境でデータの矛盾排除できたら別環境で最新の状態までリカバリしたデータと見比べてリカバリできなかったデータを特定しましょう。
３. ハードウェア制約とバックアップ手法への対応
「同時に2インスタンスしかバックアップできない」といったハードウェアやソフトウェアの制約がある場合でも、「時点整合性」を諦めてはなりません。設計の工夫で対応が必要です。
A. ハードウェア制約への対処：データ保護専用製品の検討
- ストレージ連携スナップショット: 複数インスタンスのDBファイルを同一のストレージアレイ上に配置し、ストレージ側の機能（LVMや専用機能）で複数のボリュームに対して協調的な（Coordinated）スナップショットを瞬時に取得します。これにより、バックアップ時間差を極小化し、SCNの同期点を作成しやすくなります。
- バックアップソフトウェアの選定: データベースとの連携に特化し、複数のDBインスタンスに対して同時にバックアップ開始をトリガーできるソフトウェアを選定し、制約を乗り越えます。
- 筆者は一瞬だけOracleのインスタンスを停止し、共有ストレージの機能でスナップショットを取得後すぐにインスタンスを起動する運用を経験したことがあります。スナップショットからデータファイルや制御ファイルをバックアップすれば業務の停止時間を最小限にしてオフラインバックアップが取得できる仕組みです。
B. 差分・増分バックアップの考慮点
バックアップ時間を短縮するための 差分（Differential）や増分（Incremental） の組み合わせは有効ですが、一点注意が必要です。
- 完全バックアップ（フルバックアップ）の頻度: 差分/増分バックアップは、最後に取得した完全バックアップを基点として成立します。ランサムウェア攻撃によって基点となるフルバックアップが汚染（暗号化）されてしまうと、その後の差分/増分バックアップもすべて無意味になってしまいます。
- オフライン/イミュータブル（不変）な保管: 差分/増分バックアップを利用しつつ、重要なフルバックアップデータは、ランサムウェアがアクセスできないテープストレージやオフラインのストレージ、または書き換え不可能な（イミュータブルな）クラウドストレージに定期的に退避させることが必須です。
結論
オンプレミス管理者にとって、複数システムのバックアップ設計は、単にデータ容量や時間との戦いではありません。 「復旧後の業務の整合性を保証できるか」 という視点が最も重要です。
システム設計とバックアップ設計を密に連携させ、トランザクションレベルで復旧時点を同期できる仕組みを必ず確保してください。それが、ランサムウェアの脅威から企業の事業継続を守る、最も賢明な投資となります。