Acronisが重視した「汚染されたデータを戻さない」

　Acronisは、RTOとRPOの設定やイミュータブルな保管、定期的な復旧テストといった基本に加え、バックアップとセキュリティを一体で考える必要性を強調した。

　ランサムウェア対策では、バックアップデータが残っているだけでは不十分だ。保存されたデータがマルウェアに汚染されていれば、復旧によって感染した状態まで戻してしまう可能性があるからだ。

　同社は、バックアップするデータがマルウェアに感染していないかを検査することに加え、復旧時にもデータを検査し、クリーンな状態で戻せるようにすることが重要だとした。バックアップやランサムウェア防御、クラウドストレージ、運用管理を統合して扱う「サイバープロテクション」という考え方も、同社の回答を貫く軸となっている。

　また、IT運用管理者が常駐していない拠点や工場、エッジ環境での復旧にも触れた。復旧手順を標準化し、中央管理やリモート支援、簡単な操作によって、現地の担当者でも復旧に着手できる仕組みを挙げている。

　Acronisの回答から見えるのは、データの保管だけでなく、復旧時の安全確認や、管理者への依存を抑えた運用までを一体で考える視点だ。

Arcserveが重視した「障害と方式のミスマッチ」

　Arcserveは、想定する障害とバックアップ方式が合っていないことを、復旧できない原因の一つとして挙げた。

　同社は、データ損失の要因を、ハードウェア故障などの「物理障害」、ランサムウェアや操作ミスなどの「論理障害」、広域災害などの「サイト障害」に分けている。

　障害の種類によって、必要な対策は異なる。例えば、機器の故障に備えた冗長化やリアルタイムの複製だけでは、暗号化や誤削除といった論理障害に対応できないことがある。　特に見落としやすいのが、レプリケーションとバックアップの違いだ。データをリアルタイムで複製していても、暗号化や誤削除は複製先にも反映されることがある。正常だった時点のデータを複数世代残していなければ、戻すべき状態そのものがなくなってしまう。

　Arcserveは、このほかにも「3-2-1-1ルール」（原本を含めてデータを合計3つ保持し、2種類の媒体に保存し、1つを遠隔地に、さらに1つをオフラインまたはイミュータブルな状態で保管する考え方）に基づくオフライン保管やイミュータブル化、本番環境との分離、定期的な復旧テストを基本として挙げている。その上で同社の回答から見えるのは、想定する障害に合った方式を選び、正常なデータを複数世代残すことの重要性だ。

Cohesityが重視した「復旧可能性の継続的な確認」

　Cohesityは、バックアップ処理の成功と、実際に復旧できることを分けて考えるべきだとした。

　多くの企業では、バックアップジョブが正常終了しているかを日々確認している。しかし、正常終了という結果だけでは、予定した時間内にデータを復旧できることや、復旧後にシステムが正常に動作することまでは保証されない。

　同社は、バックアップの成功率だけでなく、復旧可能性や異常の有無を継続的に可視化できる仕組みも確認すべきだと指摘する。

　本番環境に影響を与えずに復旧テストを実施できること、異常な暗号化や大量削除を検知できること、取得したバックアップデータの安全性を確認できることも、重要なポイントとして挙げた。保護対象については、「Microsoft 365」や「Salesforce」などのSaaSに加え、「Kubernetes」やクラウドネイティブなデータベースにも言及している。

　Cohesityは、このほかにもRTOとRPOの設定、イミュータブル化や環境分離、管理者権限が侵害されてもバックアップを削除できない仕組みを基本として挙げている。その上で同社の回答から浮かぶのは、バックアップを一度設定して終わりにするのではなく、実際に復旧できる状態を継続的に確認する必要性だ。

Veeamが重視した「データ以外の復旧条件」

　Veeamは、イミュータブル化やエアギャップ、クリーンなバックアップの検証、復旧訓練といった基本に加え、復旧に必要な条件をデータ以外にも広げて考えるべきだとした。

　バックアップデータが無事でも、ユーザーIDや権限、鍵管理、ネットワーク設定、セキュリティ設定などが失われれば、システムを業務で利用できる状態には戻せないことがある。

　例えば、サーバや業務アプリケーションを復元できても、「Active Directory」や「Microsoft Entra ID」などのID基盤が使えなければ、利用者はログインできない。条件付きアクセスポリシーに加え、アプリ登録やエンタープライズアプリ、サービスプリンシパル、ロールなど、業務アプリの認証や連携に必要な設定情報も復旧対象になり得る。

　復旧先の環境を確保できるかどうかも問題になる。

