LINUX.ORG.RU

[ext4][e2fsck][horror_story]Как восстановить?


0

1

Все началось с того, что ноутбук некоторое время эксплуатировался в условиях воздействия сильных ускорений. После этого на жестком диске появились не читаемые блоки. После мыслей о том, что надо бы жесткий диск заменить, бэды были заремаплены mhdd. После прохода e2fsck обнаруженные ошибки были исправлены, поврежденные файлы перекачал и забыл о данном инциденте.
А забывать-то не следовало.
Нужно было запаковать ФС в архив, пройти жесткий диск записью, создать новую ФС и распаковать обратно, поправив fstab.
Через некоторое время начались странности - собирал линукс под ARM для марвеловского SoC и полученные образы то грузились, то не грузились, то нормально собирались только в один поток, то только в два, подумал - баги в gcc, в конце концов собрал, чтобы работало все, что мне нужно и не собирались лишние драйвера, установил на устройство и снова забыл о том, что были странные глюки.
Зря забыл.
Через некоторое время начались более серьезные странности - kernel_panic в коде ext4 через некоторое время после загрузки. Перезагрузка не помогала, загрузился в single user, перемонтировал / в ro, получив на этот раз просто OOPS и запустил e2fsck. e2fsck сказал, что filesystem is clean, но после запуска с ключами -f -p признал что ошибки есть, но засопротивлялся, сказав что все очень плохо и автоматом исправить не получится.
Вот тут бы и скопировать все, что еще читается на другой носитель, но я перезапустил e2fsck c -f -y , было очень много сообщений о том что блок используется несколькими файлами, потом были удалены поврежденные файлы и каталоги и все вроде бы закончилось, но перезгрузиться командой reboot уже не удалось. После перезагрузки через SysRq получил kernel panic из-за отсутствия init, подцепил жесткий диск к другому компу - надеялся найти свои файлы в Lost+Found - нашел, но очень мало. Каталог /home стал пустым, в Lost+Found никаких признаков его содержимого.
Прогнал photorec по пустому месту- нашлось немного файлов из домашнего каталога, но битые.
Поставил Stellar Phoenix на венду в виртуалбоксе - не нашлось даже того, что нашел photorec, вообще пусто в /home.
e2fsck показывает, что занято ~140GB и 1,5 миллиона inodes, но если смонтировать, видно только ~1.8Gb и ~200000 inodes (по данным find и du), df показывает, что занято ~140GB как и e2fsck, но файлов нигде нет. e2fsck больше не находит ошибок.
Очень нужно вытащить копии дерева исходных кодов linux с разными изменениями под железки - патчи собирался сделать, но, как на зло, не успел и отсканированные документы (несколько тысяч png, photorec по всему диску вытаскивает только битые фрагменты, а собрать деревья исходного кода linux из множества текстовых файлов без имен не представляется возможным).
Попытался разобраться в коде драйвера ext4 и e2fsck, но быстро понял, что за пару дней понять как оно работает и чего могло натворить, не удастся, а данные нужны срочно.
Прошу помощи у уважаемых лоровцев. Очень прошу.

Бро, я чуть не заплакал, читая эту простыню, ты трижды ССЗБ, ты понимаешь ведь? И бэкапа нет, верно? И код не продублирован нигде, верно?

Мой совет: первым делом снять посекторный образ винта при помощи dd и все дальнейшие операции выполнять на другом компе, но _исключительно_ с копией (даже не оригиналом) образа — иначе и без того, что есть останешься.

adriano32 ★★★ ()
Ответ на: комментарий от adriano32

Посекторный образ естественно снят, с его копией и пытаюсь работать. У меня есть некоторый опыт восстановления данных, но преимущественно чужих с вендовых разделов. Свои немного восстанавливал с reiserfs (reiserfsck --rebuild-tree и все вернулось на место).
Вопрос в том, что еще можно попробовать. Нужно содержимое домашнего каталога и желательно /etc (там wpa_supplicant.conf с ключами беспроводных сетей, настройки сетевой загрузки и тонкий тюнинг энергопотребления был сделан...)

vladisslav ()

>но я перезапустил e2fsck c -f -y , было очень много сообщений о том что блок используется несколькими файлами

После такого, ИМХО, ничего не поможет. fsck попортил таблицы с блоками, код драйвера ext4 смотреть бесполезно. У меня такое встречалось, что после e2fsck ФС система становилась хуже.

ИМХО, лучше пытайтесь склеивать что есть из кусочков, с png не знаю, но 4 кб блок кода вполне можно сравнивать с ванильным ядром.

