Восстановление информации с поврежденного LVM раздела

К нашим партнерам, крупной компании, занимающейся восстановлением данных в Москве пришло вот такое письмо:

"Добрый день, хотелось бы узнать, сможете ли вы восстановить данные после такого: ubuntu server 64 bit, два винта WD 2 Tb, mdadm raid 1 обеспечивает зеркало, lvm разделы. Запущен Windows Server 2008 r2 под KVM, ему отданы два раздела LVM, на одном из них хранились базы 1С 8.2, во время работы вдруг пропал логический диск, пишет, что не отформатирован, винда с первого раздела ЛВМ грузится, а данные на втором LVM утеряны... Сканирование R-Studio выявило 40 вариантов, но ни в одном из них не оказалось нужных данных... Возьметесь? Реально?"

Диски из массива были переданы в эту компанию, а затем попали в СЦ "Хардмастер" для анализа ситуации.

Для диагностики логических проблем связанных с ОС Linux нужна специальная рабочая станция под управлением WinОС (так как зачастую требуются те или иные программные средства, существующие только для этой ОС) с установленной VMWare Workstation (поскольку приходится работать в среде Linux). Виртуальная машина, которая потребовалась для анализа ситуации была создана на базе сборки Ubuntu 12 64 bit, с установленным пакетом поддержки lvm.

Первым делом, во избежании эксцессов, оригинальный диск был склонирован посекторно "as is" на заведомо исправный аналогичный, далее у клиентов был уточнен анамнез. Выяснилось, что на сервере никаких работ не проводилось, в процессе эксплуатации KVM машины пользователи сперва столкнулись с проблемами типа "вылетают базы 1С", "нельзя зайти в базу" но логический раздел был виден. После перезапуска сервера второй логический диск с нужной информацией исчез, вернее стал опознаваться, как неразмеченный.

На виртуальной машине была произведена диагностика, выявившая полный порядок в таблице разделов. Целый LVM раздел также определялся и подключался правильно, а вот второй том оставался недоступен. Далее закрались подозрения в возможном наличии шифрования на потерянном разделе, поскольку анализ HEX содержимого сразу после GPT MBR показывал "белый шум". По факту дальнейших изысканий было принято решение запустить в KVM гостевую систему и вылить проблемный раздел непосредственно из нее в посекторном режиме.На данном этапе возникли трудности, связанные с тем, что виртуализатор KVM, под которым была организована виртуальная машина с Windows Server 2008R2, отказался запускаться в средах VMWare Workstation 8.0 / VMWare ESXi 5.0. Не смотря на документированный разработчиками VMWare workaround, шаманство с бубном вокруг проблемы успеха не принесло. KVM упорно рапортовал об отсутствии у процессора аппаратной виртуализации, при попытке запустить домен ругался на отсутствие /dev/kvm. Также egrep '(vmx|svm)' /proc/cpuinfo, при всех попытках научить VMWare транслировать в виртуальную машину о наличии у процессора необходимого для дела атрибута, возвращал 0.Вдоволь натанцевавшись с виртуализацией, пришлось организовывать загрузку системы с клиентского диска на реальном аппаратном сервере, после чего получилось успешно вылить образ проблемного раздела. Надо заметить, что, в принципе, можно было обойтись без этого шага, и устроить выемку партиции средствами Linux. Однако паранойя, возникшая на базе печального опыта, основанного на том, что многие люди часто недоговаривают, да и просто не владеют ситуацией доподлинно, заставила заняться дополнительными исследованиями. В конце концов, это позволило получить твердую уверенность в том, что границы проблемной области были точно определены, что в гостевой ОС отсутствовало шифрование раздела или еще какие-либо каверзы, и позволило вплотную заняться анализом картины логического пространства поврежденного LVM раздела.

И к сожалению достаточно быстро выяснилась причина выхода раздела из строя. Каким то образом данные с первого раздела, по всей видимости в результате сбоя, когда по непонятной причине раздел начал расширять границы, перелезла на второй раздел попутно затерев то, что на нем было записано. Затерлось, вернее перезаписалось, не все, а только начало. Но этого хватило, чтобы потерялись большая часть таблицы MFT и часть нужной информации. В результате целостные базы данных из числа тех, которые нужны были клиентам, достать так и не получилось.

Вот так вот, кстати, довольно часто бывает. Админы городят городушки просто потому, что могут, не задумываясь, зачем оно в реале надо. Как говорится, I did it just because I can. Построить корпоративный сервер на open source ПО без гарантий и поддержек, запускать Win2008 server из-под виртуалки на кмв стоящей на lvm, — вот верный путь обеспечить предприятию потерю информации.