У меня сейчас действительно большие проблемы, поэтому очень бы очень понравилось ОЧЕНЬ быстрое решение. Я был в сеансе SSH на моем ноутбуке, который имеет шифрование LUKS, и я думал, что восстанавливал его заголовок. Но позже я понял, что на самом деле у меня на рабочем столе был SSH, и я случайно использовал файл резервной копии заголовка LUKS для восстановления на рабочем столе, который не имел никакого шифрования LUKS. Теперь я не могу загрузиться в мою файловую систему вообще. Можно ли как-нибудь восстановить свою операционную систему или, по крайней мере, мои файлы? Я также удалил, попытался стереть заголовок, как только понял, но это не помогло, заголовок все еще остается, просто все их ключи отключены.

64-битная файловая система Kali Linux ext4, двойная загрузка с разделом Windows 10 Раздел Kali Linux - это тот, в котором заголовок был случайно перезаписан.

Я использовал команду, которая случайно восстановила заголовок: cryptsetup luksHeaderRestore /dev/sda5 --header-backup-file header.bak

2 ответа2

0

У Mount есть возможность попробовать использовать резервный суперблок (например, -o b=40961 ), поэтому команда с доступом только для чтения плюс один из ваших резервных суперблоков, например

mount -v -o ro,b=40961 /dev/sda5 mountpoint

может быть стоит попробовать, по крайней мере, только для чтения, это не должно причинить вреда и не требует копии.


Я попытался создать небольшую (50M) файловую систему ext4, скопировав в нее около 34M в 40 файлах, а затем перезаписал первые 2M нулями (размером с резервную копию заголовка luks).

