「バックアップは取っています」という言葉の危うさ

先代から会社を引き継いで数ヶ月、あるいは数年。決算書の見方も、取引先との付き合い方も、少しずつ自分のものになってきた。そんな時期に、ふと総務担当の古参社員に「うちのデータのバックアップってどうなってるの」と聞いてみたら、「もちろん取ってますよ、外付けのハードディスクに」という答えが返ってきた——。この記事はそこで安心してしまいそうになった経営者に向けて書いている。

結論を先に言う。「バックアップを取っている」という言葉と「データが本当に復元できる状態にある」という事実の間には、中小企業では驚くほど大きな溝がある。その溝を埋める最も実践的な考え方が、本記事で解説する「3-2-1ルール」だ。データを3つ持ち、2種類の異なる媒体に保存し、1つは必ず離れた場所(オフサイト)に置く——この3つの数字を守るだけで、火災・水害・ランサムウェア・単純な機器故障といった原因の異なる災厄のほとんどから会社のデータを守れる。

先代の時代は、パソコンの数も少なく、紙の台帳と手書きの伝票が業務の背骨だった。だからバックアップという概念自体が薄かった会社も多い。しかし今、見積書もクラウドの会計ソフトも顧客リストも、すべてがデータとして存在している。承継したのは会社という実体であると同時に、目に見えないデータという資産でもある。その資産を守る設計図を、この記事で一緒に描いていきたい。

この記事はこんな社長のために書いている

  • 先代から会社を継いで、パソコンやサーバーの管理は総務や古参の社員に任せきりになっている
  • 「バックアップは外付けHDDに取っている」と聞いて、それ以上突っ込んで聞けていない
  • 取引先から「BCP(事業継続計画)は策定していますか」と聞かれて答えに詰まった経験がある
  • 先代がランサムウェアやサイバー攻撃という言葉自体をあまり気にしていなかった会社を継いだ
  • IT担当が退職・異動する予定があり、バックアップの運用がその人の頭の中にしかないと感じている

一つでも当てはまるなら、この先を読み進める価値がある。

株式や登記には専門家がいるのに、システムには誰もいない

事業承継の場面では、株式の移転には税理士が、登記の変更には司法書士が、契約書の巻き直しには弁護士がついてくれる。士業のネットワークは、先代の代からの付き合いも含めて手厚く整っていることが多い。ところが、会社のパソコンやサーバー、データの管理については、相談できる専門家がまったく見当たらない、という声を多くの経営者から聞く。

法律行為には必ず「資格者」という形で相談窓口が用意されているのに、ITの実務には資格者の看板を掲げた相談先がほとんど存在しない。結果として、経営者は「情報システム部」という名の一人担当者、あるいは総務が兼務している誰かに、すべてを託すしかない状態に置かれる。バックアップの設計もその中に埋もれてしまいがちな項目の一つだ。この孤独感は、経営者だけの責任ではない。ただ、承継のタイミングは、その孤独な状態を初めて見直せる貴重な機会でもある。

なぜ「承継後」に見直す必要があるのか

先代が現役だった時期のバックアップ体制は、多くの場合、次のような経緯で出来上がっている。

  • 昔からいる社員が「なんとなく」外付けHDDにコピーを取り始めた
  • パソコンの入れ替えのタイミングでベンダーに勧められたクラウドサービスを導入したが、設定内容を誰も把握していない
  • 「うちはそんなに大事なデータはないから」という先代の判断で、対策が最小限のまま止まっている

これらは、当時の会社規模や業務内容には合っていたかもしれない。しかし承継のタイミングでは、事業内容そのものが変わっていることも多い。新規事業を始めた、顧客管理をExcelからクラウドの顧客管理システムに移行した、リモートワークを一部導入した——こうした変化のたびにデータの置き場所は増えていくのに、バックアップの設計は最初に決めたまま放置されているケースが非常に多い。

先代への敬意を忘れずに言うならば、当時のやり方を否定する必要はない。時代が変わり、データの重要性も攻撃の手口も変わった。だからこそ、承継という節目に「今の会社に合った設計に更新する」という発想を持つことが重要になる。

データという資産は、決算書に載らない

