Случайно восстановленный заголовок LUKS в обычной файловой системе

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

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

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

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

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

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

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 from 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 с заполненным нулями файлом 2М

$ 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.