Powered By Blogger

пятница, 28 июня 2013 г.

Восстановление информации, vmdk - xfs

Пришла беда...
Развалился RAID 1 на 1 Тб SATA винтах.
Контроллер 3ware 9550  SX на 4 SATA порта. Винты Seagate Barracuda 7200.12. Один винт помер окончательно (совсем), при подключении к компу зависало все, даже BIOS не прогружался. Второй был с убийственными показателями SMART и системой не определялся никак.
RAID использовался как хранилище виртуальных дисков *.vmdk для VMware ESXi 4.0. Гостевой системой была Ubuntu Server с файловой системой XFS, на обоих разделах виртуальных дисков. Собственно там было 2 виртуальных диска на 250 Гб и на 680 Гб. Контроллер видел тоже только один диск (физический), сейчас уже не помню что он там писал и предлагал, так как ситуация была "критическая" и информация которая хранилась на дисках была нужна срочно... Было принято решения отцепить диск от 3ware'ного контроллера, подцепить к другому компу и сделать полную копию.
Сейчас уже могу сказать, что главное в такой ситуации это сохранять спокойствие и не поддаваться панике, не реагировать на панику окружающих людей. Лучше совсем остаться одному, и хорошенько все обдумать, прежде чем что то делать. Составить последовательность действий, рассмотреть различные варианты развития событий.
Нашли новый винт на 1 Тб, стали копировать на него через Acronis Server Edition, конечно же загрузившись с LiveCD. Прошло около пяти часов и на 90% выдал ошибку, типа не могу дальше и все. Причем не предлагал пропустить нечитаемые сектора и продолжить. Хорошенько выругавшись, решил работать с тем, что удалось скопировать.
ESXi увидел оба виртуальных диска, хорошо, подумал я. Примаунтил диски к гостевой Linux, он тоже увидел виртуальные диски, и разделы на них, и файловую систему XFS, но маунтить разделы не смог, сыпался ошибками.
Что бы не терять время отрыли еще один винт на 1 Тб и стали лить вторую копию с еле дышащего винта с райда, теперь уже с помощью dd, acronis disk director уже не доверяли.
Легендарная команда: dd if=/dev/sda1 of=/dev/sdb2 bs=4096 conv=noerror 
отпахала почти 6 часов, при этом не показывая никакой информации о происходящем, наконец выдала что скопировано 800 с чем то гигов, еще сколько то гигов не смог скопировать.
Мой коллега потащил вторую копию цеплять к виндовой машине для сканирования через R-Studio. В итоге после 5 часов сканирования R-Studio нашел около 250 т. файлов (искали только *.doc и *.xls). Файлы были с рандомными именами, никакой структуры папок даже не проглядывалось, попадались файлы размером в 300 Гб... Результат можно сказать был "никакой", найти в такой куче нужные файлы было невозможно.

Тем временем первая копия диска ни в какую не хотела маунтиться к системе. xfs_alloc_read_agf и bad magic nimber in super_block - могу сказать что это ничего хорошего не означает, все очень плохо. Скажу только что перепробовал все что только можно. Несколько раз пргонял xfs_repair, с разными параметрами, толку ноль. xfs_check даже не стартовал. Тоже самое было и со второй копией диска, которую отключили от R-Studio - так как результат не устроил никого.

Тогда было решено с клонировать еле живой диск еше раз, теперь уже с помощью dd_rescue.
Прогонял в три захода:

dd_rescue --no-split --verbose /dev/sdb_bad /dev/sda_good /var/res.log
dd_rescue --direct --max-retries=2 --verbose /dev/sdb_bad /dev/sda_good /var/res.log
dd_rescue --retrim --max-retries=2 --verbose /dev/sdb_bad /dev/sda_good /var/res.log

На удивление почти мертвый винт выдержал такое надругательство на собой. Команды нашел в инете на сайте какого-то доброго человека, просто уже не помню где. Сканировал долго, при этом показывал информацию о скорости сканирования, сколько сканировал, об ошибках. Запускалась команда с Hirens BootCD Linux.
На удивление сканировал намного больше, и ошибок было всего 5, около 10 Мб нечитаемой инфы. Может повлияло то что винчестер был "вверх ногами", но не факт =)
После этого все отлично примаунтилось, xfs правда ругнулся на то что надо бы очистить журнал, но с копировалось кажется все.


Комментариев нет:

Отправить комментарий