ファイル割り当てテーブルを取り返しのつかないほど失ったUSBサムドライブにmysqlデータベースを保存しました。したがって、ibdata1 ファイル全体にアクセスできません。ただし、16 進エディタを使用して使用されたレコード ページを見つけることはできます。
すべてのデータはそこにありますが、各レコードを自分で読み取り、6 か月前のバックアップから復元されたデータベースに対して新しい SQL ステートメントを再生する必要があります。
バックアップがあるので、テーブルの構造はわかっています。新しいデータベースで、おおよそバイナリ データの小さなブロックに等しいとわかっているレコードを見つけることができます。しかし、レコードの開始位置を正確に特定し、レコード データをデコードするのに問題があります。
テーブルの CREATE ステートメントは次のとおりです。
CREATE TABLE ExpenseTransactions (
idExpenseTransactions int(11) NOT NULL AUTO_INCREMENT,
TransactionDate datetime NOT NULL,
DollarAmount float DEFAULT NULL,
PoundAmount float DEFAULT NULL,
Location varchar(255) DEFAULT NULL,
MinorCategory int(11) NOT NULL,
Comment varchar(255) DEFAULT NULL,
Recurring bit(1) NOT NULL DEFAULT b'0',
Estimate bit(1) NOT NULL DEFAULT b'0',
PRIMARY KEY (idExpenseTransactions),
KEY MinorCategory (MinorCategory)
) ENGINE=InnoDB AUTO_INCREMENT=4687 DEFAULT CHARSET=utf8;
クリーンなレコードは次のようになります。
'2924', '2013-11-01 00:00:00', '60', NULL, 'George', '66', 'Lawn Maintenance', '1', '0'
このレコードに関連付けられた 16 進バイトが次にあります。レコードを再作成するのに必要以上のバイトがあることは確かですが、参照ポイントを与えるために id フィールドであると思われるものをマークしました。
10 06 02 00 01 70 00 41 80 00 0B 6C 00 00 00 00 07 05 86 00 00 01 4A 0E B1 80 00 12 4F 23 1F C1 40 00 00 70 42 47 65 6F 72 67 65 80 00 00 42 4C 61 77 6E 20 4D 61 69 6E 74 65 6E 61 6E 63 65 01 00
文字列は簡単に推測でき、MinorCategory を構成する 4 バイトを選択できます。最後の 2 バイトは 2 ビット値を表す必要があります。残りはより困難です。