Как я могу реинтегрировать потерянный и найденный PV в LVM VG?

Недавно я потерял RAID, который был физическим томом одной из моих групп томов LVM linux. Я закончил тем, что делал vgreduce --removemissing и продолжил дело восстановления данных.

Ну, сегодня я обнаружил этот RAID (он прятался, не спрашивайте).

# pvdisplay -m /dev/md2
  WARNING: Volume group mg20 is not consistent
  "/dev/md2" is a new physical volume of "499.87 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/md2
  VG Name               
  PV Size               499.87 GiB
  Allocatable           NO
  PE Size               0   
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               SUXIe9-B4xG-Qlbz-5cSd-f1dh-cRQh-vOF4qz

mg20 не согласуется, потому что потерянный и найденный PV /dev/md2 вероятно, содержит копии старого каталога логических томов, который упоминает файловую систему, живущую на /dev/md2,

Как мне реинтегрировать /dev/md2 в mg20 и сохранить файловую систему, которая живет на нем? (и избавляю себя от необходимости восстанавливать его содержимое). /dev/md2 содержал только один LV, и этот LV полностью содержался на /dev/md2,

linux raid lvm partition-recovery Mutant Bob
источник

Я нашел полезную информацию на redhat.com/archives/linux-lvm/2007-November/msg00040.html redhat.com/archives/linux-lvm/2007-November/msg00039.html вращался вокруг фильтров в lvm.conf, но не смог его должным образом использовать, поскольку PV, кажется, был очищен от логического тома, возможно, потому что мои фильтры не были достаточно ограничивающими («a | / dev / md2 |» соответствует / DEV / MD20). Вполне возможно, что если бы я был более осторожен, я бы мог избежать перекрестного загрязнения новых метаданных VG потерянным и найденным PV.

Mutant Bob

Ответы:

я понял способ восстановить рейд. Современные системы LVM довольно часто делают резервные копии конфигурации VG. Вы можете увидеть список ваших резервных копий и команд, которые вызвали их, используя vgcfgrestore --list , Я выбрал тот, что раньше, когда я сделал vgreduce --removemissing и нашел эти соответствующие биты внутри него:

pv8 {
        id = "SUXIe9-B4xG-Qlbz-5cSd-f1dh-cRQh-vOF4qz"
        device = "unknown device"       # Hint only

        status = ["ALLOCATABLE"]
        flags = ["MISSING"]
        dev_size = 1048312832   # 499.875 Gigabytes
        pe_start = 2048
        pe_count = 127967       # 499.871 Gigabytes
}

а также

homes18 {
        id = "d7yt43-PMTv-XnsH-qAff-3d5A-ilB6-eQB0Jy"
        status = ["READ", "WRITE", "VISIBLE"]
        flags = []
        segment_count = 1

        segment1 {
                start_extent = 0
                extent_count = 89600    # 350 Gigabytes

                type = "striped"
                stripe_count = 1        # linear

                stripes = [
                        "pv8", 0
                ]
        }
}

Поэтому я создал копию этого файла и удалил "MISSING" от flags = , Я также установил device = "/dev/md2"хотя это, вероятно, не было необходимости. Я выполнил vgcfgrestore -f /etc/lvm/archive/mg20_synthetic-2015.vg mg20 и теперь мой mg20 / homes18 вернулся и прошел fsck.

Если честно, я не очень доволен этим как ответом. Это немного излишне, чтобы восстановить ВСЮ конфигурацию.

Я думаю, что реальный ответ может включать lvcreate -Z n, но мне лень проводить необходимые эксперименты, чтобы это проверить.

Mutant Bob
источник