バックアップ、先代の時代から取ってはいるが復元できるか試したことはあるか

結論、それは「まだ確認していない」に等しい

先代の時代から続けているバックアップ。毎晩自動でテープやNASにデータが吐き出され、担当者が「今日も無事終わりました」とチェックする。それを何年も続けてきたなら、社長であるあなたは「うちはバックアップの備えができている」と思っているはずです。しかし、そのバックアップから実際にデータを復元してみたことは、これまで一度もないのではないでしょうか。

結論から言います。復元したことのないバックアップは、あるかどうか分からないバックアップと同じです。取得ログが緑色でも、復元できるかどうかはまったく別の話だからです。この記事は、こんな状態の社長に向けて書いています。

• 先代が始めた自動バックアップの仕組みを、意味も分からずそのまま引き継いでいる
• IT担当の古参社員から「バックアップは大丈夫です」と言われて、それ以上踏み込めていない
• サーバーやPCが壊れたときに本当にデータが戻るのか、想像したことがない
• ランサムウェアのニュースを見て不安になったが、何をすればいいか分からない

承継した会社では、株式や登記、取引先との関係といった「人が助けてくれる領域」には専門家が付いています。税理士、弁護士、事業承継の専門家。ところがシステムやデータの話になると、相談できる相手が社内にも社外にも見つからず、結局「今まで動いているから大丈夫」という先代からの申し伝えに頼るしかない、という孤独な状況に陥りがちです。バックアップの復元テストは、まさにその「相談先がない領域」の代表格です。

なぜ「取っている」と「戻せる」はまったく違う話なのか

バックアップという言葉には安心感があります。しかし、バックアップの仕組みは「データを書き出す」プロセスと「データを書き戻す」プロセスの、まったく別の2つの技術で構成されています。多くの中小企業が整備しているのは前者だけです。書き出す部分は自動化されていて日々動いているのに、書き戻す部分は一度もテストされていない、という状態は驚くほど頻繁に見られます。

書き出しに失敗が起きにくい理由は単純です。書き出し先の容量が足りていれば、多くのバックアップソフトは「成功」のログを出します。しかし、そのファイルが実際に壊れていないか、暗号化のキーが正しく保存されているか、バックアップ対象から重要なフォルダが漏れていないか、といった問題は、復元を実行するまで表面化しません。ログが緑色であることと、いざというときにデータが戻ることは、似ているようで別の保証です。

この構図を車の点検にたとえると分かりやすくなります。ガソリンを満タンに入れているからといって、エンジンがかかるかどうかは別問題です。バックアップの取得は「ガソリンを入れる」行為に近く、復元テストは「実際にエンジンをかけてみる」行為に近い。多くの会社は前者だけを毎晩繰り返し、後者を一度も試していません。ガソリンが満タンでもエンジンがかからなければ、その車で出かけることはできないのと同じで、復元できないバックアップはデータを守っていることになりません。

さらに厄介なのは、バックアップの「失敗」がほとんどの場合、静かに起こるという点です。ハードディスクの一部セクタが壊れていても、バックアップソフトは処理そのものは完了させてしまうことがあります。担当者が毎朝チェックしているのは「処理が完了したかどうか」という表面的なログであり、「その中身が本当に使える状態かどうか」までは、通常の運用チェックでは検証されません。ここに、日々の運用が丁寧であればあるほど油断が生まれる、という逆説があります。

先代が組んだバックアップ、その設計思想を誰も知らない

承継した会社でよく起きるのが、「バックアップの設定をしたのが先代の時代の担当者で、もう退職している、あるいは先代自身が業者に一括発注して、詳細は誰も把握していない」というケースです。設定した人がいなくなった仕組みは、動いているように見えても、実際には次のような問題を抱えていることがあります。

• バックアップの対象フォルダが、当時のシステム構成のままで更新されていない
• 新しく導入した基幹システムや会計ソフトのデータが、バックアップ範囲に入っていない
• バックアップ先のディスクやテープがすでに寿命を迎えていて、書き込みエラーが静かに発生している
• パスワードや暗号化キーの管理者が退職していて、復元時に誰も開けられない

こうした問題は、日々の運用を見ているだけでは絶対に発見できません。復元テストを実際にやってみることでしか、設計の古さや抜け漏れは見えてこないのです。