　被害を受けた既存環境をすぐに復旧先として利用できない場合は、別のハードウェアやクラウド環境を用意しなければならない。だが、新しい機器の調達には時間がかかり、クラウドへの復旧も、回線帯域や接続条件、コストの制約によって実行できない場合がある。

　復旧を担う人員も重要だ。構築時の担当者が既におらず、再設定すべき項目が数百、数千に及べば、理論上は復旧可能でも、予定した時間内には戻せない。Veeamは復旧訓練についても、技術的な操作だけでなく、誰が判断し、誰にエスカレーションし、誰が本番環境への復帰を承認するのかまで確認すべきだとした。

　同社の回答からは、復旧を単なる「データを戻す作業」ではなく、ID、復旧先、人員、意思決定を含む業務再開のプロセスとして捉える考え方が見える。

各社の着眼点は、復旧テストにも表れた

　4社はいずれも、復旧テストの重要性を挙げた。違いが表れたのは、テストで何を重点的に確認するかだ。

　Acronisは、想定したRTOとRPOを達成できるかに加え、復旧後のシステムがマルウェアに感染していないかを確かめる必要があるとした。

　Arcserveは、実際の作業時間を測定し、リストア後の点検まで含めてRTO内に収まるかを確認するよう求めている。主担当者が不在でも別の担当者が手順書だけで作業できるか、認証サーバや業務システムを正しい順番で復旧できるか、アクセス権が元の状態に戻っているか、利用者のPCから接続できるかも確認項目に含めた。

　Cohesityは、復旧テストを一度実施して終えるのではなく、復旧可能性や異常の有無を継続的に把握できる運用を重視する。

　Veeamは、IDやネットワーク、システム間の依存関係、権限、認証情報、承認プロセスに加え、危機的な状況でも迅速に意思決定できるかまで検証対象に含めている。

　どの回答も、単にファイルが戻ったかを確かめるだけでは足りないという点では共通する。一方で、技術、セキュリティ、運用、組織のどこまでを復旧テストに含めるかには、それぞれ異なる重点が表れている。

あなたの会社は「復旧できた」をどう定義しているか

　ここまで見てきた各社の回答を、製品・サービスを選ぶ際の確認項目として改めて整理しよう。4社に共通していたのは、バックアップを取得できるかではなく、必要な業務を実際に再開できるかを基準に考えることだ。

　まず、事業への影響を基に「どの業務を」「どの程度の時間で」「どの時点まで戻す必要があるか」を決める。その上で、オンプレミスのサーバだけでなく、SaaSやクラウド、PC、ID基盤など、業務再開に必要な対象が漏れなく保護されているかを確認する。

　バックアップデータについては、本番環境とは別に安全に保管され、不正な変更や削除を防ぐ仕組みが適切に設定されているかを確認する。保存したデータが破損しておらず、マルウェアに汚染されていないことも必要だ。

　復旧テストでは、データを戻せるかだけでなく、想定した時間内に、正しい順序と権限でシステムを復旧し、利用者が業務を再開できるかまで検証する。

　ここまでは、4社に共通する基本だ。一方で、製品や運用を検討する際に、どこをより詳しく確認すべきかという点には違いがあった。

　Acronisの回答からは、バックアップとセキュリティを一体で捉え、汚染されたデータを戻さない仕組みを確認する必要性が見える。Arcserveの回答からは、想定する障害とバックアップ方式が合っているか、正常なデータを複数世代残せるかが確認項目になる。Cohesityの回答は、バックアップ処理の成否だけでなく、実際に復旧できる状態か、異常が起きていないかを継続的に把握できるかという観点を示している。Veeamの回答からは、IDや権限、復旧先、人員、承認プロセスなど、データ以外の条件も確認対象になることが分かる。

　これらは、いずれか一つを選べば、他の観点が不要になるというものではない。企業が業務を再開するために必要な条件を、それぞれ異なる角度から具体化したものだ。

　製品選定で考えるべきなのは、共通する基本を押さえた上で、自社では何をもって「復旧できた」と判断するかという点だ。

　正常な世代のデータが戻ればよいのか。マルウェアに汚染されていない状態まで確認するのか。復旧可能性を継続的に検証できることを求めるのか。IDや権限、復旧先、人員、承認を含め、事業を再開できることまでを復旧とするのか。

　この「復旧できた状態」を先に定めなければ、必要な機能や運用体制も決められない。バックアップ製品を選ぶ際は、機能の多さを比べる前に、自社がどの状態まで、どの時間で戻す必要があるのかを具体化することが出発点になるだろう。