Отсутствуют метаданные LVM, пытаюсь воссоздать рейд 1 с LVM
Это возможно, но довольно болезненно.
Во-первых, знайте, что dd печатает свою текущую позицию в копии (байты копируются), если послать сигнал USR1. поэтому найдите PID от dd, используя либо ps, либо что-то вроде pidof или pgrep (не POSIX и не на всех unix-y системах IIRC).
Команда ps, которая работает для меня (также использующего awk, в среде debian):
ps aux|awk '/dd/ {print $2}'|grep -v awk
grep -v awk необходима для того, чтобы PID из awk также не печатался.
Имея PID от dd, отправьте сигнал USR1:
kill -USR1 [pid of dd]
консольное окно, в котором работает dd, выведет, сколько байт он скопировал. Теперь вы можете убить dd по-настоящему (ctrl+c, kill -9, что угодно). Я не помню, сообщает ли dd о своем прогрессе при прерывании, если он убит таким образом в POSIX, поэтому сначала отправьте сигнал USR1.
dd, возможно, скопировал еще несколько байт с тех пор, как вы его остановили, поэтому выполните:
head -c [number of bytes reported copied from dd] > \
/path/to/drive/you/are/moving/to/filename.bin
чтобы поместить усеченную копию на целевой диск. Вместо точного числа байт вы можете выбрать что-то кратное желаемому размеру блока, чтобы ускорить передачу при возобновлении копирования. Запишите любое выбранное вами число и убедитесь, что вы только усекаете, а не увеличиваете изображение.
После того, как образ скопирован на новый диск, выполните:
dd if=/dev/sdc bs=64M skip=[truncated size divided by block size, e.g. 64000000] \
of=/path/to/part2
Если у вас есть место для оставшегося образа на меньшем исходном диске, удалите неусеченный образ, который вы скопировали на новый диск в части 1, чтобы освободить место, и попросите dd вывести его на этот диск вместо него. Когда перенос будет завершен, вы можете выполнить команду
cat /path/to/part2 >> /path/to/part1
для добавления part 2 в конец part 1, создав полный образ диска! Обратите внимание, что на диске, на котором находится часть 1, должно быть как минимум столько же свободного места, чтобы вся вторая часть была добавлена на него.
Если вы не возражаете против полного переноса, я бы сделал cat /dev/sdc | gzip -c - > /path/to/imagefile.img.gz, чтобы создать архив, сжатый gzip. Его можно записать на раздел жесткого диска, используя что-то вроде zcat /path/to/imagefile.img.gz > /dev/sdX.
[скопировано из моего комментария в ответ]
Кроме того, я думаю (но не помню точно), что dd пишет в stdout, если не указан of=. Если это так, вы можете пропустить запись part2 в отдельный файл и использовать:
dd bs=64M skip=[skip-block-count] if=/dev/sdc >> /path/to/part1
@MatijaNalis справедливо предложил использовать dd_rescue или ddrescue (две разные программы, выполняющие одну и ту же задачу) для копирования образа диска. Я бы сделал это, если ваш раздел/диск имеет ошибочные сектора или другие аппаратные неисправности.
Первая :головка — не лучший инструмент для отображения двоичных данных. Попробуйте odилиhexdump(Что-то вродеhexdump -C -n 4096 /dev/XYZ)
Второй :Это не имеет ничего общего с идентификатором md. -LVM использует свои собственные идентификаторы, записанные в заголовках физического тома (PV ).
Третий :Было бы полезно опубликовать архив, созданный lvmdump -sm(, который содержит, например. /var/log/messages -, поэтому вы можете просмотреть его вывод.)
Некоторые идеи:
Это единственные два диска?
Первое, что мне показалось, это похоже на то, что md был собран неправильно -например. при использовании неправильного устройства перезапись одного из ваших устройств:
Вы пытаетесь восстановить vg0 с "UUID" "3JWsYl -FmEP -gpsa -7grO -VlLU -x7uC -EevgFc":
vg0 {
id = "3JWsYl-FmEP-gpsa-7grO-VlLU-x7uC-EevgFc"
Но на ногах md девайса стоит vg0 с другим "UUID"
vg0 {
id = "IwXCM3-LnxU-Oguo-PXiN-nXwq-VFaU-ZmgySs"
Но похоже, что PV имеет правильный идентификатор:
pv0 {
id = "3fgedF-F7Dc-c300-svuP-b3Q3-qSnb-CukkLq"
против 3fgedFF7Dcc300svuPb3Q3qSnbCukkLqна одной из ног.
Итак, я предполагаю, что позже в области метаданных есть что-то еще. Например :Это клонированная виртуальная машина, и вы изменили ее идентификатор позже?
При повторном просмотре похоже, что одна из ножек сдвинута на несколько байт (или часть устройства была перезаписана нулями? Вот почему следует использовать od/hexdump ). Так что md не видит ничего, кроме хлама -, так как данные на обоих дисках действительно различаются.
Вы как-то манипулировали разделами? Обновленное ядро? Вы диски смотрите на другой машине? Это может быть проблема выравнивания.
Кажется, что одна из ветвей имеет правильный заголовок PV. LVM его не видит, так как просматривает md, который возвращает мусор. А LVM не смотрит на ноги md.
Возможные решения
Одно из возможных решений — разобрать md на отдельные ноги. (Только помните :НЕ обнулять суперблок!)и пусть LVM посмотрит на ноги :запустите pvscan на разделах -если нога правильная, с одной из них может быть все в порядке.
Ваши метаданные показывают, что существует только один линейный LV, имеющий только один сегмент, охватывающий весь диск -, который может быть полезен. Какая файловая система была на устройстве? Если у вас есть /etc/lvm/backup, я думаю, у вас есть и /etc/fstab. В качестве другого возможного решения можно найти начало FS и напрямую использовать dmsetup для создания сопоставления :https://wiki.gentoo.org/wiki/Device-mapper#Linear.
И последнее, что не менее важно, :старайтесь, чтобы исходные устройства были доступны только для чтения.
Так что я решил проблему самостоятельно. Я где-то читал, что действительно старые версии mdadmиспользовали меньше метаданных, а новые версии использовали больше. Поскольку я перешел с системы Ubuntu 10.10 на CentOS 6.9 (, несмотря на то, что он успешно монтировался на CentOS 6.9 в течение нескольких недель ), я решил, что это объясняет, почему /dev/md0устройство было меньше исходного PV.. Как только я загрузил резервную копию системы Ubuntu 10.10, собрал рейд и запустил vgcfgrestoreна исходной группе томов, рейд смонтировался нормально, и мои данные снова стали доступны.
Таким образом, в основном файловые системы рейда, построенные на очень старых версиях mdadm, не следует монтировать непосредственно в новые дистрибутивы Linux.