株式や不動産、設備といった資産は、決算書や固定資産台帳に金額として明記される。しかし、長年蓄積してきた顧客リスト、取引の履歴、図面や仕様書、社員が積み上げてきたノウハウの記録——これらのデータは、どれだけ会社の競争力を支えていても、バランスシート上には一切姿を現さない。承継の際に会計士や税理士とじっくり話し合う「見える資産」の陰で、「見えない資産」であるデータの扱いは、話題にすら上がらないまま引き継がれてしまうことが多い。

先代がその重要性を軽視していたわけではない。むしろ、長年の付き合いで築いた顧客との関係や、現場で培った技術情報こそが、先代にとって最も大切にしていたものだったはずだ。ただ、それを「データとしてどう保全するか」という技術的な話に落とし込む機会が、これまでなかっただけだ。承継者であるあなたが、その資産価値をあらためて言葉にし、守る仕組みを作ることは、先代の想いを引き継ぐ作業そのものでもある。

そもそも「バックアップ」とは何を指すのか

バックアップという言葉は、実務の現場では次のような意味で混同されがちだ。

  • パソコンの中のファイルを別のフォルダにコピーすること
  • 会計ソフトのデータをUSBメモリに移すこと
  • クラウドサービスに保存していれば「バックアップされている」と思い込むこと

しかし本来のバックアップとは、「元のデータが消えた・壊れた・使えなくなったときに、別の場所にある複製から元の状態を復元できる仕組み」を指す。単にコピーがあることと、実際に復元できることの間には大きな差がある。多くの中小企業でありがちなのは、コピーはあるが「復元テストを一度もしたことがない」というケースだ。いざ必要になったときにファイルが壊れていた、パスワードが分からない、復元の手順を知る人がすでに退職していた——という事態は、決して珍しい話ではない。この「復元できるか試したことがない」問題については、バックアップ、先代の時代から取ってはいるが復元できるか試したことはあるかでさらに詳しく扱っている。

IPAが「バックアップを取ろう」を6か条目に加えた意味

独立行政法人情報処理推進機構(IPA)は2026年3月、「中小企業の情報セキュリティ対策ガイドライン」の第4.0版を公開した。このガイドラインは長年「情報セキュリティ5か条」という形で、中小企業が最低限守るべき基本対策をまとめてきたが、第4.0版ではここに新たに「バックアップを取ろう」が加わり、「情報セキュリティ6か条」となった。

これは象徴的な変化だ。OSの更新、ウイルス対策ソフトの導入、強固なパスワードの設定といった「侵入を防ぐ」対策に加えて、「侵入されたあとにどう復旧するか」という視点が、国の基本方針として明文化されたことを意味する。攻撃を100%防ぐことはできないという前提のもとで、被害を受けた後にどれだけ早く元の状態に戻れるかが、企業の生死を分けるという認識が広がっている。

先代の時代、セキュリティ対策といえば「ウイルス対策ソフトを入れておけば十分」という感覚だった会社は多いはずだ。しかし今の基準では、それだけでは片手落ちになる。承継者として、この基準の変化を知っておくことは、経営判断の土台として欠かせない。

ランサムウェアという新しい脅威を正しく理解する

先代の時代にはあまり聞かなかった言葉かもしれないが、近年の中小企業被害で最も警戒すべきなのがランサムウェアだ。これは会社のパソコンやサーバー内のデータを勝手に暗号化し、「元に戻したければ金を払え」と要求する攻撃の総称である。

ここで重要なのは、ランサムウェアの被害はパソコン1台の故障とはまったく性質が異なるという点だ。ネットワークで繋がった社内の複数の端末やサーバーに一気に広がることが多く、さらに悪質なケースでは、社内のバックアップ用ハードディスクやNAS(ネットワーク接続ストレージ)まで暗号化の対象にされてしまう。つまり「バックアップを取っていたから安心」と思っていた複製データ自体が、攻撃者に人質にされてしまうケースが後を絶たない。

ランサムウェアは従来のバックアップ運用そのものを標的にするケースが増えている。単にデータを複製しておくだけでは、十分な対策とはいえなくなった。

この指摘は、まさに3-2-1ルールの中でも「オフライン・オフサイトの複製」がなぜ重要なのかを説明している。常時ネットワークに繋がっているバックアップは、攻撃者にとって「まとめて壊せる標的」になりかねない。ランサムウェア対策そのものを何から始めればいいかは、承継後の会社がランサムウェア対策は何から始めるかで具体的に整理している。

3-2-1ルールの中身を分解する

ここからが本題である、3-2-1ルールの具体的な内容を、承継後の中小企業の目線で分解していく。元々は米国の写真家が自分の作品データを守るために考案した手法だが、2012年に米国のサイバーセキュリティ専門機関CISA(当時のUS-CERT)が有効な対策として取り上げたことで、企業のデータ保護の基本形として広く定着した。

バックアップの3-2-1ルールを構成する「3つのコピー」「2種類の媒体」「1つのオフサイト」を分解して示す概要図。

3-2-1ルールは、次の3つの数字で構成される。

数字意味中小企業での具体例
3データを合計3つ持つ本番データ+社内バックアップ+クラウド(または遠隔地)バックアップ
22種類以上の異なる媒体に保存するパソコン内のSSDと、外部のNASやクラウドストレージなど
11つは必ずオフサイト(離れた場所)に置く本社が被災しても影響を受けないクラウドサービスや遠隔地の拠点

順番に見ていく。「3」は本番データを含めた総数であることに注意したい。つまり「本番データ+バックアップ1つ」では2にしかならず、3-2-1ルールを満たさない。少なくとも本番データ以外に2つの複製が必要になる。

「2」は媒体の種類を分散させることを求めている。同じ種類の媒体、たとえば同じメーカーの同じ型番のハードディスクを2台使っていても、経年劣化や故障のタイミングが似通ってしまい、リスク分散にならない場合がある。パソコン内蔵のストレージと外部のNAS、あるいはクラウドストレージのように、性質の異なる保存先を組み合わせることが望ましい。

「1」は最も見落とされがちな要素だ。社内にしかバックアップがない場合、火災・水害・盗難といった物理的な被害が発生すると、本番データと複製データが同時に失われてしまう。オフサイト、つまり社屋とは別の場所にデータを置いておくことで、この「まとめて失う」リスクを避けられる。クラウドサービスの活用は、このオフサイト要件を満たす最も手軽な手段の一つになっている。

これらをまとめた考え方そのものが3-2-1ルール(バックアップ)であり、次の見出しから解説する「3-2-1-1-0」という拡張版も、この基本形の上に成り立っている。

進化版「3-2-1-1-0」ルールも知っておく

近年、3-2-1ルールをさらに発展させた「3-2-1-1-0」という考え方も普及してきている。これはランサムウェアのようにバックアップそのものが攻撃対象になる時代に対応するための拡張版で、CISAなども言及している。追加された2つの要素は次のとおりだ。

従来の3-2-1ルールと進化版3-2-1-1-0ルールの違いを対比した図。

  • 追加の「1」: 複製のうち1つは「オフライン」または「イミュータブル(改変・削除不可)」な状態で保管する
  • 「0」: 復元テストを行い、エラーが0件であることを検証済みのデータであること

「オフライン」とは、ネットワークから物理的または論理的に切り離された状態を指す。ネットワークに繋がっていないバックアップは、ランサムウェアがネットワーク経由で暗号化を広げようとしても届かない。「イミュータブル」とは、一定期間、誰であってもデータを書き換えたり削除したりできない設定を指し、多くのクラウドストレージサービスがこの機能を提供している。

「0」の要素、つまり復元テストの実施は、地味だが最も見落とされがちなポイントだ。バックアップを取ること自体は多くの会社が「一応やっている」状態にあるが、実際に「そのデータから元に戻せるか」を試したことがある会社は驚くほど少ない。データが壊れていないか、パスワードは分かるか、復元にどれくらいの時間がかかるか——これらは事前に検証しておかなければ、いざというときに初めて判明する。

すべての中小企業がいきなり3-2-1-1-0まで完璧に整える必要はない。まずは基本の3-2-1を満たし、余力があればオフライン化と復元テストを追加していく、という段階的な発想で十分だ。

複数拠点・複数事業所を持つ会社ならではの注意点

