LVM: как я должен попытаться восстановить PV и возможную коррупцию LV?

это была моя домашняя настройка хранения файлов. У него нет резервных копий, потому что установка RAID должна была быть избыточностью. Я не объяснил, что произошло,и расплачиваюсь за это. Настройка:

  • Ubuntu 16.04
  • массив RAID 5 с четырьмя дисками с использованием mdadm (4x2TB): /dev/md0
  • на массиве, PV и LV управляется LVM.
  • на логическом Томе с именем vg0-файловая система XFS.

обратите внимание, что хост Linux, в том числе /etc и /boot, установлены на другом диске и полностью доступны (поэтому у меня есть доступ к /etc/lvm/archive). Массив RAID является чисто файловым хранилищем, процесс загрузки не зависит от него вообще, кроме его записи в /etc/fstab.

по какой-то причине я загрузился из установщика FreeDOS, который я изо всех сил пытался понять. Я думаю, что, возможно, я сказал ему переделать этот Том, хотя я не помню, как это сделал. В любом случае, когда я перезагрузился в Linux (Ubuntu 16.04), я был сброшен в режим восстановления в качестве пользователя root. Не удалось подключить UUID группы томов, как определено в файле /etc / fstab.

прошло достаточно много времени с тех пор, как я изначально настроил этот RAID-массив, что я полностью забыл, как работает LVM, или что я даже использовал LVM для создания тома. (10-12 лет, замена жестких дисков и изменение размера массива иногда в течение этого времени.) Итак, сначала я попытался использовать testdisk [1], чтобы найти и восстановить информацию о разделе. Это никогда не работало, раздел всегда был неправильным размером (524Gb вместо 4.5 TB) и никогда не был на "границе физического сектора"."Я экспериментировал с различными геометриями, думая, что есть волшебная комбинация, которая прекрасно восстановит раздел. Вот текущее состояние диска в соответствии с fdisk:

$ sudo fdisk -l /dev/md0
GPT PMBR size mismatch (1098853631 != 200894463) will be corrected by w(rite).
Disk /dev/md0: 4.1 TiB, 4500904476672 bytes, 8790829056 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 1048576 bytes / 3145728 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors  Size Id Type
/dev/md0p1          1 1098853631 1098853631  524G ee GPT

Partition 1 does not start on physical sector boundary.

и разошлись:

(parted) print list                                                       
Error: /dev/md0: unrecognised disk label
Model: Linux Software RAID Array (md)                                     
Disk /dev/md0: 4501GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags: 

в публикации вопроса на форуме testdisk [2] я понял что я использовал LVM для управления массивом RAID, и что возможно, что они вообще не используют традиционный инструмент секционирования. Исследование "восстановление физических томов lvm" выкопано http://blog.adamsbros.org/2009/05/30/recover-lvm-volume-groups-and-logical-volumes-without-backups/. pvck говорит мне следующее:

$ sudo pvck /dev/md0
  Incorrect metadata area header checksum on /dev/md0 at offset 4096
  Found label on /dev/md0, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=192512
  Incorrect metadata area header checksum on /dev/md0 at offset 4096

у меня также есть несколько резервных копий Тома LVM в/etc/lvm / archives, последним из которых является следующее:

[email protected]:~$ sudo cat /etc/lvm/archive/vg0_00002-935168089.vg
# Generated by LVM2 version 2.02.98(2) (2012-10-15): Sun Jul 19 12:00:04 2015

contents = "Text Format Volume Group"
version = 1

description = "Created *before* executing 'lvextend /dev/vg0/lv0 /dev/md0'"

creation_host = "bilby" # Linux bilby 3.16.0-43-generic #58~14.04.1-Ubuntu SMP Mon Jun 22 10:21:20 UTC 2015 x86_64
creation_time = 1437332404  # Sun Jul 19 12:00:04 2015

vg0 {
    id = "Q4ZRRc-1l0h-FEgu-jrxA-EfW1-tAis-vv0jyL"
    seqno = 5
    format = "lvm2" # informational
    status = ["RESIZEABLE", "READ", "WRITE"]
    flags = []
    extent_size = 262144        # 128 Megabytes
    max_lv = 0
    max_pv = 0
    metadata_copies = 0

    physical_volumes {

        pv0 {
            id = "bKQs0l-zNhs-X4vw-NDfz-IMFs-cJxs-y0k6yG"
            device = "/dev/md0" # Hint only

            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 8790828672   # 4.09355 Terabytes
            pe_start = 384
            pe_count = 33534    # 4.09351 Terabytes
        }
    }

    logical_volumes {

        lv0 {
            id = "pqInOe-ZLpV-t9oK-GQE1-AoIt-mB3M-4ImaV1"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 22356    # 2.729 Terabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 0
                ]
            }
        }
    }
}

если это полезно, следующие детали на массиве RAID:

$ sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Sun Oct 11 13:34:16 2009
     Raid Level : raid5
     Array Size : 4395414528 (4191.79 GiB 4500.90 GB)
  Used Dev Size : 1465138176 (1397.26 GiB 1500.30 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Mon Oct  3 13:12:51 2016
          State : clean 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 1024K

           UUID : 9be3b2f7:102e373a:822b5a8f:216da2f7 (local to host bilby)
         Events : 0.103373

    Number   Major   Minor   RaidDevice State
       0       8       64        0      active sync   /dev/sde
       1       8       48        1      active sync   /dev/sdd
       2       8       16        2      active sync   /dev/sdb
       3       8       32        3      active sync   /dev/sdc

наконец, вот печальный след testdisk.журнал, который я оставил позади: https://dl.dropboxusercontent.com/u/2776730/testdisk.log

изменить: вывод lsblk:

[email protected]:~$ sudo lsblk
NAME                 MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                    8:0    0 59.6G  0 disk  
├─sda1                 8:1    0  243M  0 part  /boot
├─sda2                 8:2    0    1K  0 part  
└─sda5                 8:5    0 59.4G  0 part  
  ├─bilby--vg-root   252:0    0 43.4G  0 lvm   /
  └─bilby--vg-swap_1 252:1    0   16G  0 lvm   [SWAP]
sdb                    8:16   0  1.8T  0 disk  
└─md0                  9:0    0  4.1T  0 raid5 
sdc                    8:32   0  1.8T  0 disk  
└─md0                  9:0    0  4.1T  0 raid5 
sdd                    8:48   0  1.8T  0 disk  
└─md0                  9:0    0  4.1T  0 raid5 
sde                    8:64   0  1.8T  0 disk  
└─md0                  9:0    0  4.1T  0 raid5 

Я полностью потерялся и подозреваю, что я сделал вещи хуже. Мои вопросы:

мне нужно "исправить" информацию о разделе, прежде чем иметь дело с проблемами LVM? Должен ли я попытаться " pvcreate --русский ХХХ --растушевывали ыыы"? И тогда мне нужно будет расширить диск и запустить что-то вроде XFS-эквивалента fsck? Или мои данные потеряны для меня в этот момент? :'(

пожалуйста, дайте мне знать, если есть что-нибудь, что я могу добавить, чтобы сделать отладку этой проблемы проще. Спасибо!

1 ответ:

хорошо. Для начала нам нужно отремонтировать это хранение стека методично, от уровня базового диска вверх. Вы запустили установщик FreeDOS, и это испортило ваши диски (предположительно), создав таблицу разделов на одном из них.

ваши диски напрямую участвуют в массиве MD, без таблицы разделов. Это довольно типично. Тем не менее, это также структура метаданных версии 0.90 в этом массиве, поэтому помещение таблицы разделов на любой из этих дисков напрямую будет иметь проблемы с массивом.

проверить, является ли у вас есть диск (любой от sdb до sde), на котором есть таблица разделов, например, в виде /dev/sdb1. Если у вас есть такой, вам нужно будет считать его грязным и вынуть его из массива, поместив его обратно после избавления от этой таблицы.

даже если мы не видим раздел на одном из этих дисков, проверка целостности должна быть запущена на /dev/md0. Команда для этого проста:

# /usr/share/mdadm/checkarray -a /dev/mdX

если это возвращается с количеством несоответствий больше нуля, то этот массив должен быть восстановлен. Мы посетим это, если понадобится, так как в настоящее время это не похоже на проблему.

что касается более конкретных проблем, testdisk поставил GPT на /dev/md0 и раздел на этом диске (/dev / md0p1). Это никогда не должно было быть там, и развращает ваши метаданные LVM. Ваша группа томов должна находиться непосредственно в /dev / md0, так как вы ее изначально создали.

во-первых, нам придется иметь дело с этим странствующий GPT на /dev / md0. Его нужно "заткнуть". Zapping GPT очистит все структуры GPT, вернув его на диск без таблицы, как и должно быть в этом случае. В этой статье подробно, что превосходно:"http://www.rodsbooks.com/gdisk/wipegpt.html". Если вы не зап, у вас будет сломанная структура GPT на этом диске, которую утилиты разбиения попытаются "исправить", что снова вызовет проблемы для вас в будущем.

после этого, теперь вы можете создайте заново все метаданные LVM, используя архивный файл, который вы разместили в своем вопросе. К счастью, вы дали мне достаточно информации, чтобы просто передать вам команду, которая будет работать. Если вы хотите узнать больше об этом процессе, это отличный ресурс: "https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/mdatarecover.html".

команда для воссоздания физического тома со всеми его оригиналами метаданные:

# pvcreate --uuid "bKQs0l-zNhs-X4vw-NDfz-IMFs-cJxs-y0k6yG" --restorefile /etc/lvm/archive/vg0_00002-935168089.vg

этот архивный файл описывает /dev / md0 как диск, который составляет вашу группу томов, и будет использовать его, как следует. Если у вас есть более поздний архивный файл в каталоге архивов LVM, используйте его вместо этого. Цель состоит в том, чтобы привести группу томов к ее последнему допустимому состоянию.

после этого, проверка целостности PV, VG и LV является ключевым. Вы уже пытались это сделать, но на этот раз это должны быть более продуктивным. Команды pvck и vgck являются то, что должно быть использовано здесь.

во-первых, проанализировать pvck:

# pvck /dev/md0

после этого проверяет, запустите vgck:

# vgck vg0

после того, как вы проверили все метаданные, пришло время активировать LVs, если они еще не:

# vgchange -ay vg0

и, наконец, проверка файловой системы на /dev/mapper / vg0-lv0 (который в вашем случае является XFS) на наличие потенциала ошибки:

# xfs_check /dev/mapper/vg0-lv0

это не должно возвращать ничего, если нет ошибок. Если что-то не так, то xfs_repair будет необходимо (не делайте этого, пока он установлен):

# xfs_repair /dev/mapper/vg0-lv0