Заметки про Linux Уроки Gimp о технологическом неравноправии Национально политические проблемы и вопросы Программирование

Восстановление файловой системы

Иногда случается беда, файловая система перестаёт монтироваться хотя оборудование цело, скорее всего такое бывает от проделок "левых" программ управления разделами или от винды

Иногда получается спасти файлы и вообще восстановить работу файловой системы. Достаточно лишь восстановить таблицу файлов. Попробую на примере файловой системы размешённой в файле

Выделяю под раздел 120Mb, создаю файловую систему Ext3 и монтирую

dd if=/dev/zero of=test.img bs=1M count=120
120+0 записей считано
120+0 записей написано
скопировано 125829120 байт (126 MB), 1,65321 c, 76,1 MB/c

mkfs.ext3 test.img 
mke2fs 1.40.8 (13-Mar-2008)
test.img is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
30720 inodes, 122880 blocks
6144 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
15 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks: 
 8193, 24577, 40961, 57345, 73729

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

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

sudo mount -o loop test.img /mnt/
df -h|grep mnt
 117M 5,6M 105M 6% /mnt

Подчёркнутым текстом выделены номера блоков в которох размещены резервные копии таблиц файлов и прочих важных для файловой системы параметров, эти цифры пригодятся для восстановления данных

Заполним файловую систему данным, перемонтируем и проверим

sudo cp -R /etc/* /boot/* /var/log/* /mnt/
df -h|grep mnt
 117M 59M 52M 54% /mnt

umount /mnt
sudo mount -o loop test.img /mnt/
df -h|grep mnt
 117M 59M 52M 54% /mnt

Видим, что файловая система в порядке, данные сохранены, всё монтируется. Теперь нанесём по ней удар, разрушим таблицу файлов: запишем в начало раздело 2 килобайта мусора, опция conv=notrunc заставит dd писать по верх существующего файла - типичное поведение вендового загрузчика

dd conv=notrunc if=/dev/urandom of=test.img bs=1k count=2
2+0 записей считано
2+0 записей написано
скопировано 2048 байт (2,0 kB), 0,000716177 c, 2,9 MB/c
sudo mount -o loop test.img /mnt/
mount: вы должны указать тип файловой системы

Всё, файловая система почти уничтожена, не монтируется, не определяется. Но её можно восстановить с помощью утилиты fsck и блоков копий таблицы файлов, вот номер блоков (Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729), количество таких резервных копий зависит от размеров и настроек файловой системы, как видите номера можно просчитать зная арифметику

fsck.ext3 -b 73729 test.img 
e2fsck 1.40.8 (13-Mar-2008)
test.img was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 16703, i_size is 286720, should be 289792. Fix? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (3548, counted=3539).
Fix? yes

test.img: ***** FILE SYSTEM WAS MODIFIED *****
test.img: 10024/30720 files (0.4% non-contiguous), 63998/122880 blocks

sudo mount -o loop test.img /mnt/
df -h|grep mnt
 117M 59M 52M 54% /mnt

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