先代がまだ現役の頃、システムのことは先代自身か、先代が信頼していた特定の業者や社員に一任されていたケースが多く見られます。当時はそれで十分機能していたはずです。しかし承継後、その「一任されていた誰か」が退職したり、取引が終了したりすると、設計の意図や前提条件を知る人がいなくなり、バックアップの仕組みはブラックボックス化していきます。これは決して珍しい話ではなく、システムや設備の管理が特定の個人の頭の中にしか残っていない状態、いわゆる属人化の典型例です。属人化した仕組みは、その人がいる間は問題が起きませんが、いなくなった瞬間に一気にリスクが表面化します。バックアップはまさにその代表例であり、「動いているから大丈夫」という安心感の裏側で、実は誰も全体像を説明できない状態になっていることが少なくありません。

IPAも「バックアップを取ろう」を新たに明文化した

これは中小企業経営者の感覚だけの話ではありません。独立行政法人情報処理推進機構（IPA）は2026年3月、「中小企業の情報セキュリティ対策ガイドライン」を第4.0版に改訂し、従来の情報セキュリティ5か条に「バックアップを取ろう！」を新たに追加して6か条としました。IPAはこの改訂の背景として、ランサムウェア被害の顕在化により、企業のサイバーセキュリティ被害が情報漏えいだけでなく事業活動そのものの停止にまで拡大していることを挙げています。

つまり、国の情報セキュリティ機関が「バックアップは基本の基本」として6か条レベルに格上げしたのが、まさに2026年のことです。先代の時代にはまだそこまで明文化された基準がなかった以上、「先代のやり方をそのまま引き継いでいれば十分」という前提そのものを、今の時代に合わせて見直す必要があります。

ランサムウェアは中小企業を狙って狙っている

「うちみたいな会社を狙う攻撃者はいないだろう」という感覚も、承継した社長にはよくある油断です。しかし警察庁の統計では、2025年に把握されたランサムウェア被害226件のうち143件、6割超が中小企業で発生しています。攻撃者にとって、セキュリティ対策が手薄で、かつ取引先とのつながりを通じてさらに被害を広げやすい中小企業は、むしろ狙いやすい標的です。

ランサムウェアの被害は、データを人質に取られて業務が止まるという形で表面化します。このときに問われるのが、まさに「バックアップから復元できるかどうか」です。バックアップさえあれば身代金を払わずに復旧できる、というのが対策の基本ロジックですが、そのロジックは復元が実際に成功して初めて成立します。取ってはいるが戻せない、というバックアップは、ランサムウェアに対して何の防御にもなっていないのと同じです。

近年のランサムウェア攻撃はさらに厄介な手口を使うようになっています。攻撃者は暗号化する前に、まずネットワーク内を静かに探索し、バックアップサーバーやバックアップ用のアカウントそのものを特定して、先に破壊したり暗号化したりすることがあります。つまり「いざとなったらバックアップから戻せばいい」という発想そのものを潰しにかかってくるのです。この手口を防ぐには、バックアップへのアクセス権限を必要最小限の人間に絞り、可能であれば本番環境と管理者アカウントを分離しておくことが有効です。誰でもバックアップの設定を変更できる状態は、攻撃者にとっても社内の誤操作にとっても、同じくらい危険な状態だと考えてください。

復元テストをしないまま迎える3つの「その日」

復元テストをしていない会社が実際にデータを失う瞬間は、大きく3つのパターンに分かれます。

パソコンが突然起動しなくなった、サーバーが落雷で壊れた、社員の誤操作で共有フォルダの重要なファイルが全部消えた。どのケースも「まさかこんな形で」という顔で相談が来ます。

1つ目は単純な機器故障です。ハードディスクやSSDは消耗品であり、何年も稼働させたサーバーやPCは、ある日突然データを読み出せなくなります。2つ目は人的ミス、いわゆる誤操作による削除や上書きです。3つ目がランサムウェアなどの悪意ある攻撃です。いずれの場合も、バックアップから復元できるかどうかで、会社が受けるダメージの大きさは何倍も変わります。復元テストをしていない会社は、この3つのどれが起きても「試してみたら復元できなかった」という二重の被害に見舞われるリスクを抱えています。

復元テストとは具体的に何をすることか

「復元テスト」という言葉だけだと大掛かりな作業に聞こえますが、実際には難しいものではありません。基本的な考え方は、バックアップから実際にデータを取り出し、それが正しく使える状態になっているかを確認する、という一点です。具体的な手順は次のようなイメージです。

このステップを、本番のデータを壊さない検証環境やテスト用のPC上で実施するのが基本です。年に1回、あるいは半期に1回でも実施しておけば、「バックアップが取れているつもり」から「復元できることを確認済み」へと状態が変わります。

大切なのは、最初から完璧を目指さないことです。全システム、全データを一度に検証しようとすると、それだけで大きなプロジェクトになってしまい、結局「時間がないからまた今度」と後回しにされがちです。まずは会計データや顧客名簿など、失うと最も困るデータを1つだけ選んで、小さく試してみる。この最初の一歩さえ踏み出せれば、「復元テストは特別な作業ではない」という感覚が社内に根付いていきます。

バックアップの種類によって復元の難易度が変わる

バックアップには大きく分けて「フルバックアップ」「差分バックアップ」「増分バックアップ」という方式があります。フルバックアップはすべてのデータを毎回丸ごと保存する方式で、復元はシンプルですが時間と容量がかかります。差分・増分バックアップは、前回のフルバックアップからの変更分だけを保存する方式で、容量を節約できる代わりに、復元時にはフルバックアップと差分・増分の両方を正しい順序で組み合わせて処理する必要があります。

先代の時代に設定されたバックアップが、容量節約のために差分や増分の方式を採用している場合、復元の手順は想像以上に複雑になっていることがあります。「バックアップは取れているはずなのに、復元しようとしたら手順が分からず止まった」という不備の多くは、実はこの復元手順の複雑さに起因しています。復元テストは、単にデータが戻るかどうかを見るだけでなく、復元の手順書そのものが今の担当者にも理解できる形で残っているかを確認する機会でもあります。

頻度はどのくらいが妥当か

復元テストの頻度について、絶対的な正解はありませんが、目安として次のような考え方が実務ではよく使われます。

• 重要な基幹データ（会計・受発注・顧客情報など）は半年に1回程度
• それ以外の業務データは年に1回程度
• システム構成やバックアップ機器を変更したタイミングでは、その都度必ず1回実施する

頻度そのものよりも重要なのは、「一度もやったことがない」状態を今すぐ終わらせることです。まず1回、どれか1つのデータで試してみる。そこから頻度を決めていく、という順番で構いません。

もう一つの目安として、「復旧までにどれくらいの時間なら業務が耐えられるか」を先に決めておく、という考え方があります。専門的には目標復旧時間と呼ばれる考え方に近く、例えば「受注データが半日戻らないと取引先への納期回答ができない」という業務であれば、復元にかかる時間がその半日を超えないかを確認する必要があります。逆に、月次でしか使わないデータであれば、復元に数日かかっても業務上は大きな支障がない場合もあります。復元テストの際にかかった時間を記録しておくことが、この業務上の許容時間と実際の復元時間のギャップを把握する唯一の手段になります。

バックアップの世代管理という落とし穴

復元テストをして初めて気づくことが多いのが、バックアップの「世代管理」の問題です。バックアップは1世代（直前の状態）だけを保持していると、ランサムウェアに感染したファイルそのものを暗号化された状態でバックアップしてしまい、そのバックアップから復元しても感染したファイルが復元されてしまう、という事態が起こり得ます。

これを避けるためには、直近の数世代を遡って復元できる状態を保っておくことが重要です。世代管理をしていない、あるいは何世代残っているか誰も把握していない、という会社は少なくありません。復元テストの過程で「何日前の状態まで戻せるか」を確認しておくと、この落とし穴に事前に気づくことができます。

バックアップの保管場所、3か所に分けているか

データ保護の考え方として広く知られているのが、3-2-1ルール（バックアップ）です。データを3つ以上のコピーとして持ち、2種類以上の異なる媒体に保存し、そのうち1つは離れた場所（オフサイト）に置くという原則です。近年ではこれをさらに発展させ、コピーのうち1つを改ざん不可能な状態（イミュータブル）または物理的に隔離した場所に置き、定期的な復元テストによって復元エラーをゼロに近づけるという考え方も広がっています。

3-2-1ルールに沿った設計そのものの立て方は承継後に見直す、中小企業のバックアップ設計入門（3-2-1ルール）で詳しく解説している。先代の時代のバックアップが「同じ建物内のNASに1つだけ」という構成になっている場合、火災や浸水、あるいは同じネットワーク経由でのランサムウェア感染によって、バックアップ自体も同時に失われるリスクがあります。復元テストをする際には、あわせて「そもそも保管場所が1か所に集中していないか」も点検しておくとよいでしょう。