創業から数十年を経て、本社のほかに工場や営業所、店舗を複数展開している会社を継いだ場合、バックアップの設計はさらに一段複雑になる。拠点ごとにパソコンやサーバーが個別に稼働していて、本社側がその実態を把握していない、というケースは決して珍しくない。先代が各拠点の所長や店長に運用を任せきりにしていた結果、拠点ごとにバックアップの有無や方法がまったく異なっている、という状態で承継を迎える社長も多い。

このような場合、まず全拠点に対して「バックアップの有無」「保存先」「担当者」を一斉に確認するアンケートのような形で棚卸しを行うのが効率的だ。拠点数が多い場合、電話やメールで一つずつ確認するよりも、簡単なフォームを作って回答してもらう方が早く全体像を掴める。ここで見えてくるのは、本社よりも地方拠点の方がバックアップ体制が脆弱だった、という構図が意外と多いという実態だ。日々の業務に追われる現場では、データ保護は後回しにされやすい。

拠点が複数ある場合の3-2-1ルールの考え方としては、各拠点のデータをまず本社のクラウド環境、あるいは統一したクラウドサービスに集約するという発想が有効になる。拠点ごとに個別のバックアップ体制を維持管理するよりも、集約した先で一元的に3-2-1ルールを満たす設計にする方が、運用の手間も監視の負担も大幅に減らせる。

承継直後にまずやるべき「バックアップの棚卸し」

3-2-1ルールを設計する前に、まず現状を正確に把握する作業が必要になる。これを怠ると、「新しいバックアップを追加したつもりが、実は既存の仕組みと二重管理になっていた」というような混乱を招く。棚卸しの手順は以下のとおりだ。

承継直後にバックアップの棚卸しを行う手順を示すフロー図。

  1. 会社が持っているデータの種類を書き出す(会計データ、顧客リスト、設計図面、契約書、写真データなど)
  2. それぞれのデータが「今どこに保存されているか」を特定する(社内サーバー、クラウド、担当者のパソコン、外部HDDなど)
  3. 現在バックアップが取られているかどうかを確認する
  4. バックアップが取られている場合、その頻度(毎日・週次・月次)と保存先を確認する
  5. 最後に「復元を試したのはいつか」を確認する

この棚卸しを一枚の表にまとめておくと、後から見返しやすい。実はこの棚卸し作業自体が、会社が使っているシステムとデータの全体像を可視化するシステム管理台帳の考え方と重なる部分が大きい。IT資産全体を管理する台帳を整備しておくことは、バックアップ設計の土台であると同時に、承継者がIT環境を把握するための第一歩にもなる。

「誰が」「いつ」「どこに」を明文化する

棚卸しが終わったら、次に3-2-1ルールに沿った具体的な運用ルールを文書化する。この文書化のステップを飛ばしてしまう会社が非常に多い。担当者の頭の中だけにルールがある状態は、その担当者が異動・退職・急病になった瞬間に会社全体のリスクになる。

明文化すべき項目の例を挙げる。

  • どのデータを、どの頻度でバックアップするか(毎日自動、週次手動など)
  • バックアップ先は具体的にどこか(サービス名、フォルダパス、契約先など)
  • 誰が実施し、誰が確認するか(担当者名、代理担当者名)
  • 復元テストをいつ、どの頻度で行うか
  • 障害発生時の初動対応の連絡先と手順

これらを1枚のドキュメントにまとめておくだけで、承継者自身が状況を把握できるようになり、担当者交代時の引き継ぎコストも大幅に下がる。特別なツールは必要なく、まずはExcelやワードで十分だ。重要なのは「存在すること」と「更新され続けること」である。

クラウドサービス活用という選択肢

3-2-1ルールの「オフサイト」要件を満たす手段として、近年はクラウドストレージやクラウドバックアップサービスの活用が主流になっている。自社で遠隔地に拠点を構えて物理的にデータを運ぶような大掛かりな対応をしなくても、月額課金のサービスを契約するだけでオフサイト保管が実現できるようになった。

