IntactFile

破損した SQLite データベースを修復 — アップロードせずに

「database disk image is malformed」は、データが失われたことをほとんど 意味しません。1 つのページかポインタが壊れ、SQLite がファイル全体を 拒否しているだけです。復旧はページを走査し、生き残ったものから クリーンなデータベースを組み直します。

データベースがデバイスから出ることはありません — 復旧はブラウザ内で実行されます。アップロードは 0 バイト。

Your data is the big block — usually intact. What breaks is the small index. Repair rebuilds it.

Drop a file here or browseTap to choose a file

ZIP · Office · PDF · video · JPG · PNG · RAR/7z · SQLite — repaired right here in your browser. Nothing is uploaded

0 bytes uploadedFree: 3 repairs/day — up to 500 MB video, 100 MB docs & archives, 50 MB photos. Free download. Single repair €5.90. No account required.

データベースが開けない？ 今すぐ復旧

  1. .db / .sqlite ファイルをドロップ
  2. 復旧はローカルで実行
  3. 新しく開けるデータベースをダウンロード

不正な形式（malformed）の SQLite データベースを復旧するときは、 壊れたファイルをその場で「直す」わけではありません — まだデコードできる ものをすべて読み出し、まっさらな新しいデータベースへ書き込みます。 SQLite 自身の .recover コマンドの動き方とまったく同じです。 それがこのブラウザの中で実行されます。上のエリアにファイルをドロップ すると、診断が何が壊れているかを示し、復旧エンジンがスキーマを組み直して、 読み取れる行をすべて挿入し直します。何もインストールされず、データベースが アップロードされることも一切ありません。

このツールが対応するエラー

Error: database disk image is malformed (11)

定番の SQLITE_CORRUPT です。ファイルのページ構造の中の何かが矛盾して います — 壊れた b-tree ページ、不正なセルポインタ、ファイルサイズと 食い違うページ数など。エンジンは最初に行き当たった問題で停止しますが、 そこまでに到達しなかったページはたいてい無傷で、生スキャンならそこから 行をそのまま取り出せます。

file is not a database

SQLite は、16 バイトのヘッダーマジック（"SQLite format 3\0"）が 正しくないときにこれを表示します。原因は大きく 2 つに分かれます。 ヘッダーのバイトが壊れた場合（その背後にあるページは無傷で復旧可能な ことがよくあります）と、ファイルが本当に別物である場合 — あるいは 暗号化された（SQLCipher/SEE）データベースで、これは高エントロピーの ノイズとして読み取られ、鍵がなければ復旧できません。診断がこの 2 つを 見分けます。

database or disk is full / malformed database schema

同じ根本的なページ損傷の、下流に現れる症状です。ファイルを開き直しても 同じ失敗になるなら、その場での修正はもう打つ手がなく、次のステップは 生き残ったページからの再構築です。

SQLite ファイルはどう壊れるのか：ページとポインタ

SQLite データベースは、固定サイズのページ（通常は それぞれ 4 KB）が平坦に並んだ配列です。ページ 1 がヘッダーとスキーマを 保持します。すべてのテーブルとインデックスは b-tree で、 その内部ページが、実際の行を保持するリーフページへと下向きにポインタで 指します。ソフトウェアはヘッダーを読み、スキーマを見つけ、それから それらのポインタをたどってデータへ到達します。

ポインタこそが弱点です。1 回の書き込みの中断、不良セクタ、途中で 止まった同期、あるいは 1 つの内部ページでのビット反転 — それだけで ポインタの連鎖が切れ、SQLite は矛盾に行き当たってイメージ全体を malformed だと宣言します。あなたの行はリーフページの中に手つかずで 座っているのに、です。これは動画の失われたインデックスや、ZIP の 壊れたセントラルディレクトリとまったく同じ話です。壊れたのは地図で あって、データではありません。

だからこそ復旧が成り立ちます。リーフページは自己記述的なレコードを 持っているので、エンジンはファイルをページごとにたどり、見つけた行を デコードし、それらの周りに b-tree をゼロから組み直せます。ポインタが 到達できない行は生スイープで見つけ出し、既知のテーブルに一致しない行は、 捨てられるのではなく lost_and_found テーブルへ入れられます。

-wal ファイルがあるなら、一緒に持ってきてください

WAL モードのデータベースは、最近の変更を兄弟の<name>-wal ファイルにステージングし、メインの データベースにチェックポイントされるまでそこに置きます。クラッシュの後、 最新のコミット済みデータがそこにだけ存在することがあります。まずメインの.db をドロップし、それから任意のサイドカー枠に-wal ファイルを追加してください。そのコミット済みフレームが スキャンの前に重ね合わされるので、復旧されたデータベースは最後の チェックポイントではなく、最後にコミットされたトランザクションを反映 します。これは任意です — 復旧はメインファイルだけでも問題なく実行され ます — が、サイドカーが手元にあれば、そこに最も新しい行があることが よくあります。

なぜデータベースには「アップロードなし」が重要なのか

データベースに実際に何が入っているかを考えてみてください。ユーザー アカウント、メッセージ、位置情報の履歴、アプリの状態のすべて。それは、 「修復のためだけ」に他人のサーバーに置いておきたくない、まさにその 一つのファイルです。アップロード方式の復旧ツールは、それをあなたの マシンからコピーし、あなたには中身を確かめられないインフラ上で処理 します。ブラウザ内復旧は、そのステップをまるごと取り除きます — ファイル はあなたのディスクから読み込まれ、あなたのタブの中で組み直され、コピーが ほかのどこにも存在しません。証拠を扱う DFIR の作業では、これは証拠保全の 連鎖（chain-of-custody）も保ちます。アーティファクトがワークステーション から出ることは決してありません。復旧の実行中にネットワークタブでそれを検証できます。