地方の中小企業では、事務所と工場、あるいは本社と営業所が同じ建物や同じ敷地内にあることが多く、「離れた場所にもう1つコピーを置く」という発想自体が抜けてしまいがちです。クラウドストレージを使えば、専用のサーバーを別の建物に用意するよりも低コストでオフサイト保管を実現できます。先代の時代にはクラウドサービスの選択肢が少なかった、あるいは費用が高かったという事情もあったはずですが、今はその制約が大きく緩和されています。承継のタイミングは、こうした「当時はできなかったが今ならできる」対策を取り入れる好機でもあります。

古参の担当者に「大丈夫です」と言われたときの受け止め方

承継した社長が最も気を遣うのが、先代の時代からバックアップを見てきた古参社員への確認です。「バックアップは大丈夫ですか」と聞いて「大丈夫です、ずっとやってますから」と返ってきたとき、それ以上踏み込みにくい空気があるのは自然な感情です。相手の長年の仕事を疑うようで、気まずさを感じる社長も多いでしょう。

ただし、ここで意識してほしいのは、これは担当者個人の能力や誠実さを疑う話ではないということです。バックアップの「取得」は真面目に続けられてきたはずです。問題になるのは「復元」という、取得とは別の技術領域を、これまで確認する機会自体がなかったという点に尽きます。「一緒に一度、試しに復元してみましょう」という提案は、担当者を疑う言葉ではなく、担当者の仕事を守るための言葉として伝えることができます。実際に復元できることが確認できれば、それは担当者にとっても大きな安心材料になります。

承継直後だからこそ、今が確認の好機

承継してすぐの時期は、会社のあらゆる仕組みを「なぜこうなっているのか」を確認しながら引き継いでいく期間です。バックアップについても、この時期にこそ、次のような質問を投げかける正当な理由があります。

• 「このバックアップの設定は、いつ、誰が組んだものですか」
• 「最後に復元を試したのはいつですか」
• 「復元にどれくらい時間がかかるか、把握していますか」
• 「バックアップの保管場所は何か所に分かれていますか」

これらの質問は、先代の判断を否定するものではありません。時代とともに会社の規模やシステムが変わった以上、当時最適だった設計が今もそのまま最適とは限らない、というだけの話です。承継のタイミングで一度立ち止まって確認することは、後任として当然の責務であり、先代への敬意を欠く行為ではありません。

先代がまだ会長職などで会社に関わっている場合、バックアップの話を切り出すこと自体に気を遣う社長も多いでしょう。「せっかく整えてくれた仕組みにケチをつけるようで気が引ける」という感情は自然なものです。ただ、伝え方を変えれば、先代を立てながら確認することは十分に可能です。「お父さんが作ってくれた仕組みを、これからも安心して使い続けたいので、一度中身を確認させてください」というように、感謝と継承の意志を先に示した上で確認に入れば、多くの場合は先代自身も快く協力してくれます。むしろ、先代の世代がバックアップの重要性を早くから理解し、仕組みを整えてくれていたこと自体は、承継した側にとって大きな財産です。その財産を、今の時代の基準でも確実に機能する状態に更新していく作業だと捉えれば、気持ちの面でも取り組みやすくなるはずです。

復元テストで見つかりやすい5つの不備

実際に復元テストを行った企業でよく発見される不備を整理すると、次のようなパターンに集約されます。

1. バックアップの対象範囲から重要なフォルダやデータベースが漏れていた
2. 暗号化パスワードが分からず、復元作業そのものが止まった
3. バックアップ機器やメディアが物理的に劣化していて、読み込みエラーが出た
4. 復元にかかる時間が予想よりも大幅に長く、業務停止時間の想定が甘かった
5. バックアップ先が本番環境と同じネットワーク内にあり、感染時に同時に被害を受ける構成だった

これらはどれも、実際に手を動かして復元を試みるまでは見えてこない問題です。逆に言えば、1回でも復元テストをやってみれば、こうした不備の大半は発見できるということでもあります。

ここで注意したいのは、不備が見つかったこと自体を「失敗」だと捉えないことです。復元テストの本来の目的は、問題が起きる前に不備を見つけることにあります。テストをして何も問題が見つからなければそれで安心材料になりますし、問題が見つかれば、実際の障害が起きる前に対処する時間が手に入ります。どちらに転んでも、テストをしたこと自体が会社にとって前進です。逆に最も避けたいのは、テストをせずに「たぶん大丈夫だろう」と思い込んだまま、本番の障害で初めて不備に気づくという展開です。

相談先がないなら、まず社内でできることから

