Компьютерная промышленность выпускает все более быстрые и надежные
средства хранения информации. А программисты (будем к ним
снисходительны и немного приукрасим действительность) пишут все
более помехоустойчивые и дуракоупорные операционные системы. Линукс,
например.Но иногда все же и с ними случаются ЧП. Прогулявшаяся по
клавиатуре кошка случайно стирает важный файл - результат
многодневной работы. Неправильно набранная команда записывает мусор
на место файловой системы. Глюкнувший драйвер приводит ее в красивое
и загадочное, но совершенно бесполезное состояние. Запущенная после
полугодового перерыва ради последней DirectX-игрушки Windows
приносит с собой вирус CIH, начисто уносящий таблицу разделов. Что
делать?

 Под DOS/WINDOWS за время их существования наросло множество
утилит, облегчающих восстановление данных - от известного каждому
продвинутому владельцу компьютера Norton Disk Doctor-а до аварийных
монстров типа Tiramisu Desktop. Их употребление широко
распространено и общеизвестно.

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

Впрочем, все не так страшно. Некоторые (а при ближайшем
рассмотрении, весьма даже приличные) средства для восстановления в
линухе есть. Ниже я привожу свои комментарии и советы по поводу
некоторых характерных случаев и важных моментов этого дела. Основаны
они как на печальном личном опыте, так и на собрании разрозненных
приемов из различных источников. Надеюсь, эти заметки кому-то
окажутся полезными.



1) Делайте резервные копии.

Пункт первый и тривиальный, он, тем не менее заслуживает самого
пристального внимания. Всегда легче и надежнее "восстановить"
пропавшую информацию, просто переписав с резервного экземпляра, чем
судорожно шарить по поверхности жесткого диска в поисках пропавших
секторов. Мы договорились, что возможности производить резервное
копирование полностью и систематически у вас нет. Но это еще не
значит, что у вас нет вообще никаких возможностей для копирования.

Для начала - вам вовсе не обязательно сохранять все содержимое
диска. На самом деле, большинство программ у вас уже есть в
дистрибутиве, а которых нет - все равно куда проще скачать и
установить свежую версию, чем что-либо восстанавливать. Иерархия
каталогов расположена так, чтобы облегчить резервное копирование. По
всей видимости вы заинтересованы в сохранности своей собственной
работы - содержимого каталога /home. Возможно, если вы долго
настраивали свою систему, то некоторый интерес может представлять и
/etc. Содержимое /usr по определению не должно представлять никакого
интереса для бэкапа, а /var содержать только быстро
возобновляемую/генерируемую/получаемую информацию, которая тоже не
стоит того, чтобы тратить время на ее восстановление. Все, это
конечно, в том случае, если вы сами не нарушили этот стандарт. Но и
из своего /home вам нужно сохранить также далеко не все. Посмотрите
внимательно на его содержимое. Может статься и так, что все
действительно важное легко поместится на одной-двух дискетах.

Проявите фантазию и напрягите воображение при выборе места для
резервного копирования. Держите копию домашних данных на работе, а
рабочих - дома. Записывайте регулярно накопившиеся архивы на
компакт-диск. Копируйте особо важные данные хотя бы просто на другой
диск на той же машине. Заведите бесплатный почтовый ящик на одном из
серверов, предоставляющих такие услуги, и пошлите себе письмо с
важной информацией. Делитесь своими разработками со знакомыми (этот
способ особенно рекомендует Линус Торвальдс :-) ).

2) Случайно стертый файл.

Увы, в этом случае свобода маневра существенно ниже чем в досе.
Просто взять и восстановить нужный файл не получится - имена файлов
и сами файлы в юниксах есть совершенно разные сущности. Как
следствие - найти удаленный файл по имени невозможно. Можно искать
только по размеру, типу, времени удаления, правам итд.

Подробно процесс восстановления удаленных файлов с помощью
стандартного средства - утилиты debugfs, описан в "Linux Ext2fs
Undeletion mini-HOWTO"
(http://pobox.com/~aaronc/tech/e2-undel/howto.txt) и состоит из
множества довольно кропотливых шагов.

К счастью, написано несколько средств, в значительной степени
автоматизирующих этот процесс, таких, как, например, recover
(http://www.linuxave.net/~recover/), unrm (http://hideout.art.ro/).

Впрочем, наиболее удобное из них встроено в Midnight Commander.
Единственная сложность с ним заключается в несколько неочевидном
способе его запуска. Для этого нужно из-под пользователя root (чтобы
иметь прямой доступ к файловой системе) в командной строке программы
набрать команду.

 cd /#undel:<имяраздела>

 имя нужно писать без части /dev/, то есть, например, для
первого раздела первого ide-диска это будет

 cd /#undel:hda1

После этого можно будет рассматривать получившийся список файлов,
ища в них наиболее подходящие.

Да! - все эти манипуляции настоятельно рекомендуется (если не хотите
еще сильнее усугубить ситуацию, повредив еще и файловую систему)
выполнять в single-user mode на отмонтированном, или, в крайнем
случае, примонтированном как read-only разделе.

3) Использование своп-раздела.

Редко когда на машине бывает достаточно свободного места, чтобы
обеспечить свободу маневра при восстановительных работах. Однако,
учитывая, что на время этих работ нормальной, загруженной работы
машины все-равно не предвидится, можно использовать важный
внутренний резерв - раздел для свопинга. В современных машинах этот
раздел достигает сотен мегабайт, и для работы мелких системных
утилит он совершенно не нужен. Можно его отформатировать и
использовать для хранения информации, восстанавливаемой с других
разделов, можно, в случае тяжелых повреждений корневого раздела,
установить там маленькую линукс-систему и дальнейшую работу вести с
нее (что гораздо удобнее, чем загружаться с rescue-дискеток.), можно
делать то и другое одновременно.


4) Физически поврежденный диск.

