重啟後 LVM 下的 mdadm RAID 消失

重啟後 LVM 下的 mdadm RAID 消失

我的問題的主要部分已經在這裡討論過一次......但我有兩個特殊問題以前沒有得到解答。

情況:我升級了硬件,安裝了兩個新磁碟並更改了設定。

這是新的設定

PROMPT> blkid
/dev/nvme0n1p3: UUID="29cd2fd5-2cd5-455c-9ac0-7cb278e46ee3" TYPE="swap" PARTUUID="dc3d569d-363f-4f68-87ac-56e1bdb4f29d"
/dev/nvme0n1p1: UUID="D2F8-117C" TYPE="vfat" PARTUUID="cdc50870-bddc-47bf-9835-369694713e41"
/dev/nvme0n1p2: UUID="e36edd7b-d3fd-45f4-87a8-f828238aab08" TYPE="ext4" PARTUUID="25d98b84-55a1-4dd8-81c1-f2cfece5c802"
/dev/sda: UUID="2d9225e8-edc1-01fc-7d54-45fcbdcc8020" UUID_SUB="fec59176-0f3a-74d4-1947-32b508978749" LABEL="fangorn:0" TYPE="linux_raid_member"
/dev/sde: UUID="2d9225e8-edc1-01fc-7d54-45fcbdcc8020" UUID_SUB="efce71d0-3080-eecb-ce2f-8a166b2e4441" LABEL="fangorn:0" TYPE="linux_raid_member"
/dev/sdf: UUID="dddf84e3-2ec3-4156-8d18-5f1dce7be002" UUID_SUB="be5e9e9f-d627-2968-837c-9f656d2f62ba" LABEL="fangorn:1" TYPE="linux_raid_member"
/dev/sdg: UUID="dddf84e3-2ec3-4156-8d18-5f1dce7be002" UUID_SUB="1e73b358-a0c8-1c2d-34bd-8663e7906e6f" LABEL="fangorn:1" TYPE="linux_raid_member"
/dev/sdh1: UUID="6588304d-6098-4f80-836e-0e4832e2de8f" TYPE="ext4" PARTUUID="000533fc-01"
/dev/md0: UUID="7Nyd6C-oG50-b3jJ-aGkL-feIE-pAFc-5uM7vy" TYPE="LVM2_member"
/dev/md1: UUID="MtJAdS-Jdbn-2MR7-6evR-XCvL-wEm5-PUkg8p" TYPE="LVM2_member"
/dev/mapper/fg00-Data: LABEL="data" UUID="a26b7a38-d24f-4d28-ab8d-89233db95be6" TYPE="ext4"

PROMPT> mdadm -Es 
ARRAY /dev/md/1  metadata=1.2 UUID=dddf84e3:2ec34156:8d185f1d:ce7be002 name=fangorn:1
ARRAY /dev/md/0  metadata=1.2 UUID=2d9225e8:edc101fc:7d5445fc:bdcc8020 name=fangorn:0

奇怪的:沒有/dev/md/0and/dev/md/1文件,只有/dev/md0and/dev/md1

