1.5TBのデータパーティションがあり、次のタイプミスのために誤って最初にいくつかのバイトが上書きされました。
ssh somewhere command | dd of=/dev/sda3 // should have used quotes here, dd was executed locally by mistake!
/ dev / sda3には、機密データを含む1.5TBのext4パーティション用のLUKSコンテナが含まれています。
問題が見つかったときにddを一時停止して終了しました。 4K未満でなければなりません。
データを回復する方法はありますか？それ以来、コンピュータが再起動されていませんが、失われたデータがまだRAMに残っていますか？ LUKSコンテナの最初の（例）4kには何が含まれていますか？
パーティションはまだマウントされていますが、次のエラーが表示されます。
[1157706.786897] EXT4-fs error (device dm-4): htree_dirblock_to_tree:896: inode #2: block 9249: comm ls: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2791782547, rec_len=44529, name_len=90
アクセスしようとしたとき。
助けてください！
ありがとうございます！
PS：より多くのテストをしましたが、4Kだけでなくより多くのデータが含まれているようです。 :-(しかし、1.5TBのデータはまだ非常に小さい割合です! 汚染されていない領域でデータをダンプし続けることはできますか? おそらくext4リカバリを使用できます. /dev/mapper/cr_sda3ダンプで検索するツールがある場合） - これはまだ有効ですか？
答え1
最初の実行dmsetup table --showkeys。出力を安全な場所に保存してください。表示される大きくて長い16進文字列は次のとおりです。実際暗号鍵（マスターキー）はあなたのデータを保護するために使用されます。 LUKSはその鍵をパスワードで暗号化（ここでは単純化）して機能するため、鍵が漏洩するとゲームが終了することに注意してください。パスワードを変更しても役に立ちません。 LUKSパーティションを消去して再作成する必要があります。ただし、同じ属性は、LUKS ヘッダーが完全に破損していても、対応する「テーブル」（キーを含む）を使用してデータを読み取ることができることを意味します。
探している行（ラインが多い場合があり、LVMもDevice Mapperを使用する）は次のとおりです。 0の代わりに任意の16進数を持つことになります（0は--showkeyなしで取得できます）。
Zia-swap_crypt: 0 11714560 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 253:1 0
（上記の作業は速いので、最初に実行してください。停電、機械の衝突などが発生した場合はデータを回復するために使用できます。この操作がないとデータを回復できません。）
全体のラインを維持したい。より良い点はフル出力です。dmsetup行を返してテーブルを復元すると、LUKSヘッダーなしでデータへのアクセスを復元できます。
次に画像をコピーしてください。解読されたどこかにデバイス。復号化されたデバイスは、上記dmsetupの出力で表示できる名前です/dev/mapper/Zia-swap_crypt。に入れたり/etc/fstab転送したのと同じですmount。
これで、実行中のシステムからデータをコピーできます（例：使用tar）。コピーが失敗した場合は、fsckファイルシステムの回復を試みることができます。 （その後、データをコピーします）。
そのキーを使用して動作する新しい LUKS ヘッダーを生成、再初期化、再起動できます。
今後ともご利用お願いしますcryptsetup luksHeaderBackup。