クラウドを使う際に確認しておきたいポイントを整理する。

  • データの保存先(国内リージョンか海外リージョンか)
  • バックアップの自動化設定(手動運用に依存していないか)
  • 復元にかかる時間の目安(データ量が多い場合、復元に数日かかることもある)
  • アクセス権限の設定(誰がバックアップデータにアクセスできるか)
  • 料金体系(データ量に応じた課金か、固定料金か)

ここで一つ注意したい点がある。クラウドサービスを契約しただけで「オフサイト対応は完了」と考えてしまうのは早計だ。契約後に自動バックアップの設定が正しく有効化されているか、実際にファイルが同期されているかを、必ず目視で確認する必要がある。導入時にベンダーの担当者に設定してもらったまま、その後一度も確認していない、という状態は珍しくない。

オンプレミス環境が残っている会社の注意点

会社によっては、社内に物理サーバーを設置し、そこで基幹システムや顧客データを稼働させている、いわゆるオンプレミス環境が今も残っているケースがある。オンプレミス環境の場合、3-2-1ルールを満たすためには自社で複製先を用意する必要があり、クラウド完結の会社よりも一手間かかる。

具体的には、社内サーバーのデータを定期的に外部のNASにコピーし、さらにそのNASのデータをクラウドや遠隔地の拠点に転送する、という二段構えの仕組みを組む会社が多い。この場合、NASへのコピーとクラウドへの転送、それぞれのタイミングがずれていると、いざ復元する際に「どちらのデータが最新か分からない」という混乱が生じる。バックアップのタイムスタンプを揃えて管理する運用ルールも合わせて決めておく必要がある。

オンプレミス環境を将来的にクラウドへ移行する計画がある会社は、移行のタイミングでバックアップ設計そのものを見直す好機になる。移行を先延ばしにする場合でも、最低限、現状のオンプレミス環境における3-2-1ルールの充足状況だけは確認しておきたい。

古参社員の「これまでのやり方」との向き合い方

承継後にIT関連の見直しをしようとすると、古参社員から「今までこれでずっと問題なかった」という反応が返ってくることがある。この反応自体は決して悪意ではなく、長年その方法で会社を守ってきたという自負の表れでもある。ここで頭から否定してしまうと、以降の協力を得にくくなる。

有効なアプローチは、「これまでのやり方を否定するのではなく、今の会社の規模と今の脅威水準に合わせて“強化”する」というフレーミングで話を進めることだ。たとえば次のような伝え方が考えられる。

「今までのやり方、ずっと会社を守ってくれてありがとうございます。ただ最近はランサムウェアのようにバックアップ自体を狙ってくる攻撃も増えているので、今のやり方に“もう一段”備えを重ねたいんです」

このように、既存の努力に感謝を示しながら「追加」の文脈で話すことで、古参社員の協力を得やすくなる。3-2-1ルールは既存の仕組みを全否定するものではなく、既存の仕組みに欠けている要素を補うための考え方でもあるので、この伝え方は実態にも合っている。

先代への確認事項を「引き継ぎリスト」にする

先代がまだ会長や相談役として会社に関わっている場合、バックアップに関する記憶や知識を持っているうちに、確認しておくべき事項をリスト化しておくことを強く勧める。先代が完全に会社を離れてしまってから「あのハードディスクのパスワードが分からない」「あの契約はどのアカウントで結んだのか」と気づいても、確認する相手がいなくなってしまう。

確認しておきたい事項の例を挙げる。

  • 過去に導入したバックアップ用の機器やサービスの契約先、契約者名義
  • 過去にシステムトラブルが発生した際、どう対応して復旧させたかという経験談
  • 先代個人のメールアドレスや電話番号が、会社のシステムの連絡先として登録されていないか
  • 先代しか知らないパスワードや暗号化キーが存在しないか
  • 先代の代で契約したITベンダーとの取引条件や、サポートの範囲

こうした確認は、経営の引き継ぎ面談の中で改まって聞くよりも、雑談の延長で「そういえば、あの時のバックアップってどうやって守ってたんですか」と聞く方が、先代も気負わずに答えてくれることが多い。承継直後の数ヶ月は、先代の記憶がまだ鮮明で、かつ社内に協力する空気も残っている、貴重な期間だと捉えたい。

属人化していたバックアップ運用のリスク

