Всем магам и чародеям - доброго времени суток.
Ситуация бональная:
Упаль и не хочет подниматься.
Инфа военно-коммерческая секретная, про бэк-апы ессесно никто не знал, что такое ноу-хау уже придумали.
Пострадавший висел на АСП11 линухе. Странно довольно всё произошо: комп за последние 3 суток завис раз 10, но пару раз была ситуация, что комп жутко начинал тормозить и ядро плевалось в консоль руганью на dma. Очень похоже было на то что безпардонно отваливался винт. Лечилось это горе ресетом.
До этого наблюдались странности не более чем раз месяц, грешили на память, а при отсутствии замены и требованию к компу 24/7 - онлайн, возможности поковырять не было :(
Вообщем, клиент - в коме, а воскрешать нужно срочно - очень срочно, или смерть на костре инквизитора с прилягающими садо-издевательствами.
Сутки уговариваю гугла выдать мне страшную тайну, и в серче "открытых сетей" не вижу ответа ;(
Воть, и приходится обращаться с проблемами к гуру-шаманам.
Итак, опишу что я делал и что я получил, и в результате к каким выводам пришел.
Пробовал раз 5 сделать старт. Комп вис после слов "граб лодинг... плиз вэйт..."
Установл винт(samsung 20Gb) в другой системник - картинка аналогичная, загрузился c RIPlinux , в биосе отключил ДМА и PIO (вроде так было там) - установил в MODE-0
разделы существуют /dev/hda, hda2 -exten. dos (type=5), hda5 -vfs 1Gb (82), hda6 - (83) корень на ~17-18 Гб.
#mount /dev/hda6 /mnt/zzz
EXT3-sf error (device hda6): ext3_check_descriptors: Block bitmap for group 128 not in group (block 41471)!
mount: wrong fs type, bad option, bad superblock on /dev/hda6,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg |tail or so# dmesg |tail -1
EXT3-fs: group descriptors corrupted!начал много читать... в жизне столько не читал в захлёб - неотрываясь целые сутки, без перерыва
С dd`шил, сделал 2 прохода ddrescue c "-n" и "-r 1" - итого: ни единого беда.
Долго курил, потом еще дольше курил доку на testdisk, после шаманских тыканий смог в тестдиске просмотреть корневой раздел, всё на месте и как должно быть.
долго ходил, 3-4 часа, вокруг MBR`a:
/dev/hda1 : start= 0, size= 0, Id=0
/dev/hda2 : start= 1008, size= 39178944, Id= 5, bootable
/dev/hda3 : start= 0, size= 0, Id=0
/dev/hda4 : start= 0, size= 0, Id=0
/dev/hda5 : start= 1071, size= 2097585, Id=82
/dev/hda6 : start= 2098719, size= 37081233, Id=83не знаю как должно быть, но мне кажеться - красиво. Да, и fstab сказал что всё ОК.
А вот тестдиск при анализе впаривает hpfs-ntfs и в таком варианте не хочет показать содержимое диска! а если восстановить старый тут же, то нормально показывает корневой раздел! отлично бегает по каталогам!
Казёл - дразнится, а не даёт! скинуть.
Пришел к выводу что оригинальный винт впорядке, т.к. симптом загрузки тот же, бежов небыло, образ отрывается тестдиском дочно так же, и раздел hda6 на mount, fsck.ext3 реагирует совершенно идинаково!
Реакция на:
#fsck.ext3 /dev/hda6
/sbin/e2fsck: Group descriptors look bad... tryng backup blocks...
Block bitmap for group 128 is not in group. (block 41471)
Relocate<y>?
Inode bitmap for group 128 is not in group. (block 29)
Inode table for 128 is not in group. (block 1206961624)
WRNING: SEVER DATA LOSS POSSIBLE.
....
и так до group 141 , часто говорит на блок 0
и самый последний мат:
/sbin/e2fsck: e2fsck_read_bitmaps: illegal bitmap block(s) for /dev/hda6если запустить с флагом -n , то упераеться в инод 2093056 со словами "не могу прочитать следующий" и делает себе аборт.
еще в тестдиске заметил разницу:
partition - start - end - size in sectors
* HPFS - NTFS - 0 1 1 - 2437! 254 63 - 39166407
L Linux Swap - 0 17 1 - 130 161 63 - 2097585
L Linux - 130 163 1 - 2438! 213 63 - 37081233я в разметках диска, секторах, блоках и суперблока - полный буд, вообще не могу понять как они считаются, но понимаю что всё пляшет от 1 байт = 8 бит, а 1 кб = 1024 байт
нашел интересную ссылочку http://darkk.livejournal.com/28545.html но не могу вникнуть в последний скрипт, что он делает, думаю реализовать.Может кто умнее в этом деле может меня поставить на путь истенный? а то уже запутался в собственных догадках :(
Думаю принести кровавую жертву, своего кота, злому дух на этом три-чёртовом винте!!! не знаю какое заклинание выбрать... кот то один ;(
Может быть попробовать средствами загрузочного диска АСП 11 ? Есть на нем восстановление системы? же,
>[оверквотинг удален]
>байт
>
>нашел интересную ссылочку http://darkk.livejournal.com/28545.html но не могу вникнуть в последний скрипт, что
>он делает, думаю реализовать.
>
>Может кто умнее в этом деле может меня поставить на путь истенный?
>а то уже запутался в собственных догадках :(
>
>Думаю принести кровавую жертву, своего кота, злому дух на этом три-чёртовом винте!!!
>не знаю какое заклинание выбрать... кот то один ;(
>Может быть попробовать средствами загрузочного диска АСП 11 ? Есть на нем
>восстановление системы? жеОбычные средства не помогают, тот-же чекдиск вроде как делает исправления, после ребута всё по старому
при работе в программе тестдиск винт читается, но в рутовый, и хоме каталог попасть не возможно проблемма с правами, какраз там нужная инфачто делать, помогайте
тестдиск может показать только половину винта, Но home, root и var не читаються, показывает что на них права доступа изменились(нет выполнения и т.п.), не открывается. А вот остальное всё естьпри анализе тестдиском, если ему сказать, что фс-система создана из висты, то вторая половина винта оцениваеться сплошной ошибкой. Если нет - то всё отлично, но всеравно он пытаеться всунуть нтфс.
могла ли нарушиться адресация секторов или разметка, и получаеться что тестдиск не использует эту инфу, а сам может чёто поверхнасно выудить и показать???
всё аналогично http://www.mrctr.upmc.edu/mrrc/computing/linuxguide
а вот тут вообще чела послали... http://expert.mandriva.com/question/71376
при попытке сканировать с других супер блоков - приходит сообщение о том что устройство занято, хотя его совсем ничего не может использовать
псмотрел на smart, увидел 4 сектора в Reallocated Sectors Count столбца raw.
думаю, что из-за этого какойто начальный сектор был перенесен, а его инфа нет.
дальнейший поиск инфы увёл от тематики никсов, т.к. ничего не могу найти подходящего для линукса, но на всякий случай http://articles.softportal.com/article-481.html
может комунить пригодится.
На мандриве сказали челу что винт убитый. А если попробовать на другой хард систему установить и из нее примонтировать раздел с инфой?
>Думаю принести кровавую жертву, своего кота, злому дух на этом три-чёртовом винте!!!
>не знаю какое заклинание выбрать... кот то один ;(Не смей мучать кота, иначе все твои винты накроются, а серверная сгорит в праведном пламени!
Если серьёзно - перестань страдать фигнёй и срочно беги к нормальному специалисту по восстановлению данных, кто имеет представление линуксовых фс. А так только время безтолку тратишь.
Харьков - большая деревня в ИТ-технологиях, даже не село.
есть только 1 "контора" которая это делает, и-то, без гарантий, с ехт3 не работали но попробовать могут - не вариант короче.
думаю, я уже больше их знаю теории.
щас гоняю с под винды, все преславуты "проги" - фекалий (сорри) r-studio показала что накрылись иноды 7 и 8, папку рут не открывает, вар видит как файл. изирекавери - отстой - делает в рав режиме поиск файлов по формату. а мне нужны sh,prs и мускуловские бд.
тестдиск намного лучшей результат показал. думаю нужно отключить gdb в смарте, и сделать обычное чтение, после чего выдрать всё необходимое. не могу ничего толком найти для отключения смарта или сброса таблицы raw или как там её.
А отправлять винт в киев или в москву или еще куданить - не вариант - неделя минимум, я за дня 3 смогу, в принципе, на писать - самая важная часть инфы случайно была сохранена на кануне траблы.
1) если уже не поздно (надо было сделать это сразу, прежде чем запускать чекдиски и т.п.)
нужно снять двоичный дамп разделов, подключив диск к здоровой машине на которой работет Linux (или загрузившись с LiveCD/USB-flash - например с помощью RIPLinux)
dd if=/dev/hdaх of=/tmp/hdax.bin bs=4096
где x - номер раздела (кроме расширенного который у вас hda2)2) Если ценная информация текстовая, её возможно удастся восстановить
с помощью поиска по ключевым словам в дампе полученном в п.13) пытаться монтировать поломанную ФС - пустая трата времени
сначала нужно прогнать на ней e2sck c опциями -fp или -fy
возможно поможет опция -b с указанием смещения до резервных копий суперблока
Желательно использовать е2fsck свежих версий
(из того же RIPLinux только берите свежую версию)4) отключать DMA в BIOS без толку так как ядро работает с дисками минуя BIOS
для отключения используйте hdparmКак показывает практика, вероятность 100% восстановления данных при таких сбоях невелика
Начинйте думать о том, чтобы начать установку системы с нуля
всё это делал, как догадываюсь, смарт отрезал 4 секотра это около 35-40 мб данных, и похоже что системных и журнала.
щас из-под винды вытягиваю часть инфы zar 8.3 http://forum.ru-board.com/topic.cgi?forum=35&bm=1&topic=5261... большая проблема с кллючём к этой тулзе, она вроде хавает его,но не реагирует на него :(
Я вот тут думаю, если вытащить бд-мускула файлами, то потом если их просто вкинуть, они могут не открываться. на 3 мускуле такое канало, на 4 вроде была какаято проблема, уже не помню, но что то не получалось. а у меня там 5.20 - 5.50. может еще какиенить нужны ключи или чтонить к мускулу? может ктонить сталкивался?
>Я вот тут думаю, если вытащить бд-мускула файлами, то потом если их
>просто вкинуть, они могут не открываться. на 3 мускуле такое канало,
>на 4 вроде была какаято проблема, уже не помню, но что
>то не получалось. а у меня там 5.20 - 5.50. может
>еще какиенить нужны ключи или чтонить к мускулу? может ктонить сталкивался?
>Если файлы БД будут небитые, их вполне можно подсунуть на работающий сервер
при условии
1) Совпадает версия MySQL (по крайней мере базовая версия)
2) Настройки упавшего сервера (/etc/my.cnf) совпадают с настройками рабочего
3) Если используется InnoDB обязатально нужно заменять целиком весь каталог данных MySQL а не только подкаталог с конкретной БДПеред заменой файлов БД
1) проверить текущий каталог БД (datadir)
mysql -uпользователь -hхост -pпароль --execute="show variables like 'datadir';"
2) остановить запущенный сервер (/etc/init.d/mysql stop)
3) удалить содержимое datadir (не забываем делать кпию если там что-то полезное есть)
4) копируем в datadir файлы БД с упавшего сервера
5) запускаем mysql (/etc/init.d/mysql start)
>[оверквотинг удален]
>а не только подкаталог с конкретной БД
>
>Перед заменой файлов БД
>1) проверить текущий каталог БД (datadir)
> mysql -uпользователь -hхост -pпароль --execute="show variables like 'datadir';"
>2) остановить запущенный сервер (/etc/init.d/mysql stop)
>3) удалить содержимое datadir (не забываем делать кпию если там что-то полезное
>есть)
>4) копируем в datadir файлы БД с упавшего сервера
>5) запускаем mysql (/etc/init.d/mysql start)Благодарю! я тогда пробовал одну базу перекидывать, так и подумал что нужно все базы вытягивать... прото, думал, что базы могут ложиться в фалы в шифрованом виде, а для их чтения может требоваться ssl ключ или еще какаянить ерунда.