rmを使用して削除されたファイルを回復する（LUKS暗号化ディスクでも可能）

Question 1

また、sudoはfsck -N/dev/sdaXでのみ動作したいと思います。

これは言葉ではありません。e2fsckすべてのブロックデバイス、さらには画像ファイルでも動作します。

画像に元に戻せない書き込みを行わないでください。スワップボリュームを削除し、VGの空き容量を活用してpc--vg-rootスナップショット（）を作成することをお勧めしますlvcreate --snapshot ...。その後、e2fsck実際のデータではなくスナップショットに対して実行できます。問題が発生した場合は、スナップショットを破棄して再開できます。

私は慣れていませんextundelete。クイック検索ではサポートする必要があるとマークされていますが、ext4メッセージはWARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.サポートされていないか気に入らないかのように聞こえますext4。これはとても古いバージョンですかextundelete？

したがって、最初に実行してe2fsckメッセージExtended attribute has an invalid value lengthがまだ存在する場合は、最新バージョンを入手してくださいextundelete。

この質問全体は LUKS と暗号化とは全く関係がないので、質問のタイトルを変更することをお勧めします。

Answer

また、sudoはfsck -N/dev/sdaXでのみ動作したいと思います。

これは言葉ではありません。e2fsckすべてのブロックデバイス、さらには画像ファイルでも動作します。

画像に元に戻せない書き込みを行わないでください。スワップボリュームを削除し、VGの空き容量を活用してpc--vg-rootスナップショット（）を作成することをお勧めしますlvcreate --snapshot ...。その後、e2fsck実際のデータではなくスナップショットに対して実行できます。問題が発生した場合は、スナップショットを破棄して再開できます。

私は慣れていませんextundelete。クイック検索ではサポートする必要があるとマークされていますが、ext4メッセージはWARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.サポートされていないか気に入らないかのように聞こえますext4。これはとても古いバージョンですかextundelete？

したがって、最初に実行してe2fsckメッセージExtended attribute has an invalid value lengthがまだ存在する場合は、最新バージョンを入手してくださいextundelete。

この質問全体は LUKS と暗号化とは全く関係がないので、質問のタイトルを変更することをお勧めします。

Question 2

私は失われた多くのファイル（おそらくすべて）を回復しましたphotorec。見つからないフォーラムページでこれを読んで、「この他のツールも使ってみよう」と思いました。

私は走った

$ sudo kpartx -a -v image.iso # map the disk image partitions
add map loop0p1 (254:0): 0 997376 linear 7:0 2048
add map loop0p2 (254:1): 0 2 linear 7:0 1001470
add map loop0p5 (254:2): 0 975769600 linear 7:0 1001472

$ sudo cryptsetup luksOpen /dev/mapper/loop0p5 img # unlock the partition with my data
Enter passhprase for /dev/mapper/loop0p5:

$ lsblk
NAME                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0                   7:0    0 465,8G  0 loop
├─loop0p1             254:0    0   487M  0 part
├─loop0p2             254:1    0     1K  0 part
└─loop0p5             254:2    0 465,3G  0 part
  └─img               254:3    0 465,3G  0 crypt
    ├─pc--vg-root   254:4    0 464,3G  0 lvm
    └─pc--vg-swap_1 254:5    0   980M  0 lvm

[...omitting other lsblk output...]

$ sudo vgchange -a y pc-vg
  2 logical volume(s) in volume group "pc-vg" now active

パーティションを準備した後

$ sudo photorec

EXT3に関して初めてエラーが発生したときに覚えていません。私は走ろうとし、sudo fsck -r /dev/mapper/pc--vg-root質問の更新に書いたのと同じ結果を得ました。しかしそれはうまくphotorecいきました。正確に何をしたのかわかりませんが、うまくいったので従わないでしょう。

2回目の実行ではphotorecウィザードに従いました。最善の結果が得られると思われるオプションを選択しただけで、全体の履歴がないので、私が確信するオプションだけを書きましょう。

正しいデバイスの選択（/dev/mapper/pc--vg-root）
正しいパーティションを選択してください（ext4）。
正しいパーティションファイルシステムを選択してください（[ ext/ext3 ] ext2/ext3/ext4 filesystem）。
[ Free ] Scan for file from ext2/ext3 unallocated space only削除されていないファイルを回復する必要がないため、未割り当て領域（）のみをスキャンするように選択します。
回復したファイルを書き込む場所を選択

ある時点では、回復したいファイル形式（テキストとPDF）も選択しました。

数時間の分析と回復により、任意の名前と正しい拡張子を持つファイル（たとえば、正しい名前のテキストファイルとして保存されていることがわかっているファイル）で埋められた数百のサブディレクトリ（、増分番号はどこにありますか？）photorecを取得しました。です。いくつかのランダムファイルを調べましたが、削除されていないテキストファイル（例を含む）、見かけ上ランダムな名前で名前が変更され、サブディレクトリからランダムにソートされたファイルまで、ディスク上のすべてのテキストファイルが再インポートされたようです。合計80GB。しかし、少なくとも私はそれらを返しました。recup_dir.<nnn><nnn>f582010347.txt/etc/ssh/sshd_config

今後数日間自動的にフィルタリングして、必要なものを見つけようとします。私はいくつかの迅速な試みをし、良い結果を得ました

$ grep --ignore-case --recursive -B5 -A5 'string' restore_path

どこ：

string復元するファイルに存在することがわかっている文字列です。
restore_pathphotorec回復ファイルを作成するために指定したパス

--textオプションを追加した後、grep回復する必要のあるPDFも識別できました。しかし、PDFはバイナリファイルであるため、PDFをすべてインポートできない可能性があることを知っています。

その結果、私が想像していたよりもはるかに良い結果が出ました。私が学んだ教訓は、定期的なバックアップが自分自身から私を守ることができないということです。また、rm危険性の低いアイテムの代わりにエイリアスを使用することをお勧めします（これ面白そうですね）。

Answer