事業承継の現場で最も頻繁に問題になるのが、バックアップの運用手順が特定の一人の頭の中にしかない、という属人化の状態だ。「バックアップは長年Aさんが担当していて、Aさんに聞けば分かる」という状態は、Aさんが休職・退職・急病になった瞬間に、会社全体が復旧不能なリスクを抱えることになる。特定の担当者の記憶や経験だけに業務が支えられている状態は、バックアップに限らず、会社のシステム運用全体に共通する典型的な弱点でもある。

承継のタイミングは、この属人化を解消する絶好の機会でもある。バックアップの担当を一人に固定するのではなく、正・副の2名体制にし、手順書を文書化しておくことで、特定の個人に依存しない体制に切り替えられる。先代の代からの引き継ぎ作業の中に、このバックアップ体制の言語化も必ず含めるべきだ。社用スマホなど端末側の管理体制も合わせて見直したい場合は、社用スマホの管理(MDM)入門、承継後に整えるべき理由も参考になる。

「非IT出身の社長」が判断に迷う場面への備え

製造・建設・卸売・サービスなど、IT業界とは異なる分野で長年経験を積んできた社長にとって、クラウドやNASといった専門用語が並ぶ提案書は、読んでいるだけで疲れてしまうものだ。ベンダーから複数の見積もりを取っても、どのプランが自社に本当に必要な水準なのか、判断材料が乏しいまま契約してしまうことも起こりがちだ。

こうした場面での実践的な対処法は、提案内容を必ず3-2-1ルールの3つの数字に当てはめて聞き直すことだ。「このプランで、データはいくつ複製されますか」「保存先の媒体は何種類になりますか」「オフサイトの保管先はどこですか」——この3つの質問を投げるだけで、提案の中身がどこまで基準を満たしているかが、専門用語を深く理解していなくても判断できるようになる。逆に、この3つの質問にベンダーが即答できない場合は、提案の設計そのものが甘い可能性がある、というシグナルとして受け止めてよい。

社内に技術に強い人材がいない場合でも、この3つの数字という共通言語を持っておくだけで、外部との交渉における対等な立場を保てる。専門知識がないことを引け目に感じる必要はない。数字で確認するという方法は、業界を問わず誰にでも使える判断軸だ。

コストをどう考えるか

バックアップ体制の強化には当然コストがかかる。クラウドストレージの利用料、NASなどの機器購入費、必要であれば外部ベンダーへの設定委託費などが発生する。承継直後は既存事業の立て直しに資金を割きたい時期でもあり、バックアップ投資を後回しにしたくなる気持ちも理解できる。

しかし、ここで考えるべきは「バックアップにかけるコスト」と「データを失った場合に発生するコスト」の比較だ。顧客リストや取引履歴、設計図面などのデータが失われた場合、業務が停止するだけでなく、取引先からの信頼を失い、最悪の場合は事業継続そのものが困難になる。バックアップは保険と同じ発想で捉えるとわかりやすい。毎年一定のコストを払うことで、万が一の際の損失を最小化する仕組みだと考えれば、経営判断としての優先順位も見えてくる。

まずは無料または低コストの範囲でできることから始めるのも一つの手だ。クラウドストレージの中には、一定容量までは無料で使えるプランを提供しているサービスも多い。完璧な体制を最初から目指すのではなく、3-2-1ルールの「3」「2」「1」を最低限満たす形から着手し、段階的に強化していくアプローチが、資金的な負担を抑えながら実効性を高める近道になる。

取引先からの要求に応えるための土台にもなる

近年、大企業を中心に、取引先の中小企業に対してセキュリティ対策の状況を確認する動きが広がっている。BCP(事業継続計画)の策定状況や、データ保護の体制について取引条件の一部として問われるケースも出てきている。3-2-1ルールに基づいたバックアップ体制を整えておくことは、こうした取引先からの照会に、自信を持って答えられる土台にもなる。

先代の時代にはこうした照会自体がなかった、という会社も多いはずだ。しかし承継後の経営環境では、直接の取引がなくても、サプライチェーン全体でのセキュリティ意識が問われる場面が増えている。バックアップ体制の整備は、防御的な対策であると同時に、対外的な信頼性を示す材料にもなり得る。

