Восстановление данных на поврежденном ext3 разделе
"Администраторы бывают двух типов: те кто не делают копий и те кто уже делает..." (Неизвестный автор)
Автор ни коим образом не претендует на оригинальность изложения материала.
Я просто искренне надеюсь что данный топик сбережет кучу нервов и денег людям по глупости или недосмотру попавшим в похожую ситуацию.
ПРЕДИСТОРИЯ
Когда-то давно давно, по просьбе одного моего близкого друга, был собран шлюз на базе обычного ПК. Поначалу ничего особенного от него не требовалось - простейший NAT, прозрачное проксирование и VPN. Время шло, потребности фирмы росли и шлюз постепенно "обростал" дополнительными сервисами - появилась почта (Postfix), затем веб сервер (Apache), база данных (MYSQL), Proftpd, BIND. За всей этой суетой естесственно никто не присматривал, не делалось никаких резервных копий не смотря даже на то, что с момента появления почты на сервере хранились копии всех писем, а BIND держал уже более десятка зон как primary так и secondary. Особенное беспокойство вызывала база данных регулярно дополняемая, а так же к ней был привязан веб сайт фирмы, за который, кстати, были так же заплачены немалые деньги. Одним словом - было что терять, и встал вопрос о резервном копировании. Тем более, что диск не резиновый и на нем просто не осталось свободного пространства.
СОБСТВЕННО ИСТОРИЯ
Друг мой, не особенно заморачивающий себе голову тонкостями системного администрирования, решил пойти по пути наименьшего сопротивления. Логика была проста - если есть в наличии точно такой же жесткий диск, идиентичный установленному на сервере, то почему бы просто не клонировать его при помощи Norton Ghost? Таким образом он рассчитывал убить двух зайцев сразу - будет резервная копия не только всех данныз, но и самой операционной системы, и в случае отказа диска на сервере время потраченное на установку системы и восстановление даннх будет минимальным, а место на основном диске можно было получить путем удаления копий писем. Сказано - сделано, остановили сервер, впихнули диск, компакт и поехали. Мысль проверить что, откуда и куда, собственно говоря, поехало пришла где-то на пятнадцатом проценте копирования, и часть данных была уже безвозвратно утеряна, диски просто банально перепутали.
Итак, что мы имеем - диск 80 Gb, на первых 15% NTFS, все остальное - то что когдато было EXT3 файловой системой со включенным журналированием. Два дня сканирования диска при помощи различных утилит не дали никакого результата. Софта было перепробовано великое множество - начиная от серьезного комерческого (не буду показывать пальцем), заканчивая бесплатными утилитами. Ни одна из программ не выдала ни килобайта полезной информации. И всего одна утилита распространяемая под GPL нашла десять из двенадцати резервных копий суперблока.
При создании EXT2 (EXT3 - это та же EXT2, только журналируемая) файловой системы утилита mke2fs помимо основного суперблока вначале файловой системы, также, по определенному алгоритму записывает копии суперблока, и копии эти равномерно распределены по всей файловой системе. Другими словами - зная как был разбит диск можно заново создать все разделы таких же размеров при помощи fdisk и при этом нетронутые копии суперблоков окажутся на "своих" местах. В моем случае были созданы такие разделы:
fdisk -l /dev/hda
Disk /dev/hda: 82.3 GB, 82348277760 bytes
255 heads, 63 sectors/track, 10011 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xa908a908
Device Boot Start End Blocks Id System
/dev/hda1 * 1 5 40131 83 Linux
/dev/hda2 6 68 506047+ 82 Linux swap / Solaris
/dev/hda3 69 10011 79867147+ 83 Linux
Теперь создаем структуры суперблока и описатели групп. Команда не для слабонервных :)
mke2fs -S /dev/hda3
Внимательно смотрим на результаты выполнения команды, нам нужны номера блоков на которых записаны копии суперблокаю
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
9994240 inodes, 19966786 blocks
998339 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=20971520
610 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424
Теперь восстанавливаем файловую систему. Для этого запускаем e2fsck с ключем -b, причем суперблок должен гарантировано быть "старым", поэтому я взял последний:
e2fsck -b 11239424 -y /dev/hda3
e2fsck начнет восстанавливать файловую систему. Все найденые файлы и каталоги будут перемещены в каталог lost+found. Естесственно имена каталогов находившихся в корне восстановить невозможно, имена будут типа #4669441, но имена подкаталогов и файлов в них сохраняются. В моем случае - мне удалось восстановить практически все данные, была утеряна только часть копий почты и системных файлов операционной системы.