Может случиться так, что, диск, на котором окажутся ваши данные,
будет поврежден. Характерной опасностью в таком случае, оказывается
то, что сам по себе любой доступ к этим данным, даже вроде бы только
для чтения, будет для них разрушителен - дефектная головка царапает
поверхность диска и наносит ей новые повреждения. Или же - хитрая
электроника современных жестких дисков по собственной инициативе
пытается вывести поврежденный участок из обращения и.....далеко не
всегда это приводит к благоприятным результатам. Поэтому первое, что
надо сделать в таком случае - скопировать все важное, что только еще
цело в другое, безопасное место.

Если есть достаточное количество свободного места, разумным будет
сначала скопировать полностью образ раздела в файл на другом
разделе, а потом уже при попытках восстановления работать с этим
файлов, обращаясь с ним как с файловой системой при помощи
loopback-драйвера. Для такого копирования следует использовать
системную утилиту dd, которая в отличии от обычных команд
копирования, корректно перенесет (или, по крайне мере попытается это
сделать) также и поврежденные блоки, а не прекратит свою работу на
полпути.

5) Тяжелые повреждения файловой системы ext2.

Ну здесь все вроде бы ясно. Есть программа e2fsck для
восстановления, ее надо запустить и она все сделает, есть debugfs
для тонкой расчистки, им можно ковырять отдельные дефектные элементы
файловой системы. Все-таки, несколько деталей.

Если начало файловой системы сильно разрушено, вместе с ней может
оказаться разрушен и суперблок, в котором хранится вся важнейшая
информация о файловой системе. e2fsck в таком случае вообще
откажется воспринимать раздел как файловую систему.

К счастью, в юниксовых файловых системах суперблок, именно
вследствие своей важности, многократно дублируется. Копии суперблока
расположены на разделе через одинаковые промежутки, зависящие от
размера блока, равные некоторой степени двойки. То есть можно
запомнить, каких размеров должны быть промежутки при каждом размере
блока, но гораздо приятнее непосредственно найти их по сигнатуре с
помощью программы findsuper, входящей в стандартный пакет
ext2fstools. Программа эта выдаст список похожих на суперблок
блоков, и по ним уже достаточно просто определить, где идет
суперблок, а где случайное совпадения, зная о равномерном
распределении суперблоков.

Найдя суперблок, можно указать его программе e2fsck при помощи ключа
-b. Обычно в таких случаях e2fsck полезно запустить два раза -
сначала с ключом -n для того, чтобы проверить, что указание этого
суперблока дает осмысленные результаты, а затем с ключом -y, чтобы
произвести собственно изменения. Имеющаяся в программе возможность
интерактивно управлять работой e2fsck в здесь обычно неполезна,
поскольку осмысленный ответ на задаваемые вопросы может быть дан
лишь при очень глубоких знаниях по поводу устройства ext2fs вообще и
данной конкретной файловой системы в частности.

В каталоге lost+found ищите файлы, которые e2fsck не смогла
поставить на вполне правильное место. После восстановления таким
образом работоспособности файловой системы в этом каталоге (впрочем,
как и в любом другом месте) часто остаются файлы со странными
именами и правами, которые не может удалить даже root. Файлы эти
выкорчевываются посредством debugfs (не забудьте отмонтировать
отлаживаемый раздел, или, по крайне мере, перевести его в
read-only).


6) Разрушение таблицы разделов

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

Есть, впрочем, и программы, которые облегчают восстановление,
пытаясь сами определить границы между разделами. Назову такие как
TestDisk
(http://www.esiea.fr/public_html/Christophe.GRENIER/testdisk.html) и
gpart, http://www.stud.uni-hannover.de/user/76201/gpart/.

Важный момент, на который следует обратить внимание - на разных
машинах геометрия диска может выглядеть совершенно по разному.
Разные типы BIOS, производят разную трансляцию между
характеристиками реальными, и допустимыми BIOS. На нормальном диске
сведения о геометрии можно получить как раз из таблицы разделов, но
здесь она стерта и каждый выдумывает, во что горазд. Следствие -
восстанавливать таблицу надо именно на той машине, на которой диск
форматировался и работал. А если уж это невозможно, то, хотя бы,
тщательно переписать в настойках BIOS параметры геометрии и вручную
выставить их на машине, где будет происходить восстановление.

Также следует обратить внимание на такой замечательный ресурс, как
Partition Rescue Mini-HOWTO
(ttp://www.linux-france.org/article/jdanield/partition-rescue-mini-HOWTO.htm)
где этот вопрос изложен со всей подробностью и детальностью.