На днях у меня случился настоящий мозговой пук, когда я расширял диск на гостевом компьютере Linux под Vmware. Я растянул дисковый файл Vmware до желаемого размера, а затем сделал то, что обычно делаю в гостевых системах Linux. без LVM: я удалил раздел LVM и воссоздал его, начиная с того же места, что и старый, но расширил до нового размера диска. (За которыми последуют fsck и resize2fs.)
А потом я понял, что LVM не ведет себя так же, как ext2 / 3/4 на необработанных разделах ... После восстановления гостевой системы Linux из последней резервной копии (к счастью, сделанной всего пятью часами ранее) мне теперь любопытно как я мог бы оправиться от следующего сценария. В конце концов, практически гарантировано, что и в будущем я буду тупицей.
Виртуальный гость Linux с одним диском, разделенным на один / boot (основной) раздел (/ dev / sda1) размером 256 МБ, а остальные - в логический расширенный раздел (/ dev / sda5).
Затем / dev / sda5 настраивается как физический том с помощью pvcreate, а одна группа томов (vgroup00) создается поверх него с помощью обычной команды vgcreate. Затем vgroup00 разделяется на два логических тома root и swap, которые логически используются для / и swap. / - файловая система ext4.
Поскольку у меня были резервные копии неисправного гостя, я смог воссоздать группу томов с помощью vgcfgrestore из резервной копии LVM, найденной в / etc / lvm / backup, с тем же UUID для физического тома и всего такого. После запуска у меня было два логических тома того же размера, что и раньше, со свободным пространством 4 ГБ, где я растянул диск.
Однако, когда я попытался запустить "fsck / dev / mapper / vgroup00-root", он пожаловался на сломанный суперблок. Я попытался найти резервные суперблоки, запустив «mke2fs -n / dev / mapper / vgroup00-root», но ни один из них не работал. Затем я попытался бежать TestDisk но когда я попросил его найти суперблоки, он выдал только ошибку о невозможности открыть файловую систему из-за неработающей файловой системы.
Итак, с политикой распределения по умолчанию для LVM2 в 64-разрядной версии Ubuntu Server 10.04 возможно ли, чтобы логические тома выделялись из конец группы томов? Это определенно объясняет, почему восстановленные логические тома не содержат ожидаемых данных. Мог ли я восстановить, воссоздав / dev / sda5 с точно таким же размером и положением на диске, что и раньше? Есть ли какие-нибудь другие инструменты, которые я мог бы использовать для поиска и восстановления файловой системы? (И ясно, что вопрос не в том, должен ли я делать это по-другому с самого начала, я это знаю. Это вопрос о том, что делать, когда дерьмо уже поразило поклонника.)
Каждый раз, когда вы выполняете операцию с LVM, по умолчанию предыдущие метаданные архивируются в /etc/lvm/archive. Ты можешь использовать vgcfgrestore восстановить его, или взять удлинители рукой (сложнее, но lvcreate(8) должен покрыть это).
Редактировать:
И чтобы сделать это как можно проще, я должен добавить, что вы можете найти последнюю резервную копию перед вашей разрушительной операцией, просмотрев описания:
# grep description /etc/lvm/archive/vg01_*
/etc/lvm/archive/vg01_00001.vg:description = "Created before executing 'lvremove -f /dev/vg01/foo'"
/etc/lvm/archive/vg01_00002.vg:description = "Created before executing 'lvremove -f /dev/vg01/bar'"
/etc/lvm/archive/vg01_00003.vg:description = "Created before executing 'lvremove -f /dev/vg01/baz'"
Редактировать:
В normal Политика распределения (по умолчанию) будет выделять полосу из первого свободного PE, когда для этого достаточно места. Если вы хотите подтвердить, где был размещен LV, вы можете посмотреть файлы архива, они отлично читаются людьми.
Насколько мне известно, нет действительно хороших вариантов восстановления, и нет инструментов, поддерживающих это. Однако см. Раздел восстановления данных в Опасности и предостережения LVM для некоторых статей по ручному восстановлению.
Как правило, лучше всего сделать резервную копию необработанного образа сломанного тома (ов) или базовых дисков и выполнить восстановление данных на версиях резервной копии, чтобы у вас был способ повторить попытку восстановления.
В приведенном выше ответе также есть раздел об изменении размера томов LVM - их расширение достаточно безопасно, и обычно лучше использовать lvresize вместо удаления и воссоздания.
По связанному с этим вопросу: поскольку вы используете VMware, вам также следует позаботиться о том, чтобы сбросы кеша записи на жесткий диск (барьеры записи) корректно распространялись из гостевого ядра Linux через гипервизор и любую ОС хоста. Также важно, чтобы в гостевой FS и гостевом ядре были установлены барьеры записи, которые должны быть версии 2.6.33 или выше.