해결됨: EXT4-fs(md1): 슈퍼블록을 읽을 수 없습니다. 데이터 손실을 피하고 싶습니다.

2024-6-5 • tag-icon

해결됨: EXT4-fs(md1): 슈퍼블록을 읽을 수 없습니다. 데이터 손실을 피하고 싶습니다.

내 Linux 지식은 미미하며(아직 배우는 중) Google-Fu 수준을 넘어서는 문제에 직면했습니다. 나는 깊이가 없으며 누군가가 나를 도울 수 있기를 바랍니다 ...

저는 제 집 연구실에서 OpenMediaVault 5.5.3-1(Usul)을 실행하고 있으며 두 개의 소프트웨어 RAID 어레이, /dev/md0 및 /dev/md1을 가지고 있습니다. 오늘 아침에 로그인했을 때 4개의 디스크로 구성된 RAID5 세트(일명 /dev/disk/by-label/RAID5)인 /dev/md1을 사용할 수 없다는 것을 발견했습니다. 잃고 싶지 않은 많은 데이터를 저장합니다.

지금까지 내가 한 일:

OpenMediaVault GUI를 확인했는데 레이드세트가 "누락"되었다는 메시지가 나타납니다.
Raidset을 구성하는 4개의 디스크 중 하나가 BIOS 수준에서 나타나지 않는 것으로 확인되었습니다. 케이블을 다시 설치했는데 이제 4개의 드라이브(sdc, sdd, sde 및 sdh)가 모두 운영 체제에 표시됩니다.
재부팅 후에도 raidset은 여전히 "누락"으로 표시되고 dmesg에 메시지가 나타납니다.
```
EXT4-fs (md1): unable to read superblock
```

/proc/mdstat md1이 비활성 상태인지 확인합니다.

root@OpenMediaTower:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : inactive sdh[3](S) sde[2](S) sdd[1](S) sdc[0](S)
      7813529952 blocks super 1.2

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

unused devices: <none>

Google을 통해 다소 비슷한 문제를 다룬 이전 기사를 찾아서 mdadm을 조사했지만 안타깝게도 세부 사항을 사용하여 문제를 진단하고 해결할 만큼 지식이 부족했습니다.

mdadm --detail의 출력

root@OpenMediaTower:~# mdadm --detail --scan
ARRAY /dev/md0 metadata=1.2 name=OpenMediaTower:Mirror UUID=f7b1c667:3df80c11:975d87ad:126b5401
INACTIVE-ARRAY /dev/md1 metadata=1.2 name=RAID5 UUID=c813cb15:a9d26d51:7faada85:9b76b36d

레이드셋을 다시 조립해 보세요

root@OpenMediaTower:~# mdadm --stop
/dev/md1 mdadm: stopped /dev/md1

root@OpenMediaTower:~# mdadm --assemble --scan
mdadm: /dev/md1 assembled from 2 drives - not enough to start the array.

mdadm --examine의 출력

root@OpenMediaTower:~# mdadm --examine /dev/sd[dehc]
/dev/sdc:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : c813cb15:a9d26d51:7faada85:9b76b36d
           Name : RAID5
  Creation Time : Sun May 17 14:49:46 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
     Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=176 sectors
          State : clean
    Device UUID : 42088567:13765c92:e2a5503b:c30355d0

Internal Bitmap : 8 sectors from superblock
    Update Time : Wed Jul 22 08:35:02 2020
  Bad Block Log : 512 entries available at offset 16 sectors
       Checksum : dd641c67 - correct
         Events : 218937

         Layout : left-symmetric
     Chunk Size : 512K

    Device Role : Active device 0
    Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdd:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : c813cb15:a9d26d51:7faada85:9b76b36d
           Name : RAID5
  Creation Time : Sun May 17 14:49:46 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
     Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=176 sectors
          State : active
    Device UUID : 69f98cc0:b818da43:b883695d:2246b3ab

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Jul 19 03:32:33 2020
  Bad Block Log : 512 entries available at offset 16 sectors
       Checksum : e55cb645 - correct
         Events : 30843

         Layout : left-symmetric
     Chunk Size : 512K

    Device Role : Active device 1
    Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sde:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : c813cb15:a9d26d51:7faada85:9b76b36d
           Name : RAID5
  Creation Time : Sun May 17 14:49:46 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
     Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=176 sectors
          State : active
    Device UUID : 04ec1c61:a7f1bb11:ee13bfe0:7153e38a