mky ★★★★★ ()
Ответ на: комментарий от vladisslav

Посекторный образ естественно снят

Уж поздно пить боржоми..

Загляни в эту книжку или поищи подобные (с hex-листингами и объяснениями структуры записей). Авось попарсишь и понаходишь чего в raw. А там можно сцепить зубы и попробовать поправить, вписать, воссоздать записи. Ну это если принципиально другого выхода нет (в DR-контору не пойдёшь).
И да, пройдись R-TT trial'ом, посмотри, что он найдёт для сравнения.

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

adriano32 ★★★ ()
Ответ на: комментарий от anon1984

>убеждаюсь в полезности и правильном для себя выборе reiserfs, извините за оффтоп.

Типа тонко вбросил? Нет, дружок, это только тебе так кажется.
Вот сам подумай, при чём в данном случае _тип_файловой_системы_, если у ТС вместо головы жопа, в жопе мозгов нет, ну и руки, по-видимому, растут из этой жопы. Да и ты в своём анатомическом строении походе не далеко от него ушёл, мой славный любитель райзерфс)))
Удачи.

anonymous ()
Ответ на: комментарий от anon1984

>выборе reiserfs

знаешь, я тоже больше доверяю reiserfs, но и у меня есть 2 fail story с --rebuild-tree, когда в lost+found упала дай бог 1/10 файлов. Так что тип файловой системы здесь не причем - как только чувствуешь, что железо отказывает - бегом делать бэкапы, потому что в противном случае может быть мучительно больно...

Pinkbyte ★★★★★ ()

Попробуй через testdisk посмотреть содержимое ФС. Может найдёт чего. Плюс можешь грепнуть сам образ по строчке, которую ты можешь однозначно указать, что она была в wpa_supplicant.conf. man grep на предмет + и - столько-то строк от найденной. Или какой-нибудь аналог grep'а, благо их сейчас на все случаи жизни понаписали.

karbofos ()

Зато теперь ты научишься делать бекапы. Видишь, даже здесь есть позитив.

post-factum ★★★★★ ()
Ответ на: комментарий от Pinkbyte

>как только чувствуешь, что железо отказывает - бегом делать бэкапы

Бекап, который делается нерегулярно, всегда будет сделан невовремя.

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

ну так я и не ратую за то, чтобы делать бэкапы только когда настает жопа. Я имею ввиду, что если есть подозрения, что данные могут потеряться нужно не полениться и сделать бэкап

Pinkbyte ★★★★★ ()

В общем все восстановил. (почти все, некоторые некритичные каталоги не нашел, но в общем-то и не сильно искал).
r-studio нашло несколько больше, чем Stellar Phoenix, но все равно какие-то старые, давно удаленные файлы и каталоги.
Данные удалось вытащить с помощью debugfs и мелкой программки на c, которой собрал список доступных файлов и их inode numbers, таким образом определив, в каким диапазоне inode numbers искать потерянные файлы и каталоги, затем читая справку и экспериментируя с dubugfs в ro режиме прикинул, какой номер должен быть у домашнего каталога, просмотрел соответствующий inode и увидел фрагменты своего домашнего каталога. Зашел туда по inode number, вывел текущий путь - оказалось, что этот каталог лежит внутри подкаталога внутри каталога .git дерева исходных кодов linux. Поднявшись на несколько уровней выше, оказался в практически корректном домашнем каталоге, элемент которого ".." указывал туда же, куда и элемент ".." первого битого «домашнего каталога» - то есть в тот же подкаталог внутри каталога .git дерева исходных кодов linux, то есть оно оказалось зациклено. Попытки подниматься выше показали, что действительно зациклено - inode numbers повторялись. С точки зрения fsck.ext4 такая ситуация оказывается является нормальной...
Ну, а дальше все просто - командами dump и rdump вытащил свои файлы и каталоги, там же нашлась резервная копия каталога /etc, так что искать оригинал не стал.
Теперь остается вопрос - использовать ли дальше этот жесткий диск и какую ФС выбрать... Но это в другой теме.
Благодарю всех откликнувшихся ЛОРовцев за моральную поддержку, adriano32 за наиболее адекватные советы.

P.S. Тем кто кричит «ССЗБ, надо было делать бэкапы!» - делать бэкапы было просто некуда, так как перед инцидентом находился довольно далеко от цивилизации, ни других компьютеров, ни съемных жестких дисков под рукой не было, интернет только GPRS/EDGE роуминговый помегабайтный, а произошел инцидент, когда ноут срочно понадобился в дороге - в условиях сильных вибраций...

vladisslav ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.