Преамбула:
Был у меня сервер, с начала запуска прошло буквально 1 неделя, по этому организовать более или менее грамотную систему резервного копирования я еще не успел. Хотя и резервная копия осталась, недельной давности. В оригинале я конечно привык ставить RAID-массив, но в этот раз я надеялся на столь стабильную платформу как ESX, посчитав что будущая неделя ничего нового не преподнесет. Да и сервант не такой серьезный что бы ставить RAID (впрочем есть сомнения в его полезности в данном случае). Подключить к блоку бесперебойного питания тоже еще не удосужился, ибо не была бы эта статья из разряда о «Законе Мерфи» или «Законе подлости», по русски говоря. Ну и я конечно же глубоко ошибся в своей спокойности происходящего. Внеочередной скачек электричества вскоре дал о себе знать. Переставил диски, развернул резервную копию недельной давности. Жесткие диски отправил на разбор полетов. Разбором полетов я занимался 2 месяца, меня попросту взял азарт и уверенность в себе. По этому все эти 2 месяца я пытался восстановить данные с файловой системы VMFS 5-версии. Что только я не перепробовал за это время, это были и всевозможные программы по ремапингу диска от битых кластеров, и драйвера под VMFS чтобы вытащить хотя бы образ VMDK. Горький опыт как всегда приходит поздно, но он приходит не один, он приходит с уверенностью в достижении своей цели, о которой сегодня я с Вами и решил поделится. Но как мои читатели знают, я обычно оперирую "голыми" фактами и философствовать не люблю, по этому приступим к восстановлению данных:
Был у меня сервер, с начала запуска прошло буквально 1 неделя, по этому организовать более или менее грамотную систему резервного копирования я еще не успел. Хотя и резервная копия осталась, недельной давности. В оригинале я конечно привык ставить RAID-массив, но в этот раз я надеялся на столь стабильную платформу как ESX, посчитав что будущая неделя ничего нового не преподнесет. Да и сервант не такой серьезный что бы ставить RAID (впрочем есть сомнения в его полезности в данном случае). Подключить к блоку бесперебойного питания тоже еще не удосужился, ибо не была бы эта статья из разряда о «Законе Мерфи» или «Законе подлости», по русски говоря. Ну и я конечно же глубоко ошибся в своей спокойности происходящего. Внеочередной скачек электричества вскоре дал о себе знать. Переставил диски, развернул резервную копию недельной давности. Жесткие диски отправил на разбор полетов. Разбором полетов я занимался 2 месяца, меня попросту взял азарт и уверенность в себе. По этому все эти 2 месяца я пытался восстановить данные с файловой системы VMFS 5-версии. Что только я не перепробовал за это время, это были и всевозможные программы по ремапингу диска от битых кластеров, и драйвера под VMFS чтобы вытащить хотя бы образ VMDK. Горький опыт как всегда приходит поздно, но он приходит не один, он приходит с уверенностью в достижении своей цели, о которой сегодня я с Вами и решил поделится. Но как мои читатели знают, я обычно оперирую "голыми" фактами и философствовать не люблю, по этому приступим к восстановлению данных:
Условие:
а) SMART диска не поврежден.
б) Наш жесткий диск все еще работает (определяется в системе), BIOS его видит вполне приемлемо.
в) В консоли vSphere виртуальная машина определяется как unknown (invalid).
г) В случае если вылетает ошибка: "Cannot open the disk '/vmfs/volumes/xxxxxx/*.vmdk' or one of the snapshot disks it depends on", пробуем удалить виртуальную машину из консоли и пересоздать дискриптор к файлу vmdk-flat примерно так как описано в этой статье. Если же виртуальная машина все еще не добавляется или если добавить ее из командной строки и она все еще
unknown (invalid), а команда vmkfstools -D *-flat.vmdk выдает сообщение о блокированном файле на подобие:
Lock [type 10c00001 offset 182634496 v 37, hb offset 3260416
gen 81, mode 1, owner 516976cd-94e8f9d5-c67e-50e549547a53 mtime 1424
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 419, 1>, gen 2, links 1, type reg, flags 0, uid 0, gid 0, mode 600
len 858993459200, nb 819200 tbz 182554, cow 0, newSinceEpoch 819200, zla 4304, bs 1048576
и снять блокировку ни чем не удается, типа стандартных советов по поиску процесса и его ликвидации, то скорее всего у Вас жесткий диск с битыми кластерами и файловой системой read only.
Проблема скорее всего в том что во время блокировки, например сетевым адаптером, через который подсоединился другой хост к виртуальной машине, он оказался во время перезагрузки блокирован в зоне расположенной на бэдблоках. И снять эту зону не получится, а как в последствии показала практика, подобные жесткие диски вообще не рекомендуются к дальнейшему их использованию.
а) SMART диска не поврежден.
б) Наш жесткий диск все еще работает (определяется в системе), BIOS его видит вполне приемлемо.
в) В консоли vSphere виртуальная машина определяется как unknown (invalid).
г) В случае если вылетает ошибка: "Cannot open the disk '/vmfs/volumes/xxxxxx/*.vmdk' or one of the snapshot disks it depends on", пробуем удалить виртуальную машину из консоли и пересоздать дискриптор к файлу vmdk-flat примерно так как описано в этой статье. Если же виртуальная машина все еще не добавляется или если добавить ее из командной строки и она все еще
unknown (invalid), а команда vmkfstools -D *-flat.vmdk выдает сообщение о блокированном файле на подобие:
Lock [type 10c00001 offset 182634496 v 37, hb offset 3260416
gen 81, mode 1, owner 516976cd-94e8f9d5-c67e-50e549547a53 mtime 1424
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 419, 1>, gen 2, links 1, type reg, flags 0, uid 0, gid 0, mode 600
len 858993459200, nb 819200 tbz 182554, cow 0, newSinceEpoch 819200, zla 4304, bs 1048576
и снять блокировку ни чем не удается, типа стандартных советов по поиску процесса и его ликвидации, то скорее всего у Вас жесткий диск с битыми кластерами и файловой системой read only.
Проблема скорее всего в том что во время блокировки, например сетевым адаптером, через который подсоединился другой хост к виртуальной машине, он оказался во время перезагрузки блокирован в зоне расположенной на бэдблоках. И снять эту зону не получится, а как в последствии показала практика, подобные жесткие диски вообще не рекомендуются к дальнейшему их использованию.
Решение:
Берем волшебную программку UFS-explorer, которая замечательно считывает данные с VMFS, копируем на другой диск образ, заливаем на сервант ESX, создаем дескриптор, подключаем к виртуалке VMDK, ПРОФИТ!
Выводы:
Потому что нефик, нужно каждый день создавать резервные копии и заранее озаботится о бесперебойном питании сервера!
Потому что нефик, нужно каждый день создавать резервные копии и заранее озаботится о бесперебойном питании сервера!
Комментариев нет:
Отправить комментарий