Centos 7 восстановление lvm
Обновлено: 04.07.2024
Жила-была у меня машина с XenServer 6.5 на борту и несколькими массивами из SATA-дисков. В последнее время перестало хватать быстродействия SATA и было решено заменить один массив на SAS-диски. Для этих целей был найден RAID-контроллер Adaptec 3805 (знаю, что старье, зато халява).
После успешного создания RAID-массива из SAS-дисков(каюсь, использовал адаптековский raid) и добавления оного как lvm-storage, начал перенос одного из образов виртуальных машин на него. В процессе созерцания прогресса переноса закралось подозрение о неладном, так как изменился тон звучания сервера. А когда сервер ушел в самостоятельную перезагрузку, я начал понемногу седеть… И окончательно меня добило то, что после перезагрузки я не нашел переносимый образ ни в одном из хранилищ, а само новое хранилище отображается со статусом «не доступно».
После непродолжительной прогулки для успокоения нервов и чашки кофе я закатал рукава (ага, на футболке то) и начал думать как восстановить образ…
Для начала, естественно, полез в логи и увидел, что при создании хранилища из массива SAS произошла ошибка:
Ошибка означает, что хранилище не доступно. Я решил проверить физические тома lvm через pvdisplay и не увидел созданного тома на SAS-массиве. pvs тоже не обнаружил тома.
Это означало, что хранилище, на самом деле, не создалось. Точнее создался объект хранилища в XenServer, но при этом он не был связан с физическим хранилищем. Почему XenServer так себя повел, и, тем более, позволил перенести образ в это хранилище, я так и не выяснил.
Получается, что образ на SAS-массиве можно даже не искать, так как физически на него ничего не переносилось. Значит нужно пробовать восстанавливать образ с хранилища, на котором он был изначально.
Поиск в интернете на тему восстановления логических томов LVM задал начальный вектор раскопок.
LVM хранит свою текущую конфигурацию в /etc/lvm/backup/ и, в обычных условиях, архив старых конфигураций в виде бинарных файлов, в /etc/lvm/archive/. UUID хранилища XenServer соответствует имени LVM VolumeGroup. Но, оказывается, в XenServer этот самый архив отключен:
Дальнейшие поиски показали, что lvm хранит архив всех конфигураций VolumeGroup в начальных секторах этих самых VolumeGroup. Так как у меня хранилище расположено на отдельном массиве, то просматриваю начало этого массива:
Если видно что-то похожее на конфиги, то можно снять дамп этих секторов для более удобного чтения (в моем случае архив занимал 100Мб):
Так же дамп можно снять через команду lvmdump.
В дампе ищу конфиг, дата которого предшествует моменту пропажи образа:
Из этого конфига нужна только запись, соответствующая пропавшему образу (та запись, которая отсутствует в текущем конфиге в /etc/lvm/backup/<Соответствующий VG>, в моем случае VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89). Переписываю ее в текущую конфигурацию и даю LVM команду восстановить VG из бэкапа:
Проверяю, что Logical Volume подхватился:
Если сейчас сделать поиск по хранилищу (через XenCenter или xe sr-scan), то XenServer успешно затрет эту запись и все придется делать заново. Как я понял, XenServer не видит у себя VDI (образа диска) с UUID, соответствующем UUID нашему восстановленному Logical Volume.
XenServer, при использовании lvm, хранит образы дисков напрямую в Logcal Volume. Точнее Logical Volume это и есть VHD-образ. Поэтому я предположил, что можно заставить XenServer увидеть образ, скопировав его поверх другого, такого же размера.
Для копирования раздела активирую разделы в этом VG:
Теперь есть доступ к разделу LVM, значит можно скопировать этот раздел с помощью dd:
После того, как скопированный образ добавился в виртуальной машине, а так же после того, как машина стартанула с этого образа, моему счастью не было предела!
Однако не все так радужно. Нужно было еще выключить сервер, чтобы вытащить глючный контроллер. А когда я его включил образ снова пропал! Получается, что XenServer при запуске сверяет UUID образа в LVM c UUID в своей базе и, если они не совпадают, образ удаляется.
Пока ковырял LVM заметил, что при переносе образа из одного хранилища в другое так же меняется и его UUID и, исходя из этого, предположил, что можно окончательно воскресить образ, просто скопировав переписанный через dd образ в другое хранилище. Это должно обновить UUID в образе, сопоставив его в UUID в базе. Повторяем все процедуры заново, после чего переносим образ на временно созданное для этого хранилище, добавляем к виртуальной машине и пробуем ее запустить. Запуск проходит нормально.
Перезагружаем сервер, трясущимися от нетерпения и усталости руками проверяем список образов и… образ на месте! Счастью нет предела и, довольный собой, я удаляюсь в закат…
Читайте также: