戻せないバックアップは無いのと同じ
デューデリジェンスのチェックリストには、たいてい「バックアップの取得状況」という項目があります。買い手が尋ね、売り手が「毎日自動で取っています」と答え、買い手はそこに丸を付けて次の項目へ進む。この一往復は、だいたい10秒で終わります。そして、この10秒で確認できたことは、実のところ何ひとつありません。
バックアップという言葉が厄介なのは、「取得」と「復元」というまったく別の二つの行為が、ひとつの単語に押し込められている点です。取得は自動化できます。cronが回り、ダンプが吐かれ、どこかのストレージに積み上がっていく。一方で復元は、誰かが手を動かして初めて成立する行為で、しかもそれが必要になるのは事故のときだけなので、平常時には一度も実行されないまま何年も過ぎていきます。
結果として、取得は毎日成功していて、復元は一度も試されたことがないという状態が、驚くほど普通に存在します。この記事では、なぜ「バックアップの有無」という問いが査定において無意味なのか、現場で実際に何が壊れているのか、そして買い手と売り手がそれぞれ何を確認すべきかを、実務の順序で整理していきます。
「取れている」と「戻せる」の間には、誰も立っていない
まず前提を揃えます。バックアップの目的は、ファイルを増やすことではありません。事業を元の状態に戻すことです。したがって、バックアップが機能しているかどうかを判定できる問いは、原理的にひとつしかありません。「戻せますか」です。
ところが実務で交わされるのは、ほぼ例外なく「取っていますか」の方です。この二つは似た顔をしていますが、答えの信頼性がまったく違います。「取っています」は、管理画面のスケジュール設定を見れば言えてしまう。「戻せます」は、実際に戻してみないと言えない。にもかかわらず、DDの現場では前者の回答が後者の証明として扱われ、そのまま通過していきます。
ここで起きているのは、売り手が嘘をついているという話ではありません。売り手自身が「取れている＝戻せる」と本気で信じているケースがほとんどです。毎日メールで「Backup completed successfully」という通知が届いていれば、それは安心する材料になりますし、成功していると書いてあるのだから成功しているのだろうと考えるのは、人として自然な反応です（そのメールが何を検証した上で successful と言っているのかは、たいてい誰も読んでいません）。
そして、この構造の残酷なところは、ズレが発覚するのが必ず「戻さなければならない瞬間」であるという点です。サーバーが飛んだ日、データを消してしまった日、あるいは移管作業に失敗した日。世界で最も余裕がないタイミングで、初めて「このダンプ、戻らないぞ」と気づく。買収後の引き渡し後の事故が深刻化しやすいのは、まさにこの発覚タイミングの悪さが原因です。
壊れているバックアップの五つの型
では、具体的に何が壊れているのか。現場で繰り返し観測されるパターンは、おおむね次の五つに集約されます。どれも派手ではなく、地味に、静かに壊れています。
型1: ダンプは取れているが、戻す手順が存在しない
最も多いのがこれです。データベースのダンプファイルが日付付きで整然と並んでいる。中身も壊れていない。しかし、それをどういう順序で、どこに、どんなオプションで流し込めば事業が復旧するのかを書いた文書が、どこにも無い。
元のオーナーの頭の中にはあります。何度かやったことがあるので、手が覚えている。しかし買い手の手元には、拡張子が .sql のファイルがあるだけです。文字コードは何か、外部キー制約を一時的に外す必要があるか、流し込んだ後にキャッシュを消す必要があるか、アプリケーション側の設定ファイルはどこを書き換えるのか。これらが分からないまま渡されたダンプは、正直なところ、動かないただの大きなテキストファイルです。
これは環境構築の属人化とまったく同じ病理で、資産が「人」の側に残っていて「モノ」の側に移っていない状態を指しています。売り手が引き渡したつもりのものと、買い手が受け取ったものが一致していない。
型2: 取得対象から、アップロードファイルとシークレットが抜けている
バックアップ＝データベース、という思い込みは根深いものがあります。DBのダンプだけを毎日取っていて、それで万全のつもりでいる。しかし現代のWebサービスにおいて、DBだけ戻しても事業は復旧しません。
典型的に抜け落ちるのは次のものです。
- ユーザーがアップロードした画像・PDF等の実ファイル（DBにはパスしか入っていない。パスだけ戻しても、リンク切れの一覧が復元されるだけです）
- 環境変数・設定ファイルに書かれたAPIキーや認証情報
- Webサーバーやリバースプロキシの設定、SSL証明書まわり
- cronの定義そのもの（ジョブの中身はコードにあっても、いつ何を叩くかの定義はサーバー上にしかない）
特にシークレットの扱いは事故になりやすい部分です。バックアップから漏れているだけなら復旧できないという損害で済みますが、逆に「バックアップにだけ平文で入っている」というパターンもあり、この場合はAPIキーが漏洩する経路がひとつ増えることになります。取得範囲の設計は、復旧可能性と情報管理の両面から評価する必要があります。
型3: 復元先の環境が違って、そもそも起動しない
データは戻った。ファイルも揃った。それでもアプリケーションが立ち上がらない、というケースです。
原因はほぼ環境差分です。元のサーバーはPHP 7.4だったが、買い手が用意した新しいサーバーは8.3で、非推奨だった関数が消えている。MySQLのバージョンが上がってsql_modeの既定値が変わり、それまで通っていたクエリがエラーになる。当時のOSにしか入っていないライブラリに依存している。ミドルウェアの設定値が暗黙の前提になっている。
つまり、バックアップが保存しているのはデータであって、そのデータが動いていた文脈ではないということです。そして事業を買うということは、データではなく文脈ごと買うことに他なりません。この差分は、実際に別のサーバーで復元を試みるまで絶対に見えません（元の本番サーバーに戻すテストをしても、環境が同じなので何も検証していないのと同じです）。
型4: 暗号化キーが、暗号化されたデータと同じ場所にしかない
セキュリティ意識が高い現場ほど陥る、皮肉なパターンです。バックアップを暗号化して保存しているのは正しい。問題は、その復号キーが、そのサーバーの中にしか置かれていないという構成です。
サーバーが健在なうちは何の問題もありません。サーバーが飛んだ瞬間に、暗号化されたバックアップだけが手元に残り、それを開ける鍵はサーバーと一緒に消えています。金庫と鍵を同じ部屋に置いて、部屋ごと燃やしたという状態です。
M&Aの文脈ではもう一段厄介で、キーが売り手の個人PCのキーチェーンや、パスワードマネージャの個人アカウントにしか無いというケースがあります。この場合、引き渡し当日は問題なく見えます。事故が起きるのは、売り手との連絡が途絶えた半年後です。
型5: 保存先が、旧オーナーの個人アカウントである
最後は、技術ではなく所有の問題です。バックアップの保存先が、旧オーナー個人のGoogleドライブ、個人のDropbox、個人のAWSアカウント、個人契約のレンタルサーバーになっている構成は、個人開発由来の事業では珍しくありません。
ここで起きるのは、「バックアップは存在するが、買い手はそれにアクセスできない」という状態です。しかも、この状態は引き渡し直後には表面化しません。旧オーナーがそのアカウントを解約した日、支払いに使っていたカードが期限切れになった日、あるいは単に容量上限に達して静かに書き込みが止まった日に、初めて問題になります。
これはアカウント名義の論点そのもので、バックアップに限らず事業資産全般に共通する構造です。ただしバックアップは「普段使わないもの」なので、名義の棚卸しから漏れやすいという性質があり、他の資産より一段見落とされやすい位置にいます。
唯一の証拠は「直近いつ、どこへ、誰が復元したか」
五つの型を並べてみると、共通点が見えてきます。すべて、一度でも実際に復元してみれば、その場で発覚するという点です。
手順書が無ければ手が止まります。ファイルが抜けていれば画像が出ません。環境が違えば起動しません。キーが無ければ開けません。アクセス権が無ければダウンロードすらできません。逆に言えば、復元を最後まで通した経験があるバックアップは、この五つを全部クリアしていることになります。
ですから、DDで確認すべき問いは「バックアップはありますか」ではありません。次の一文です。
「直近で復元を実行したのはいつで、どの環境に戻して、どこまで動作を確認しましたか」
この問いは、質問として非常によくできています。取得の設定画面を見るだけでは答えられないからです。返ってくる答えが「本番以外のサーバーに、先月、全部戻して管理画面のログインと投稿表示まで確認しました」であれば、その事業のバックアップは資産です。「取ってはいますが、戻したことは無いですね」であれば、それは資産ではなく、資産だと思われている何かです。
そして残念ながら、実務で圧倒的に多いのは後者です。悪意はまったくありません。事故が起きていない事業ほど復元する機会が無いので、健全に運営されてきた事業ほど「一度も戻したことがない」という答えになる。優等生ほどこの項目で引っかかるという、なかなか意地の悪い構造になっています。
買い手は、書類ではなく実演を求めるべき
買い手側の実務に落とし込みます。バックアップの検証は、技術的DDの中でも比較的早い段階に置く価値があります。理由は、ここが不合格だった場合、その事実が価格ではなく取引条件そのものに影響するからです。
確認の方法は、質問ではなく実演です。具体的には、次の順序で依頼します。
- 最新のバックアップ一式を、本番とは別の環境に復元してもらう。ここで言う「一式」には、DB・アップロードファイル・設定・シークレットをすべて含みます。本番に戻すテストは検証になりません
- 復元後の環境で、事業の中核機能が動くところまで確認する。トップページが表示された、では足りません。ログインできるか、決済まわりが疎通するか、画像が表示されるか、管理画面から更新できるか。収益に直結する導線を通します
- その作業を、売り手ではなく買い手側の人間の手でやってみる。ここが本質です。売り手がやれば動くのは当たり前で、それは属人性の証明にしかなりません。手順書だけを渡された第三者が復元を完走できて初めて、その資産は移管可能だと言えます
- かかった時間を計測する。事故時の復旧時間はそのまま停止時間であり、停止時間は売上の欠損です。「2時間で戻る」と「丸2日かかる」は、同じ復元可能でもリスクの大きさが桁で違います
この検証は、たいていの規模の事業なら半日で終わります。半日で、五つの型のすべてに網がかかる。費用対効果としては、DD項目の中でもかなり優秀な部類です。
なお、売り手がこの実演を渋る場合、そこには理由があります。技術的に無理なのか、時間が無いのか、そもそも自信が無いのか。渋る理由の中身が、バックアップそのものより雄弁に事業の状態を語ります。
売り手が、交渉が始まる前にやっておくこと
売り手側の話をします。ここまで読んで「うちは戻したことがないな」と思った方がいるとすれば、それはむしろ幸運です。交渉のテーブルで発覚するより、今気づいた方が圧倒的に良い。
やることは単純で、一度、別のサーバーに全部戻してみる。これだけです。ただし、その過程で必ず引っかかる箇所が出てくるので、そこを潰していく作業が本体になります。
順序としては次のようになります。まず取得対象を洗い出して、DB以外に何が必要かを列挙します。次に、それらを含めた状態で復元を試みます。ほぼ確実にどこかで止まるので、止まった箇所をそのまま手順書に書き足していきます。この「詰まった場所を書く」という作業が、そのまま引き継ぎ資料になります。頭の中で完璧な手順書を書こうとすると絶対に完成しませんが、実際に詰まった場所を記録するだけなら誰でも書けます（そして、詰まらなかった箇所は書く必要がありません）。
この作業には、副次的な効果が二つあります。ひとつは、当然ながら自分の事業が事故から守られること。もうひとつが重要で、「先月、別サーバーに全復元して動作確認済みです。手順書はこれです」と言える売り手は、DDで一段高く評価されるということです。
買い手が本当に見ているのは、バックアップという個別の項目ではありません。この事業が、オーナーの頭の中ではなく、記録と手順として存在しているかどうかです。復元テストを通してある事業は、それを証明できてしまう。逆に言えば、たった半日の作業で、事業全体の解像度に対する評価を引き上げられるということでもあります。
査定と契約への織り込み方
バックアップの状態は、査定に対して次のように効きます。
- 直近に第三者環境への復元実績があり、手順書が揃っている: この論点で減点する理由はありません。むしろ運営体制の成熟を示す加点材料として扱われます
- 取得はされているが、復元は未検証: 買い手は「引き継ぎ直後に事故が起きたら、自力で戻せない可能性がある」という前提で見ることになります。引き渡し時に復元検証を条件として入れるか、一定期間の技術サポートを条件に含める交渉になりがちです
- 保存先や復号キーが旧オーナーの個人資産に紐づいている: 移管対象資産の定義そのものが不完全な状態です。契約書で切り分けるべき論点であり、価格の話に入る前に整理が必要になります
- バックアップが実質存在しない（取得が止まっている等）: この場合、買い手は事業と一緒に「いつ起きるか分からない全損リスク」を買うことになります。復旧体制の構築コストを買い手側の初期投資として見積もる話になります
契約面では、最低限ひとつだけ明文化しておく価値があります。引き渡す資産の一覧に、バックアップの保存先アカウント・復号キー・復元手順書を明記するという一文です。「サーバー一式」「データ一式」という書き方では、これらが含まれるのかどうかが後から争点になります。特に復号キーは、それ自体はただの文字列なので、資産として認識されないまま引き渡しから漏れやすい部類に入ります。
もうひとつ、取得が止まっていないことの監視を誰が持つのか、という論点もあります。バックアップは静かに失敗します。ディスクが埋まった、認証が切れた、保存先の仕様が変わった。エラーが誰にも通知されない構成だと、止まってから数ヶ月経って気づくことになる。引き渡し時点で動いていたことと、その後も動き続けることは別の話です。
戻せない資産は、まだ資産になっていない
バックアップの話は、地味です。DDの項目としても、正直あまり花形ではありません。収益構造の分析や、コード品質の評価や、契約関係の精査に比べると、確認作業そのものは驚くほど単純です。別のサーバーに戻してみるだけ。それ以上でも以下でもない。
ただ、この単純な作業をやったかどうかが、事業が引き継げるかどうかという、最も根本的な前提を左右します。戻せないバックアップは、査定上は存在しないのと同じです。存在するのはファイルであって、復旧可能性ではないからです。
そして、この論点で一番損をしているのは、実は売り手の方だと考えています。何年もかけて事業を育て、毎日きちんとバックアップを取り続けてきた。その努力は本物です。にもかかわらず、一度も復元を試したことがないというだけで、買い手からは「不確実性を抱えた事業」として値付けされてしまう。積み上げてきたものの実質と、評価される内容が噛み合っていない。これは単純にもったいない。
逆から見れば、この差は半日で埋まります。別のサーバーを一台立てて、全部戻して、詰まったところをメモする。それだけで、「たぶん大丈夫です」が「先月やりました、これが手順書です」に変わる。事業の中身は何ひとつ変わっていないのに、買い手から見える景色は完全に変わります。
バックアップは、取るものではなく、戻すものです。戻したことがないなら、それはまだ、戻せるかどうか分からないものでしかありません。売却を考え始めた日に、まず一度戻してみてください。その半日が、事業の価値を正しく評価してもらうための、最も安上がりな投資になります。