PROMPT> mdadm --detail /dev/md[01]
/dev/md0:
           Version : 1.2
     Creation Time : Wed Oct 16 16:51:48 2019
        Raid Level : raid1
        Array Size : 3906886464 (3725.90 GiB 4000.65 GB)
     Used Dev Size : 3906886464 (3725.90 GiB 4000.65 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Wed Oct 16 16:57:03 2019
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : fangorn:0  (local to host fangorn)
              UUID : 2d9225e8:edc101fc:7d5445fc:bdcc8020
            Events : 2

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       64        1      active sync   /dev/sde
/dev/md1:
           Version : 1.2
     Creation Time : Wed Oct 16 16:51:56 2019
        Raid Level : raid1
        Array Size : 1953382464 (1862.89 GiB 2000.26 GB)
     Used Dev Size : 1953382464 (1862.89 GiB 2000.26 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Wed Oct 16 16:51:56 2019
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : fangorn:1  (local to host fangorn)
              UUID : dddf84e3:2ec34156:8d185f1d:ce7be002
            Events : 1

    Number   Major   Minor   RaidDevice State
       0       8       80        0      active sync   /dev/sdf
       1       8       96        1      active sync   /dev/sdg

在這兩個 RAID1 陣列之上,我建造了一個卷組,將它們粘合到一個分區上,並將其用作/data掛載

問題

每當我重新啟動時,RAID 都會遺失。陣列中沒有留下任何痕跡。

是的,我確實編輯過/etc/mdadm/mdadm.conf

PROMPT> cat /etc/mdadm/mdadm.conf 
# mdadm.conf
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers
DEVICE /dev/sda /dev/sde /dev/sdf /dev/sdg

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR m++++@++++++.++

# definitions of existing MD arrays

#ARRAY /dev/md1 metadata=1.2 name=fangorn:1 UUID=7068062b:a1a9265e:a7b5dc00:586d9f1b
#ARRAY /dev/md0 metadata=1.2 name=fangorn:0 UUID=9ab9aecd:cdfd3fe8:04587007:892edf3e
ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=fangorn:0 UUID=7368baaf:9b08df19:d9362975:bf70eb1f devices=/dev/sda,/dev/sde
ARRAY /dev/md1 level=raid1 num-devices=2 metadata=1.2 name=fangorn:1 UUID=dc218d09:18f63682:78b5ab94:6aa53459 devices=/dev/sdf,/dev/sdg

是的,我發出了update-initramfs -u

恢復資料的唯一方法是在每次重新啟動後重新建立陣列:

mdadm --create /dev/md0 --assume-clean --level=raid1 --verbose --raid-devices=2 /dev/sda /dev/sde
mdadm --create /dev/md1 --assume-clean --level=raid1 --verbose --raid-devices=2 /dev/sdf /dev/sdg
  • 注意--assume-clean開關
  • LVM 立即重新建立並可安裝。
  • 沒有資料遺失。

但是:如何讓系統在重新啟動時重新組裝陣列?

磁碟上已經有相當多的數據,所以我不想對底層硬體重新分割區,除非我有辦法在不遺失資料的情況下這樣做。

我可以在陣列和 LVM 未啟動並運行的情況下存取資料嗎?

附加資訊

  • 已新增 2019-10-22

重新啟動後 - 即當重組失敗並且我處於單用戶模式時 - 我從 mdadm 獲得以下輸出(我mdadm.conf同時刪除以查看它是否有幫助 - 它沒有):

PROMPT> mdadm --assemble --scan -v 
mdadm: looking for devices for further assembly
mdadm: cannot open device /dev/sr0: No medium found
mdadm: no recogniseable superblock on /dev/sdh1
mdadm: Cannot assemble mbr metadata on /dev/sdh
mdadm: Cannot assemble mbr metadata on /dev/sdg
mdadm: Cannot assemble mbr metadata on /dev/sdf
mdadm: Cannot assemble mbr metadata on /dev/sde
mdadm: Cannot assemble mbr metadata on /dev/sda
mdadm: no recogniseable superblock on /dev/nvme0n1p3
mdadm: no recogniseable superblock on /dev/nvme0n1p2
mdadm: Cannot assemble mbr metadata on /dev/nvme0n1p1
mdadm: Cannot assemble mbr metadata on /dev/nvme0n1
mdadm: No arrays found in config file or automatically

之後,我按照上面的描述重新創建了數組並獲得了這個輸出:

PROMPT> mdadm --create /dev/md0 --assume-clean --level=raid1 --verbose --raid-devices=2 /dev/sda /dev/sde
mdadm: partition table exists on /dev/sda
mdadm: partition table exists on /dev/sda but will be lost or
       meaningless after creating array
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: partition table exists on /dev/sde
mdadm: partition table exists on /dev/sde but will be lost or
       meaningless after creating array
mdadm: size set to 3906886464K
mdadm: automatically enabling write-intent bitmap on large array
Continue creating array? 
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

PROMPT> mdadm --create /dev/md1 --assume-clean --level=raid1 --verbose --raid-devices=2 /dev/sdf /dev/sdg
mdadm: partition table exists on /dev/sdf
mdadm: partition table exists on /dev/sdf but will be lost or
       meaningless after creating array
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: partition table exists on /dev/sdg
mdadm: partition table exists on /dev/sdg but will be lost or
       meaningless after creating array
mdadm: size set to 1953382464K
mdadm: automatically enabling write-intent bitmap on large array
Continue creating array?
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.

後來又做了一個lsblk

PROMPT>  lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
NAME            SIZE FSTYPE            TYPE  MOUNTPOINT
sda             3,7T linux_raid_member disk  
└─md0           3,7T LVM2_member       raid1 
  └─fg00-Data   5,5T ext4              lvm   /data
sde             3,7T linux_raid_member disk  
└─md0           3,7T LVM2_member       raid1 
  └─fg00-Data   5,5T ext4              lvm   /data
sdf             1,8T linux_raid_member disk  
└─md1           1,8T LVM2_member       raid1 
  └─fg00-Data   5,5T ext4              lvm   /data
sdg             1,8T linux_raid_member disk  
└─md1           1,8T LVM2_member       raid1 
  └─fg00-Data   5,5T ext4              lvm   /data
sdh           119,2G                   disk  
└─sdh1        119,2G ext4              part  /home
sr0            1024M                   rom   
nvme0n1         477G                   disk  
├─nvme0n1p1     300M vfat              part  /boot/efi
├─nvme0n1p2   442,1G ext4              part  /
└─nvme0n1p3    34,6G swap              part  [SWAP]

這是一個有人能理解的暗示嗎?

PROMPT> fdisk -l

The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sda: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM004-2CV1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 513C284A-5CC0-4888-8AD0-83C4291B3D78


The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sde: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM004-2CV1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 437D10E3-E679-4062-9321-E8EE1A1AA2F5


The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdf: 1,84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000DL003-9VT1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E07D5DB8-7253-45DE-92C1-255B7F3E56C8


The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdg: 1,84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Hitachi HDS5C302
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: E07D5DB8-7253-45DE-92C1-255B7F3E56C8

Disk /dev/md0: 3,65 TiB, 4000651739136 bytes, 7813772928 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/md1: 1,84 TiB, 2000263643136 bytes, 3906764928 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mapper/fg00-Data: 5,47 TiB, 6000908173312 bytes, 11720523776 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

另一點資訊

PROMPT> gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.4

Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: OK
Main partition table: ERROR
Backup partition table: OK

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

答案1

我想介紹 Martin L. 解決方案的另一種變體。它的不同之處在於它引入的停機時間要少得多,因為資料遷移到新陣列可以在系統工作時透明地完成。您只會在遷移過程中遇到磁碟效能下降的情況。

按照建議進行在他的回答中直到他建議創建新的 VG 的地方。

不要建立新的 VG。在新建立的陣列上建立新的 PV,並使用這些 PV 擴展現有的 VG:vgextend fg00 /dev/md-NEW

然後,使用 . 將邏輯磁碟區從舊 pv 移到新 pv pvmove /dev/md-OLD。即使在安裝和存取檔案系統時也可以完成此操作。這將需要很長時間,但最終會完成。我會在screen和 verbosely:內運行它screen pvmove -vi5 /dev/md-OLD,以確保它不會在 SSH 會話關閉時中斷,並且每 5 秒顯示一次進度。

新 PV 中可能沒有足夠的 PE 來執行此操作。這是因為您現在使用分割區而不是整個驅動器,可用空間和陣列大小稍小。如果是這樣,你就得減少一個LV。例如,卸載 FS、減少(使用resize2fs)並減少 LV 大小。這將花費更長的時間,但仍然比逐個檔案複製繁忙的檔案系統要快。

當舊的PV為空時(pvmove完成),將它們從VG中刪除,刪除PV標籤並刪除舊陣列。刪除那些現在未使用的驅動器,對它們進行分割並添加到正在運行的陣列中。陣列重新同步也將在背景完成,在完成之前您只會遇到磁碟效能下降的情況。

現在,不要忘記修復引導,即mdadam --examine --scan >> /etc/mdadm/mdadm.confupdate-initramfs等等。

答案2

@nh2 給了一個簡單但可能有危險他的回答中的解決方案使用分割區或直接使用整個磁碟建立 mdadm 陣列有什麼區別

順便說一句,如果您遇到這種情況,您的資料不會遺失。您很可能只需要sgdisk --zap設備,然後使用例如重新建立 RAID mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc /dev/sdd(mdadm 會告訴您它已經偵測到過去的數據,並詢問您是否要繼續重新使用該數據)。我嘗試了多次並且有效,但我仍然建議您在執行此操作之前進行備份。

經過長時間的研究,我設法找到了解決方案。

這是我所做的

首先是一些狀態資訊

PROMPT> df -h
Dateisystem           Größe Benutzt Verf. Verw% Eingehängt auf
/dev/mapper/fg00-Data  5,4T    1,5T  3,8T   28% /data

然後卸載分區

PROMPT> umount /data

PROMPT> cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sdg[1] sdf[0]
      1953382464 blocks super 1.2 [2/2] [UU]
      bitmap: 0/15 pages [0KB], 65536KB chunk

md0 : active raid1 sde[1] sda[0]
      3906886464 blocks super 1.2 [2/2] [UU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>

現在我降級兩個陣列

PROMPT > mdadm --manage /dev/md0 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md0

PROMPT > mdadm --manage /dev/md1 --fail /dev/sdg
mdadm: set /dev/sdg faulty in /dev/md1

PROMPT > cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sdg[1](F) sdf[0]
      1953382464 blocks super 1.2 [2/1] [U_]
      bitmap: 0/15 pages [0KB], 65536KB chunk

md0 : active raid1 sde[1](F) sda[0]
      3906886464 blocks super 1.2 [2/1] [U_]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>

從陣列中刪除磁碟

PROMPT > mdadm --manage /dev/md0 --remove /dev/sde 
mdadm: hot removed /dev/sde from /dev/md0
PROMPT > mdadm --manage /dev/md1 --remove /dev/sdg
mdadm: hot removed /dev/sdg from /dev/md1

PROMPT > cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sdf[0]
      1953382464 blocks super 1.2 [2/1] [U_]
      bitmap: 0/15 pages [0KB], 65536KB chunk

md0 : active raid1 sda[0]
      3906886464 blocks super 1.2 [2/1] [U_]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>

現在/dev/sde/dev/sdg可以自由地(重新)分區。

  • 因此,我按照建議建立了比可用空間小幾 MB 的新分割/dev/sde/dev/sdg
  • 建立了新的 2 磁碟 RAID1 陣列,其中一個活動磁碟和一個「缺少」磁碟
  • 使用這些新陣列作為實體磁碟區建構了一個新的 LVM 磁碟區組
  • 在其上建立一個邏輯磁碟區(與舊磁碟區的大小相同減去建立分割區時遺失的幾MB)
  • 將舊 LV 中的所有資料複製到新 LV 中
  • 銷毀舊的 RAID 並將磁碟分割區新增至新的 RAID 中

這是新的狀態

PROMPT > lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
NAME              SIZE FSTYPE            TYPE  MOUNTPOINT
sda               3,7T                   disk  
└─sda1            3,7T linux_raid_member part  
  └─md2           3,7T LVM2_member       raid1 
    └─fg01-Data   5,5T ext4              lvm   /data
sde               3,7T                   disk  
└─sde1            3,7T linux_raid_member part  
  └─md2           3,7T LVM2_member       raid1 
    └─fg01-Data   5,5T ext4              lvm   /data
sdf               1,8T                   disk  
└─sdf1            1,8T linux_raid_member part  
  └─md3           1,8T LVM2_member       raid1 
    └─fg01-Data   5,5T ext4              lvm   /data
sdg               1,8T                   disk  
└─sdg1            1,8T linux_raid_member part  
  └─md3           1,8T LVM2_member       raid1 
    └─fg01-Data   5,5T ext4              lvm   /data
sdh             119,2G                   disk  
└─sdh1          119,2G ext4              part  /home
sr0              1024M                   rom   
nvme0n1           477G                   disk  
├─nvme0n1p1       300M vfat              part  /boot/efi
├─nvme0n1p2     442,1G ext4              part  /
└─nvme0n1p3      34,6G swap              part  [SWAP]

PROMPT > cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md3 : active raid1 sdf1[1] sdg1[0]
      1953381376 blocks super 1.2 [2/1] [U_]
      [==>..................]  recovery = 10.0% (196493504/1953381376) finish=224.9min speed=130146K/sec
      bitmap: 0/15 pages [0KB], 65536KB chunk

md2 : active raid1 sda1[1] sde1[0]
      3906884608 blocks super 1.2 [2/1] [U_]
      [=>...................]  recovery =  6.7% (263818176/3906884608) finish=429.0min speed=141512K/sec
      bitmap: 2/30 pages [8KB], 65536KB chunk

unused devices: <none>

相關內容