定期的な見直しを仕組みにする

3-2-1ルールに基づいた体制を一度整えたら終わり、というわけではない。事業内容の変化、新しいクラウドサービスの導入、社員の入退社などに応じて、バックアップの対象や運用方法は変わっていく。半年に一度、あるいは年に一度、次のようなチェックを行う仕組みを作っておくことが望ましい。

  • バックアップ対象のデータに漏れが出ていないか(新しく導入したシステムのデータは含まれているか)
  • 復元テストを実施し、実際に元に戻せることを確認したか
  • 担当者体制に変更はないか、手順書は最新の状態か
  • クラウドサービスの契約内容や料金プランに変更がないか

このチェックを、たとえば年度初めの定例業務として組み込んでおけば、忘れずに継続できる。承継者自身がこのチェックの実施状況を年に一度確認するだけでも、体制の形骸化を防ぐ効果は大きい。

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

ここまで、3-2-1ルールという考え方を軸に、承継後の中小企業がバックアップ体制をどう見直していけばよいかを解説してきた。数字自体はシンプルだが、実際に自社のデータ構成に当てはめて運用ルールを作る作業には、それなりの時間と社内の対話が必要になる。

大切なのは、完璧な体制を最初から目指す必要はないということだ。まずは棚卸しから始め、3-2-1ルールの「3」「2」「1」のうち、今の会社に欠けている要素を一つずつ埋めていく。それだけで、火災や機器故障、そしてランサムウェアといった原因の異なる脅威の多くから、会社が長年積み上げてきたデータという資産を守れるようになる。先代が守ってきた会社を、次のかたちで守り継いでいく——その最初の一歩として、今日、バックアップの現状を一つ確認してみてほしい。

よくある質問

Q1. 先代が決めたバックアップ体制を変えると、先代に失礼にならないか心配です

先代が築いた体制を否定する必要はまったくない。当時の会社規模や脅威の状況に合わせた合理的な判断だったはずだ。承継後に見直すのは「時代とともに変化した脅威やデータ量に対応するための更新」であり、過去の否定ではない。実際に先代に相談してみると、「今はそんなに危ないのか、それなら任せるよ」と快く受け入れてもらえるケースも多い。敬意を持って「更新」というフレーミングで伝えることが大切だ。

Q2. バックアップを長年担当していた古参社員に、新しいやり方を提案しても反発されそうです

長年その方法で会社を守ってきたという自負を尊重した上で、「今までのやり方に感謝しつつ、追加で強化したい」という伝え方をすると受け入れられやすい。頭から否定するのではなく、既存の運用に3-2-1ルールで欠けている要素(オフサイト保管や復元テストなど)を補う形で提案するのが現実的だ。可能であれば、その社員自身に新しい体制の運用担当を続けてもらい、承継者は状況を把握する側に回るという役割分担も検討したい。

Q3. 会社の登記や株式には名義変更が必要だと分かりますが、システムやデータにも「名義」のような問題はありますか

クラウドサービスやドメインの契約者名義が、先代の個人名やすでに退任した役員名になっているケースは非常に多い。契約者名義が本人以外の場合、パスワード再設定や重要な通知が本人に届かず、いざという時にアカウントにアクセスできないという事態が起こり得る。バックアップの見直しと同時に、契約しているクラウドサービスやドメインの契約者名義・連絡先メールアドレスが現経営者に更新されているかも、必ず確認しておくべきだ。

Q4. バックアップの担当者を社内に置けない場合、外部に委託することはできますか

可能だ。近年はバックアップの設計・運用・監視を代行してくれる外部サービスやITベンダーも増えている。社内に専任のIT担当者を置く余裕がない中小企業では、クラウドサービスの自動バックアップ機能と、月次の状況確認だけを外部に委託する、といった軽量な形で始めることもできる。委託する場合も、3-2-1ルールの「3」「2」「1」がそれぞれ具体的にどう満たされているかを、契約前に必ず確認しておきたい。

バックアップ設計と並行して、稼働しているサーバーOSのサポート状況も確認しておきたい。先代の代から動くWindows Serverのサポート終了(EOL)対応を参照。