「システムのことは相談先がない」という孤独感を抱えている社長にお伝えしたいのは、復元テストは大掛かりな外部発注をしなくても、まず社内だけで始められるという点です。バックアップソフトに標準で付いている「テストリストア」や「復元シミュレーション」の機能を使えば、専門知識がなくても最初の一歩は踏み出せます。

その上で、次のような場合には外部の専門家に相談することを検討してください。

• 復元テストをやってみたが、そもそも復元の手順自体が分からない
• バックアップの設計を今の会社規模やシステム構成に合わせて見直したい
• ランサムウェア対策として、保管場所やアクセス権限まで含めた総点検をしたい

いきなり大きな契約をする必要はありません。まずは現状のバックアップ構成を棚卸しして評価してもらう、というスポットの相談から始める会社も多くあります。

相談先を選ぶ際のポイントとして、「バックアップ機器を売ること」が目的の業者と、「復元できる状態を作ること」が目的の業者は、似ているようで提案の中身が異なります。前者は容量の大きい機器やライセンスの追加を勧めてくることが多く、後者は復元手順の整備や訓練、記録の仕組み作りまで含めて提案してくれる傾向があります。承継直後で業者選びの基準がまだ分からない場合は、「復元テストを一緒にやってもらえますか」という質問を投げかけてみると、相手の姿勢がある程度見えてきます。

システム管理台帳と組み合わせて考える

バックアップの話は、単独の話題として終わらせるより、会社にある機器やシステムの全体像と紐づけて考えるとより実効性が上がります。何をバックアップすべきか、どのシステムが会社の事業継続に不可欠かを把握するためには、まず社内にどんなシステムがあり、どこにデータが存在しているかを一覧化しておく必要があります。これがシステム管理台帳の考え方です。

承継直後で「うちにどんなシステムがあるのか、自分でも全部を把握できていない」という社長は珍しくありません。バックアップの復元テストを機に、あわせて社内のシステム一覧を作っておくと、次に同じような不安が出てきたときに、確認すべき範囲がすぐに分かるようになります。台帳作りの具体的な手順は非IT出身の承継社長のためのIT資産管理の始め方も参考にしてほしい。

一覧化の作業は、思っているよりも時間がかかりません。まずはパソコン、サーバー、業務システム、契約しているクラウドサービスを1枚のシートに書き出すだけで十分です。そのシートに「バックアップ対象か」「最後に復元テストをした日付」という2つの列を追加しておけば、バックアップの状況を一目で確認できる管理表としても機能します。承継直後にこの一覧を作っておくことは、システムの話だけでなく、次に何か問題が起きたときに誰に何を聞けばよいかを整理する土台にもなります。

稟議を通すときの伝え方

復元テストの実施や、バックアップ構成の見直しには、多少の予算や社員の時間が必要になる場合があります。社内で承認を得る際、「先代の時代からのやり方を疑っている」という伝え方をすると、古参社員や周囲から反発を受けやすくなります。むしろ次のような伝え方が有効です。

• 「IPAのガイドラインが改訂され、バックアップが情報セキュリティの基本6か条に入った」という外部要因を根拠にする
• 「今の設定で復元できるかを一度確認するだけ」という、最小限のスコープから始める
• 「先代が築いてくれた仕組みを、今の時代でも確実に機能させるための確認」という前向きな位置づけにする

こうした伝え方は、社内の稟議を通す際にも、過去の否定ではなく未来への備えとして受け止められやすくなります。

復元テストの結果は必ず記録に残す

復元テストを1回やって「できた」で終わらせず、結果を記録に残すことが重要です。記録すべき項目は次の通りです。

• 実施日
• 対象データ
• 復元にかかった時間
• 発見した問題点とその対処
• 次回実施予定日

この記録があれば、担当者が変わっても、次に確認すべきことが明確になります。逆に記録がなければ、数年後に「前に確認したはず」という曖昧な記憶だけが残り、また同じ不安を抱えることになります。承継した会社にとって、こうした記録は次の代への引き継ぎ資産にもなります。

バックアップ以外にも広がる「取っているつもり」問題

復元テストの話は、実はバックアップだけに限りません。会社のシステム全体を見渡すと、似た構造の問題が他にも潜んでいることがあります。退職した社員のアカウントが残っていないか、パソコンやスマートフォンの管理が誰の手に渡っているか把握できているか、社内システムのパスワードやライセンスの更新が期限切れになっていないか、といった論点です。いずれも「日々の運用は回っているように見えるが、実際に確認したことはない」という同じ構造を持っています。バックアップの復元テストをきっかけに、こうした周辺の点検にも目を向けてみる価値があります。

