壊れた iOS の Core Data ストアを復元する

Core Data はオブジェクトグラフと永続化のフレームワークであって、データベースそのものではありません — データベースは SQLite で、そのレイアウトを支配しているのが Core Data です。Core Data ストアを任意の SQLite ブラウザで開いても、親しみやすいテーブル名は目に入りません。フレームワークが生成する変形されたスキーマが見えます。各エンティティは Z + エンティティ名を大文字にしたテーブルになるので、Person エンティティはテーブル ZPERSON です。各行は3つのシステム列を持ちます: Z_PK（整数の主キー）、Z_ENT（その行がどのエンティティ/サブクラスか）、そして Z_OPT（楽観的ロック用のバージョンカウンタ）です。属性にも接頭辞が付き — firstName は ZFIRSTNAME になります — 対1のリレーションシップは、参照先の行の Z_PK を保持する外部キー列として格納されます。

データの隣には3つの管理用テーブルがあります。Z_PRIMARYKEY はエンティティごとに1行を持ち、列は Z_ENT、Z_NAME、Z_SUPER、Z_MAX — これまでに発行された最大の主キーで、Core Data は次の挿入を割り当てるためにこれをインクリメントします。Z_METADATA は Z_VERSION、Z_UUID、Z_PLIST を保持し、Z_PLIST は NSStoreModelVersionHashes やストアの UUID を含むストアメタデータを格納したバイナリ plist の blob です。Z_MODELCACHE はコンパイル済みモデルをキャッシュします。日付は Cocoa の基準日、2001-01-01 00:00:00 UTC からの秒数を表す REAL 値として格納されます — Unix エポックではありません — なので、生のタイムスタンプ 0 は 2001年の元日です。

これらはすべて標準的な SQLite コンテナの中に存在します: 固定サイズのページ（既定で 4096 バイト）が並んだ平坦な配列で、ファイルの先頭 16 バイトはマジック文字列 SQLite format 3\000 です。ページ 1 はファイルヘッダと sqlite_master スキーマを保持し、各 Z テーブルはb-treeで、その内部ページは実際のレコードを保持するリーフページへと下向きに指しています。ポインタが1つ壊れると SQLite はファイル全体を拒否します — たとえ行で満たされたリーフページが無傷であっても。

iOS 7（および OS X 10.9 Mavericks）以降、Core Data は既定でストアを WAL モード — write-ahead logging（先行書き込みログ）— で開きます。だからこそ、1つのストアは実際にはディスク上で最大3つのファイルになります: <AppName>.sqlite、<AppName>.sqlite-wal、そして <AppName>.sqlite-shm です。この違いを理解することが、あなたの最新のデータが生き残るかどうかを決めます。

-wal ファイルは先行書き込みログです。アプリがトランザクションをコミットすると、変更されたページはメインの .sqlite に直接書き込まれるのではなく、-wal にフレームとして追記されます。それらをデータベースに畳み込み直すのは、定期的なチェックポイントだけです。その帰結として、チェックポイントの前にアプリがクラッシュしたり強制終了されたりした場合、最も新しくコミットされた行は -wal の中にだけ存在しうるのです。そのレイアウトは厳密です — 32 バイトのヘッダ（マジック 0x377f0682 または 0x377f0683、フォーマットバージョン、ページサイズ、チェックポイントシーケンス、2つの salt 値、そしてチェックサム）に続いてフレームが並び、各フレームは 24 バイトのフレームヘッダ（ページ番号、コミットフレームの場合はページ数で表したデータベースサイズ・それ以外は 0、2つの salt、2つのチェックサム）と1ページ分のデータからなります。

