結論から申し上げますと、「バックアップを取っていたのに復元できない」という事態は、バックアップの対象・方法・前提条件が現実の障害や攻撃シナリオと一致していない場合に起こります。
これは珍しい話ではなく、実務ではむしろ典型的な失敗例に近いものです。
まず、一般に言われる「バックアップを取っている」という状態は、多くの場合データそのもの、いわゆるデータプレーンのみを対象にしています。
例えば、ファイルサーバ上のファイル、データベースのテーブル、オブジェクトストレージ内のデータなどです。これ自体は重要ですが、実際のシステムはデータだけで動いているわけではありません。
OSの設定、ミドルウェアの設定、クラウドであればIAM、ネットワーク構成、アクセス制御、暗号鍵、アプリケーションのバージョンや依存関係など、いわゆるコントロールプレーンの情報が揃って初めてデータは「意味を持って」利用できます。
このコントロールプレーンがバックアップされていない、あるいは正確に再現できない場合、データは存在しても動かす環境が再構築できません。
典型例として、データベースのバックアップはあるが、暗号化キーが失われていて復号できない、クラウドのIAM設定が消失しており、誰も管理者権限でアクセスできない、ネットワーク構成が再現できずアプリケーションが外部と通信できない、といったケースがあります。
この状態では「データはあるが復元できない」という認識になります。
次に、バックアップ自体が攻撃や障害の影響を受けているケースも非常に多いです。
ランサムウェア攻撃では、業務データだけでなく、バックアップ領域やスナップショット、バックアップ管理サーバまで同時に破壊・暗号化されることがあります。
特にオンラインで常時接続されているバックアップは、攻撃者から見れば本番データと同等か、それ以上に価値のある破壊対象です。
この結果、バックアップは存在していたが、復元時にすでに汚染されている、あるいは完全に消去されているという事態が生じます。
さらに、バックアップの「復元検証」が行われていないことも大きな要因です。
バックアップは取得できていても、いざ復元しようとすると手順が不明確であったり、担当者しか知らない設定があったり、前提となるソフトウェアやライセンスがすでに失効していたりすることがあります。
実務では、バックアップ取得は定常業務として回っている一方で、実際に本番相当環境へ復元する訓練やテストは行われていないケースが少なくありません。
この場合、理論上は復元可能でも、現実には時間内に業務を再開できない、あるいは復元作業自体が破綻します。
ご質問にあったデータプレーンとコントロールプレーンの話に戻しますと、これはまさに本質を突いています。
現代のITシステム、とくにクラウドや仮想化基盤では、データプレーンだけのバックアップは「半分のバックアップ」に過ぎません。
コントロールプレーン、すなわちシステムを成立させている構成情報、権限、鍵、ネットワーク、依存関係を含めて初めて、実用的な復旧が可能になります。
今回のアサヒさんの件のような大規模なサイバー攻撃が注目される理由もここにあります。
単なるデータ消失ではなく、システム全体の信頼境界や管理基盤が侵害されると、バックアップがあっても安全に、かつ迅速に復元できる保証はなくなります。
そのため近年は、バックアップの有無ではなく、攻撃を前提とした復旧設計ができているか、オフラインやイミュータブルなバックアップがあるか、コントロールプレーンを含めて再構築できるかが重視されるようになっています。
要するに、「バックアップを取っている」という言葉の中身が曖昧なままだと、いざというときに復元できないという現象は十分に起こり得ます。
実務では、何を失うと業務が止まるのかを正確に洗い出し、それを再現するために何をバックアップし、どこまで検証しているかが問われます。
この点を意識すると、なぜそのような話が頻繁に出てくるのか、より具体的にイメージできると思います。