経営者が最終的に問われること

会社を継いだ社長にとって、システムやデータの話は、株式や不動産のように目に見える資産ではないため、どうしても後回しにされやすい領域です。しかし、データが失われて業務が止まった瞬間、社長が取引先や社員から問われるのは「なぜバックアップがあったのに戻せなかったのか」という一点に尽きます。そのとき「先代の時代からの仕組みだったので」という説明は、責任を免除してくれる言葉にはなりません。承継した以上、その仕組みを引き継いだ社長自身の責任として受け止められることになります。

だからこそ、今のうちに一度確認しておくという行動そのものが、経営としての備えになります。復元テストは、専門的な知識を持つ社員や外部の業者に任せる部分があってもかまいませんが、「確認したかどうか」を把握しておくのは社長自身の役割です。難しい技術の詳細を理解する必要はありません。「いつ、誰が、何を確認したか」を知っているだけで、経営としての責任は十分に果たせます。

まとめではなく、次の一歩として

先代から受け継いだバックアップの仕組みは、これまで会社を支えてきた大切な資産です。それを否定する必要はまったくありません。ただ、その資産が本当に機能するかどうかを、一度も確かめずに使い続けるのは、もったいないことです。

今日、担当者に「一度、試しに復元してみましょう」と声をかけてみてください。それだけで、これまで抱えていた「もしものときに本当に大丈夫なのか」という漠然とした不安の輪郭が、はっきりと見えてくるはずです。確認して初めて、安心は本物になります。半年経っても不安が消えないという場合は承継から半年、システム面の不安が減らないときに見直すべき手順もあわせて確認してほしい。

よくある質問

Q1. 復元テストをすると、今動いているシステムに影響が出ませんか

適切に行えば本番環境に影響を与えずに実施できます。復元テストは、別の検証用フォルダやテスト用のPC・仮想環境にデータを書き戻して内容を確認する形が基本です。本番のデータを上書きする形でテストを行うと事故のリスクがあるため、必ず本番環境とは別の場所に復元して確認するようにしてください。手順が分からない場合は、バックアップソフトの提供元やシステム管理を担う業者に、安全なテスト方法を確認するのがよいでしょう。

Q2. 先代の時代から使っている古い担当者に、今さら「復元できるか確認して」と言うのは気が引けます

担当者の仕事を疑う言葉ではなく、担当者の仕事を守るための確認だと捉えると伝えやすくなります。長年バックアップの取得を続けてきたこと自体は評価すべき仕事です。今回確認したいのは、取得とは別の「復元」という工程であり、これまで確認する機会がなかった領域だと伝えれば、多くの場合、担当者自身も納得して協力してくれます。実際に復元できることが確認できれば、それは担当者にとっても長年の仕事の正しさを証明する機会になります。

Q3. バックアップの保管場所や名義が先代個人の契約になっている場合、どうすればいいですか

まずは契約名義とアカウントの管理者権限を確認し、会社名義や後任者が管理できるアカウントに切り替えることをおすすめします。バックアップサービスやクラウドストレージの契約が先代個人のメールアドレスや個人名義になっているケースは珍しくなく、先代が完全に引退した後にパスワードやアカウントへのアクセスができなくなるリスクがあります。復元テストを行うタイミングは、こうした契約名義やアクセス権限を点検する好機でもあります。

Q4. 復元テストの結果、データが戻らないことが分かったら、まず何をすればいいですか

すぐに全部を作り直す必要はありません。まずどの範囲が復元できて、どの範囲が復元できなかったのかを整理し、業務上どのデータが最も重要かを優先順位づけしてください。優先度の高いデータについては、バックアップの取得方法そのものを見直す、あるいは保管先を分散させるといった対策を先行して行い、それ以外の部分は段階的に改善していくという進め方が現実的です。不安であれば、この整理の段階からシステムに詳しい専門家に相談することをおすすめします。

バックアップの運用ルールと合わせて、Windows Updateの適用ルールも社内で明文化しておきたい。Windows Updateの社内運用ルール、承継後に整備する方法を参照。

また、復元テストを済ませたとしても、実際にランサムウェアに感染してしまった場合は、テスト時とは異なる緊迫した状況での判断が求められる。ランサムウェアに感染した。バックアップはあるのに復元できない、を防ぐ承継後の初動に、感染直後の初動手順を時系列でまとめているので、あわせて確認しておいてほしい。