-shm ファイルは共有メモリの wal-indexです: SQLite が -wal 内のページを素早く見つけるために使う検索構造です。これは完全に派生データで — あなたの行を1つも保持しておらず、SQLite が -wal から自動的に再構築します。だからルールは単純です: -wal は持ち込み、-shm は無視する。まず .sqlite をドロップし、次にオプションのサイドカー枠に -wal を追加すると、そのコミット済みフレームがスキャン前に重ね合わされ、復元は最後のチェックポイントではなく最後にコミットされたトランザクションを反映します。デバイスから .sqlite だけをコピーして -wal を置き去りにするのは、最近のデータを静かに失う典型的な手口です — クラッシュからの復旧にとっても、フォレンジック抽出にとっても罠です。

SQLite の層では、ストアは2つの結果コードのいずれかで失敗します。SQLITE_CORRUPT（コード 11）は 「database disk image is malformed」（データベースのディスクイメージが不正）と出力します: エンジンがポインタをたどった先に、有効な b-tree ページではないもの — ゼロ埋めされたページ、不正なセルオフセット、ファイル長と食い違うページ数 — を見つけたということです。SQLITE_NOTADB（コード 26）は 「file is not a database」（ファイルはデータベースではない）と出力します: 16 バイトのヘッダマジックが誤っているという意味で、ヘッダのバイトが壊れた（その奥のページは無事なことが多い）か、あるいはファイルが本当に別物か暗号化されているかのどちらかです。Core Data はこれを包んで NSCocoaErrorDomain コード 259（NSFileReadCorruptFileError）— 「The file couldn't be opened because it isn't in the correct format.」（ファイルは正しい形式ではないため開けませんでした）— として表に出す一方、生の SQLite コードはエラーの userInfo 内、NSSQLiteErrorDomain キーの下に収められます。したがって、NSSQLiteErrorDomain=11 と読めるログ行こそ、これがスキーマのバージョン不一致ではなくページレベルの破損だという確証です。

復元は、壊れたファイルをその場で直そうとはしません。まだデコードできるものをすべて読み出し、まっさらな新しいデータベースに書き込みます — SQLite 自身の .recover コマンドと同じ戦略です。各 Z テーブルの b-tree を歩いてリーフレコードをデコードし、ポインタの連鎖がもう到達できないページについては生のページ走査にフォールバックして、自己記述的なレコードをファイルから直接拾い上げます。既知のテーブルに帰属させられない行は捨てられずに lost_and_found テーブルに収まり、Z_PRIMARYKEY の Z_MAX 値は復元された行から再構築されるので、アプリは主キーの衝突なしに挿入を続けられます。走査は freelist や vacuum 前のページも読むため、アプリが以前に削除した行が再浮上することもあります — 便利ですが、知っておく価値があります。

1つの正直な限界は Core Data 特有のものです。バイナリ属性（写真、PDF、音声）に 「Allows External Storage」（外部ストレージを許可）がチェックされていると、Core Data は値ごとに、バイトを行にインライン化するか、約 100 KB を超えたら別ファイルとして書き出すかを判断します。それらの外部 blob は、ストアの隣にある隠しサポートディレクトリ — .<storename>_SUPPORT/_EXTERNAL_DATA/ — の下に UUID のファイル名で保存され、データベースの行はそのファイルへの参照だけを保持し、バイトそのものは保持しません。

したがって .sqlite だけを復元すると、すべてのスカラー属性とインライン化されたすべての blob は戻ってきますが、外部に保存されたデータについては画像ではなく参照が返ります。同じアプリコンテナからの _EXTERNAL_DATA フォルダも手元にあれば、それらのファイルは名前で再びペアになります。そのディレクトリが失われていれば、そもそもデータベースの中に無かったバイトを、どんなデータベース復元も再構築することはできません。そして Core Data ストアはアプリのプライベートな状態すべて — ユーザーがこれまで保存したあらゆるメモ、メッセージ、健康記録、アカウント — を保持しうるため、これらはすべてブラウザ内で実行されます: ファイルはディスクから読まれ、タブ内で再構築され、Network タブであなたのマシンから 0 バイトも出ていないことを確認できます。