Команда e2fsck (с & без использования всех суперблоков резервного копирования с -b ) не восстановила никаких файлов. Может быть, это был маленький размер и относительно большой%, который был перезаписан, но, несмотря на то, что он был теперь монтируемым, никаких файлов там не было (даже lost+found был пуст). Другой ответ ( https://superuser.com/a/1044614/307834 ) говорит, что список файлов и каталогов, возможно, был перезаписан, и, очевидно, резервный суперблок может не помочь.

Однако Photorec удалось восстановить 33 из 40 файлов (без имен файлов), 31 были идентичны, хотя 2 были изменены (несоответствие md5). Вот ссылка на пошаговые инструкции. (Он также покажет резервные суперблоки).

Если бы у вас был резервный список всех имен файлов и хэш (например, md5 из find | md5sum или даже crc32), было бы намного проще сопоставить файлы с их именами. Конечно, лучше всего делать резервную копию самих файлов - не все системные файлы, их можно легко загрузить и заново установить, а только ваши личные данные и файлы ($ HOME?) И, возможно, некоторые файлы конфигурации в /etc ,


В любом случае, если кому-то интересно, вот несколько команд, чтобы создать небольшой ext4 и сломать его и попытаться восстановить:

$ fallocate -l 50M 50

$ mke2fs -v -t ext4 -E lazy_itable_init=0,lazy_journal_init=0 50
mke2fs 1.43.4 (31-Jan-2017)
fs_types for mke2fs.conf resolution: 'ext4', 'small'
Discarding device blocks: done                            
Discard succeeded and will return 0s - skipping inode table wipe
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
12824 inodes, 51200 blocks
2560 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=33685504
7 block groups
8192 blocks per group, 8192 fragments per group
1832 inodes per group
Filesystem UUID: b42aef3d-4e2a-44c3-8bb1-967968f61e38
Superblock backups stored on blocks: 
        8193, 24577, 40961

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

$ sudo mount -v 50  /media/50
mount: /dev/loop1 mounted on /media/50.
$ cp -ar /usr/share/backgrounds /media/50/backgrounds # 40 files totaling 34M
$ sudo umount -v /media/50 
umount: /media/50 unmounted

Сохраните оригинальный "хороший" файл для сравнения

$ cp -v 50 50-bak
'50' -> '50-bak'

Без подтверждения dd просто перезаписывает 50 с заполненным нулями файлом 2M

$ dd if=/dev/zero of=50 bs=1M count=2 conv=notrunc
2+0 records in
2+0 records out
2097152 bytes (2.1 MB, 2.0 MiB) copied, 0.00552528 s, 380 MB/s

Сохраните копию сломанного файла, чтобы повторить попытку позже

$ cp -v 50 50-broken
'50' -> '50-broken'

Запуск "e2fsck 50" "восстановит" файловую систему, но при монтировании не будет обнаружено восстановленных файлов.

Получить / перепроверить резервные суперблоки

$ mke2fs -n 50
mke2fs 1.43.4 (31-Jan-2017)
Creating filesystem with 51200 1k blocks and 12824 inodes
Filesystem UUID: 7a31ebab-ddc2-40a6-89f6-39ecc26578cc
Superblock backups stored on blocks: 
        8193, 24577, 40961

Команды e2fsck, которые должны / могут помочь:

$ e2fsck -v -b 40961 50
e2fsck 1.43.4 (31-Jan-2017)
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** journal has been deleted ***

Resize inode not valid.  Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory.  Clear<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Root inode not allocated.  Allocate<y>? yes
/lost+found not found.  Create<y>? yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  +(1--1875) +1878 +(8193--8450) +(24577--24834) +(40961--41218)
Fix<y>? yes
Free blocks count wrong for group #0 (6301, counted=6314).
Fix<y>? yes
Free blocks count wrong for group #2 (4096, counted=8192).
Fix<y>? yes
Free blocks count wrong (44438, counted=48547).
Fix<y>? yes
Inode bitmap differences:  +1 +(3--10)
Fix<y>? yes
Free inodes count wrong for group #0 (1820, counted=1821).
Fix<y>? yes
Directories count wrong for group #0 (3, counted=2).
Fix<y>? yes
Free inodes count wrong (12812, counted=12813).
Fix<y>? yes
Recreate journal<y>? yes
Creating journal (4096 blocks):  Done.

*** journal has been regenerated ***

50: ***** FILE SYSTEM WAS MODIFIED *****

          11 inodes used (0.09%, out of 12824)
           0 non-contiguous files (0.0%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
        6749 blocks used (13.18%, out of 51200)
           0 bad blocks
           0 large files

           0 regular files
           0 directories
           0 character device files
           0 block device files
           0 fifos
           1 link
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
           1 file

Монтирование по-прежнему не показывает восстановленных файлов ...
Попробуйте подключиться напрямую с резервным суперблоком (-b), но не работает ни с одним резервным блоком.

$ sudo mount -vo ro,b=40961 50 /media/50
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

# Nothing in syslog/dmesg.
0

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

Опция «сделай сам» - восстановить файловую систему из одного из резервных суперблоков:

  1. Создайте образ диска поврежденного раздела и сделайте всю работу над этим образом. Вам понадобится жесткий диск с достаточным количеством свободного места для хранения этого образа диска.
  2. Используйте losetup чтобы настроить изображение в качестве петлевого устройства. Это даст ему имя устройства, например /dev/loop0 .
  3. Запустите mke2fs -n на устройстве обратной связи, чтобы выяснить, где находятся резервные суперблоки. Вы притворяетесь, что создаете новую файловую систему здесь (опция -n ), чтобы mke2fs вам, куда она будет помещена.
  4. Запустите e2fsck -n -b <insert a superblock address here> на устройстве обратной связи с каждым из резервных адресов суперблока по очереди, пока не найдете подходящий. Здесь вы притворяетесь, что восстанавливаете файловую систему (снова -n ), чтобы посмотреть, будет ли она работать. Скорее всего, вы будете успешны с первой попытки.
  5. Перезапустите e2fsck на устройстве loopback, только без опции -n . Это восстановит файловую систему в максимально возможной степени.
  6. Смонтируйте петлевое устройство как файловую систему и посмотрите, насколько серьезен ущерб.

После того, как вы это сделали, у вас есть два варианта: вы можете повторить шаги в исходной файловой системе или скопировать нужные файлы из образа, стереть исходный файловый элемент, переустановить Kali и скопировать восстановленное файлы на него.

Безопасный вариант - отправить диск в компанию по восстановлению данных. Они будут делать в основном те же шаги, что и выше, но, поскольку они знакомы с процедурой, они не испортят. Это, вероятно, будет стоить несколько сотен долларов.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .