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

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

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

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

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

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

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

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

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

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

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

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

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

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

>выборе reiserfs

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

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

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

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

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

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

В общем все восстановил. (почти все, некоторые некритичные каталоги не нашел, но в общем-то и не сильно искал).
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 роуминговый помегабайтный, а произошел инцидент, когда ноут срочно понадобился в дороге - в условиях сильных вибраций...

Уважуха :)