Internal Bitmap : 8 sectors from superblock
    Update Time : Tue Jul 21 21:59:53 2020
  Bad Block Log : 512 entries available at offset 16 sectors
       Checksum : b6579d04 - correct
         Events : 216993

         Layout : left-symmetric
     Chunk Size : 512K

    Device Role : Active device 2
    Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdh:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : c813cb15:a9d26d51:7faada85:9b76b36d
           Name : RAID5
  Creation Time : Sun May 17 14:49:46 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
     Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=176 sectors
          State : clean
    Device UUID : 2af17abb:48930a97:31ce1fa5:850ac7d0

Internal Bitmap : 8 sectors from superblock
    Update Time : Wed Jul 22 08:35:02 2020
  Bad Block Log : 512 entries available at offset 16 sectors
       Checksum : a0495199 - correct
         Events : 218937

         Layout : left-symmetric
     Chunk Size : 512K

    Device Role : Active device 3
    Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

e2fsck를 실행했는데 슈퍼블록 관련 문제가 보고되었습니다. 이 단계에서는 시도하지 않았습니다.

root@OpenMediaTower:~# e2fsck /dev/md1
e2fsck 1.45.5 (07-Jan-2020)
e2fsck: Invalid argument while trying to open /dev/md1

The superblock could not be read or does not describe a validext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

RAID세트를 재조립하고 각 디스크의 이름을 개별적으로 지정해 보았습니다.

root@OpenMediaTower:~# mdadm --verbose --assemble /dev/md1 /dev/sdc /dev/sdd /dev/sde /dev/sdh
mdadm: looking for devices for /dev/md1
mdadm: /dev/sdc is identified as a member of /dev/md1, slot 0.
mdadm: /dev/sdd is identified as a member of /dev/md1, slot 1.
mdadm: /dev/sde is identified as a member of /dev/md1, slot 2.
mdadm: /dev/sdh is identified as a member of /dev/md1, slot 3.
mdadm: added /dev/sdd to /dev/md1 as 1 (possibly out of date)
mdadm: added /dev/sde to /dev/md1 as 2 (possibly out of date)
mdadm: added /dev/sdh to /dev/md1 as 3
mdadm: added /dev/sdc to /dev/md1 as 0
mdadm: /dev/md1 assembled from 2 drives - not enough to start the array.

답변1

추가 데이터 손실을 방지하려면 다음을 설정하십시오.기록 중 복사 덮어쓰기모든 실험에 사용하세요.

그러면 집중된 힘으로 행운을 시험해 볼 수 있습니다아니요최신 업데이트 시간과 이벤트 횟수가 있는 드라이브입니다 /dev/sdd.

mdadm --stop /dev/md1
mdadm --assemble /dev/md1 --force /dev/mapper/sdc /dev/mapper/sde /dev/mapper/sdh

운이 좋다면 이를 통해 데이터에 액세스할 수 있습니다(저하 모드).

그러나 가장 큰 문제는 애초에 어떻게 무너졌느냐는 점이다. 따라서 SMART 값을 확인하고 드라이브에 재할당/보류/수정할 수 없는 섹터가 있는 경우 계속하기 전에 새 드라이브가 필요합니다 ddrescue. 고장난 드라이브에서 데이터를 복구하려고 시도하는 것은 좋은 생각이 아닙니다.

답변1

관련 정보