Вопросы Теги

Восстановление файлов, удаленных с помощью rm (, даже с зашифрованного диска LUKS -)

Спасибо, Эммануэль Роза, за ваш комментарий, вы указали мне правильное направление.

После запуска очистки смонтированного тома
btrfs sc start -Bd /dev/mapper/bckp

Вот такой результат:
scrub device /dev/mapper/bckp (id 1) done scrub started at Thu Sep 12 13:28:38 2019 and finished after 05:12:29 total bytes scrubbed: 3.02TiB with 0 errors

Нет ошибок или предупреждений в журналах.

Итак, я снова запустил проверку btrfs и, наконец, получил чистый результат:
bf ch -p /dev/mapper/bckp Opening filesystem to check... Checking filesystem on /dev/mapper/bckp UUID: 4b793176-530a-4a82-b156-3363db035760 [1/7] checking root items (0:01:27 elapsed, 5102746 items checked) [2/7] checking extents (0:04:15 elapsed, 969366 items checked) [3/7] checking free space cache (0:00:32 elapsed, 4871 items checked) [4/7] checking fs roots (0:09:14 elapsed, 720718 items checked)ked) [5/7] checking csums (without verifying data) (0:00:29 elapsed, 1557593 items checked) [6/7] checking root refs (0:00:00 elapsed, 222 items checked) [7/7] checking quota groups skipped (not enabled on this FS) found 3308474904576 bytes used, no error found total csum bytes: 3214237436 total tree bytes: 15878373376 total fs tree bytes: 11854004224 total extent tree bytes: 553287680 btree space waste bytes: 2253478467 file data blocks allocated: 49609008967680 referenced 4863848071168

Моя программа:
btrfs version
btrfs -проги v4.19

uname -rom
4.19.57 -gentoo x86 _64 GNU/Linux`

Таким образом, FS снова чист и пригоден для использования без каких-либо предупреждений, спасибо за помощь.

0
27.11.2021, 20:12
1 ответ

Мне удалось восстановить многие, а то и все файлы, потерянные с помощью 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заработало. Я не знаю точно, что я сделал, но это сработало, поэтому я не буду подчиняться.

При втором запуске photorecя просто следовал указаниям мастера. Я просто выбрал варианты, которые, как я предполагал, дадут мне наилучший результат, и у меня нет их полной истории, поэтому я просто напишу то, что, как я уверен, я сделал.

  • выберите правильное устройство(/dev/mapper/pc--vg-root)
  • выбрать правый раздел(ext4)
  • выберите правильную файловую систему раздела([ ext/ext3 ] ext2/ext3/ext4 filesystem)
  • выбрать сканирование только нераспределенного пространства ([ Free ] Scan for file from ext2/ext3 unallocated space only), так как мне не нужно было восстанавливать не удаленные файлы
  • выбрал позицию для записи восстановленных файлов в

В какой-то момент я также выбрал типы файлов, которые я хотел восстановить (text и PDF ).

После нескольких часов анализа и восстановления photorecдоставил мне несколько сотен подкаталогов (recup_dir.<nnn>, где <nnn>— возрастающий номер ), заполненный файлами со случайными -именами и правильным расширением (Например,f582010347.txt— это текстовый файл, который я сохранил под правильным именем ). Я проверил некоторые случайные файлы, и похоже, что я вернул все текстовые файлы, которые у меня были на диске, даже неудаленные (, включая /etc/ssh/sshd_config, например ), переименованные со случайными -выглядящими именами и, очевидно, случайно отсортированы по подкаталогам, и в сумме они составляют более 80 ГБ. Но, по крайней мере, они у меня есть.

В ближайшие дни попробую их автоматически отфильтровать, чтобы найти нужные. Я сделал несколько быстрых попыток и добился хороших результатов с 

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

где:

  • string— это строка, которая, как я знаю, присутствует в файле, который я хочу восстановить
  • restore_path— это путь, который я указал photorecдля записи восстановленного файла

Добавив параметры от --textдо grep, я также смог определить некоторые PDF-файлы, которые мне нужно восстановить. Однако я знаю, что, поскольку PDF являются двоичными файлами, это, вероятно, не позволит мне вернуть их все.

В конце концов, все прошло гораздо лучше, чем я предполагал. Урок, который я усвоил :мои регулярные резервные копии не защитят меня от самого себя. Кроме того, хорошей идеей может быть использование псевдонимов rmдля чего-то менее опасного(this выглядит интересно ).

0
28.11.2021, 20:20

Теги

Похожие вопросы