何が復旧できて、何ができないか

復旧できるもの

  • 壊れたページや b-tree ポインタによる「database disk image is malformed」
  • 背後のページは無傷なまま、ヘッダーフィールドが壊れたもの（ページサイズやページ数の誤り）
  • 切り詰められたファイル。生き残ったページ上のすべての行を取り出します
  • ポインタの連鎖がもう到達できないページ上の行を、生ページスキャンで救い出します
  • 提供された -wal サイドカーからの、チェックポイントされていない変更

復旧できないもの

  • 物理的に上書きされたか、末尾から切り詰められた行 — そのデータはもう存在しません
  • 鍵のない暗号化データベース（SQLCipher/SEE） — ページは暗号文です
  • 正確な列アフィニティ。値はディスク上のストレージクラスのまま戻ってきます
  • 正しさの保証。復旧したデータは常に疑わしいものです。必ず検証してください
  • 0 バイトのファイル。それはまず、ストレージデバイスに対するデータ復旧の問題です

復旧レポートは、各テーブルから何が取り出せたかを一覧にし、生スキャンで 拾った行やデコードできず捨てた行に印を付けます。そして、修復が失敗した 場合に料金が請求されることは一切ありません。

よくある質問

「database disk image is malformed」とはどういう意味？

これは SQLite の SQLITE_CORRUPT エラー（result code 11）です。エンジンがファイル内のポインタをたどった先で、有効な b-tree ページではない何か — ゼロ埋めされたページ、不正なセルオフセット、ファイルの末尾より先を指すページ — に行き当たった、ということです。すべての行が失われたという意味ではありません。実際には、たった 1 つの壊れたページや誤ったヘッダーフィールドがファイル全体を落としてしまう一方で、残りのテーブルは無傷のままそこにあります。復旧はページを直接たどってスキーマを組み直し、まだデコードできる行をすべて、まっさらな新しいデータベースへ挿入し直します — SQLite 自身の .recover コマンドとまったく同じ戦略です。

ブラウザ内で本当に破損した SQLite データベースを復旧できますか？

はい。上のエリアに .db（または .sqlite/.sqlite3）ファイルをドロップしてください。ページスキャナーは純粋な TypeScript で、すべてあなたのタブの中で動きます。各ページをローカルで読み取り、スキーマを再構築し、各テーブルの b-tree をたどり、b-tree では到達できないものについてはポインタに頼らない生ページスキャンにフォールバックします。既知のテーブルに割り当てられない行は、捨てられるのではなく lost_and_found テーブルに格納されます。結果として得られるのは、ダウンロードできる新しく開けるデータベースファイルです。ブラウザ側で SQLite の復旧を提供している競合はありません — ほとんどはファイルをサーバーにアップロードさせます。

-wal ファイルとは何ですか？ 必要ですか？

WAL（write-ahead logging）モードの SQLite は、最近の変更を -wal という名前の兄弟ファイルに保持し、メインの .db にチェックポイントで書き戻されるまでそこに置きます。アプリがクラッシュした場合、最新のデータはその -wal ファイルの中だけに存在することがあります。もし手元にあれば、データベースをドロップした後、任意のサイドカー枠に追加してください。コミット済みのフレームがスキャンの前に重ね合わされるので、復旧結果は最後にコミットされたトランザクションを反映します。-wal がない場合でも、復旧はメインファイルに対して問題なく実行されます — チェックポイントされなかった変更が見えないだけです。

データベースをオンラインの修復ツールにかけても安全ですか？

データベースは、自分の管理下にないサーバーに渡すべきでないものの最たる例です。アプリがこれまでに保存したすべてのユーザーレコード、メッセージ、認証情報を抱えていることがあります。アップロード方式のツールは、あなたが書いたわけではない保存規約のもとで、そのファイルを自社のインフラにコピーします。ここでは何もアップロードされません — ファイルはあなたのディスクから読み込まれ、あなたのブラウザ内で組み直され、ネットワークタブで 0 バイトも送信されていないことを確認できます。

どのアプリが SQLite にデータを保存していますか？（自分に当てはまるか確かめたい）

ほとんどすべてです。iOS と Android のアプリ、ブラウザ（履歴、Cookie、拡張機能のストレージ）、Signal をはじめとするメッセンジャー、メモアプリ、メールクライアント、Lightroom のカタログ、そして数え切れないデスクトップツールが、いずれもデータを SQLite データベースに保持しています — 多くは .db、.sqlite、.sqlite3、あるいはアプリ独自の拡張子です。あるツールがデータベースは corrupt、malformed、または「not a database」だと表示するなら、このページはそのためのものです。DFIR のアナリストも、ディスクイメージからアーティファクトを取り出す際に同じファイルに出くわします。

なぜすべての行が戻ってくるわけではないのですか？

正直に言います。破損したデータベースから復旧したデータは常に疑ってかかるべきものです — SQLite 自身のドキュメントもそう述べており、頼りにする前に信頼できる情報源と照合して検証すべきです。物理的に上書きされたか、ファイルの末尾から切り詰められたものは失われており、どんなツールもそれを創り出すことはできません。値はディスク上のストレージクラスのまま戻ってくるため、列の型が変わることがあります。また、スキャンはフリーリストや vacuum されていないページも読み取るため、以前に削除された行が再び現れることがあります。復旧レポートは、テーブルごとに何が起きたかを正確に伝えます。

関連： 表計算ファイルが開けない — Excel ファイルを修復 · ドキュメントが開けない — PDF ファイルを修復 · アーカイブが展開できない — ZIP ファイルを修復 ·アップロードゼロの主張を検証する