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

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

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

Выделяю под раздел 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

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