「データベースが開けません」と出たとき — 何％戻るかを言い切る人は、たぶん見ていません

長年使ってきたソフトを開いたら、起動しない。エラーの文言をそのまま検索すると、データベースが壊れているらしい。そんな状況になったことはありませんか。

・業務で使っているアプリが起動せず、データが読めなくなった

・`database disk image is malformed` のようなメッセージが出る

・バックアップはあるが、半年前のもので、そこから今までの入力が入っていない

まず、いちばん急ぐことをお伝えします。

何よりも先に、コピーを取ってください

そのファイルに、これ以上さわらないでください。

やることは1つだけです。壊れたファイルを、別の場所へコピーする。それだけです。USBメモリでも、別のフォルダでも構いません。できれば2か所に置いてください。

理由は単純で、復旧を試みる操作そのものが、状態をさらに悪くすることがあるからです。修復ツールを走らせる、アプリで開き直す、再インストールする。どれも、残っている断片を上書きしてしまう可能性があります。元のファイルさえ手つかずで残っていれば、何度でもやり直せます。

復旧で最初にやるべきことは、直すことではなく壊れた状態を保存することです。

「何％戻りますか」に答えられる人はいません

次に聞きたくなるのが、これです。ですが、この質問に事前に答えられる人はいません。

データベースが壊れるといっても、壊れ方はさまざまです。先頭の数十バイトだけが書き換わったのなら、中身はほぼ無傷です。ファイルの後ろ半分が切り落とされていたら、その部分は誰にも取り戻せません。消えたバイトは、どんな技術でも復元できません。

そして、どちらの壊れ方なのかは、開いてみるまで分かりません。 ファイルサイズもエラーメッセージも、そこまでは教えてくれません。

だから、「9割は戻せますよ」と最初に言い切る相手には、根拠を聞いてください。中身を見ていない段階で出せる数字ではありません。

頼むときに確かめる3つ

事前に約束できないものがある以上、確かめるべきは率ではなく、やり方です。

① 元のファイルに書き込まないと明言しているか

「読み取り専用で扱います」「作業前後でファイルが変わっていないことを確認します」と言えるかどうか。ここが守られていれば、失敗しても振り出しに戻れます。

② 救えなかった部分を、どう扱うか

いちばん差が出るところです。取り出せなかった行をそれらしい値で埋めて返してくる人がいます。件数が揃うので、一見きれいに見えます。これは最悪です。 本物と作り物が混ざったデータは、どこが信用できるのか永久に分からなくなります。「救えなかったものは、救えなかったと報告する」相手を選んでください。

③ 出てきたデータが本物だと、どう確かめるか

「取り出しました」で終わらせず、取り出した行が元の内容と一致しているかを、どう検証したかを聞いてください。件数だけの報告は、中身の保証にはなりません。

 そのまま使える依頼文

コピーして、必要なところだけ変えてお使いください。

―――ここから―――

データベースファイルが壊れて開けなくなりました。救出をお願いしたいです。

・ファイル：〇〇.db（〇MB）

・使っていたソフト：〇〇

・症状：〇〇（例：アプリ起動時に「database disk image is malformed」と出る）

・心当たり：〇〇（例：作業中にPCが強制終了した／保存先のUSBを抜いた）

・元のファイルは別の場所にコピーして保管してあります（原本には触っていません）

・お願いしたいこと：

　原本には書き込まないでください。

　救い出せなかった部分は、推測で埋めずに「取り出せなかった」と報告してください。

　取り出した行が本物であることを、どう確かめたかも教えてください。

・戻したいもの：〇〇（例：顧客の一覧と、直近1年の取引履歴）

―――ここまで―――

「推測で埋めないでください」の1行が、この依頼のいちばん大事なところです。

返ってくるべきもの

まっとうな相手なら、次の3つが返ってきます。

・救い出せたデータ（CSVなど、別のソフトで開ける形で）

・何が取り出せて、何が取り出せなかったかの内訳（表ごとの件数）

・原本が変わっていないことの確認（作業前後で同一であること）

2つ目が肝心です。「〇〇は全件、△△は一部のみ」まで分かって初めて、次に何をすべきかを決められます。 全体で何件としか言えない報告では、どこを手で入力し直すかも判断できません。

 実際にやってみた話

手前味噌ですが、当方のツールでの検証を1つ。

450行のデータベースを1つ用意し、それを8通りに壊しました。 先頭だけを壊したもの、ヘッダを壊したもの、内部の索引を壊したもの、真ん中のページを8枚つぶしたもの、後ろ40%を切り落としたもの、そもそもデータベースですらないファイル、中身が空のファイル、そして壊していない対照。

結果は、はっきり分かれました。先頭やヘッダの破損では450行すべてが戻りました。真ん中のページがつぶれたものは342行（76.0%）、後ろを切り落としたものは143行（31.8%）です。 データベースでないファイルと空のファイルは、何も出さずに失敗として停止しました。

同じ「壊れています」でも、31.8%と100%があります。 これがこの作業の性質そのものです。

そのうえで、もうひとつ確かめたことがあります。出てきた行が、すべて本物だったかです。全条件を通じて、取り出した行に作り物は1つも混ざっていませんでした。この確認は、正解を伏せた状態で照合する形で行い、114項目すべてが合格・不合格0でした（これは合成データでの検証で、お客様のデータではありません）。

最後に、正直なところ（3行）

・救出率は事前にお約束できません。 できるのは、観測した幅をお見せすることと、実際に開いてみてからお伝えすることだけです。

・消えたバイトは戻せません。 上書きされた部分・切り落とされた部分は、どんな方法でも復元できません。

・1行も救えないこともあります。 そのときは、確認した範囲と分かったことをお伝えします（作り話で埋めることはしません）。

---

壊れたデータベースからのデータ救出を、上のような形でお引き受けしています。原本には書き込まず、救えるだけ取り出し、救えなかったところは救えなかったと報告します。取り出した行に作り話を混ぜません。まずはファイルの大きさと、出ているエラーの文言をお知らせください。

復旧レポートの実物です（自社デモ・450行のデータベースを8通りに壊して検証）。

見てほしいのは、何を試してどの手が効いたかが順に残るところ。戻らなかった分も件数で書きます。

▶ 壊れたSQLiteのデータを救出します: