이전에 RAID-1로 설정 /dev/sdb1했는데 다시 설치하고 이전 구성이 손실되었습니다. 멍청해서 도망쳤어/dev/sdc2mdadm
sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1
RAID를 재구성해 보세요. 드라이브를 동기화한 후(앗?) 이제 /dev/md0, /dev/sdb1, 또는가 /dev/sdc2설치되지 않습니다. 의 경우 /dev/md0슈퍼블록의 잘못된 매직 넘버에 대해 불평합니다. 의 경우 /dev/sd{b,c}1inode 누락에 대해 불평합니다.
즉, 문제는 모든 데이터를 삭제하면 됩니까, 아니면 여전히 어레이를 복구할 수 있습니까?입니다.
dumpe2fs다음은 이러한 파티션의 출력입니다.
brent@codpiece:~$ sudo dumpe2fs /dev/md0
dumpe2fs 1.42 (29-Nov-2011)
dumpe2fs: Bad magic number in super-block while trying to open /dev/md0
Couldn't find valid filesystem superblock.
brent@codpiece:~$ sudo dumpe2fs /dev/sdb1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name: <none>
Last mounted on: /var/media
Filesystem UUID: 1462d79f-8a10-4590-8d63-3fcc105b601d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 61054976
Block count: 244189984
Reserved block count: 12209499
Free blocks: 59069396
Free inodes: 60960671
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 965
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Wed Feb 10 21:04:42 2010
Last mount time: Fri May 10 20:25:34 2013
Last write time: Sun May 12 14:41:02 2013
Mount count: 189
Maximum mount count: 38
Last checked: Wed Feb 10 21:04:42 2010
Check interval: 15552000 (6 months)
Next check after: Mon Aug 9 22:04:42 2010
Lifetime writes: 250 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 7cd5ce46-b823-4453-aa66-00ddaff69952
Journal backup: inode blocks
dumpe2fs: A block group is missing an inode table while reading journal inode
편집하다:
@hauke-laging이 맞는 것 같습니다. 과거에 1.0 메타데이터 RAID 위에 1.2 메타데이터 버전 RAID-1을 만들었습니다. 올바른 버전을 다시 실행했지만 mdadm --create이제 파일 시스템이 손상되었습니다. 파티션 테이블을 조작해야 합니까, 아니면 간단히 실행할 수 있습니까 fsck /dev/md0?
fsck다음은 및 에 대한 새로운 출력 입니다 dumpe2fs.
brent@codpiece:~$ sudo fsck /dev/md0
fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
The filesystem size (according to the superblock) is 244189984 blocks
The physical size of the device is 244189952 blocks
Either the superblock or the partition table is likely to be corrupt!
brent@codpiece:~$ sudo dumpe2fs /dev/md0
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 1462d79f-8a10-4590-8d63-3fcc105b601d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 61054976
Block count: 244189984
Reserved block count: 12209499
Free blocks: 240306893
Free inodes: 61054965
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 965
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Wed Feb 10 21:04:42 2010
Last mount time: n/a
Last write time: Mon May 13 10:38:58 2013
Mount count: 0
Maximum mount count: 38
Last checked: Wed Feb 10 21:04:42 2010
Check interval: 15552000 (6 months)
Next check after: Mon Aug 9 22:04:42 2010
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 7cd5ce46-b823-4453-aa66-00ddaff69952
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00215ad3
Journal start: 0
Group 0: (Blocks 0-32767) [ITABLE_ZEROED]
Checksum 0x4453, unused inodes 0
Primary superblock at 0, Group descriptors at 1-59
Reserved GDT blocks at 60-1024
Block bitmap at 1025 (+1025), Inode bitmap at 1041 (+1041)
Inode table at 1057-1568 (+1057)
23513 free blocks, 8181 free inodes, 2 directories
Free blocks: 12576-12591, 12864-12879, <...>
Free inodes:
Group 1: (Blocks 32768-65535) [ITABLE_ZEROED]
Checksum 0x348a, unused inodes 0
Backup superblock at 32768, Group descriptors at 32769-32827
Reserved GDT blocks at 32828-33792
Block bitmap at 1026 (bg #0 + 1026), Inode bitmap at 1042 (bg #0 + 1042)
Inode table at 1569-2080 (bg #0 + 1569)
31743 free blocks, 8192 free inodes, 0 directories
Free blocks: 43232-43239, 43264-43271, <...>
Free inodes:
Group 2: (Blocks 65536-98303) [ITABLE_ZEROED]
Checksum 0x2056, unused inodes 0
Block bitmap at 1027 (bg #0 + 1027), Inode bitmap at 1043 (bg #0 + 1043)
Inode table at 2081-2592 (bg #0 + 2081)
32768 free blocks, 8192 free inodes, 0 directories
Free blocks: 66417-66432, 66445-66456, 66891, <...>
Free inodes: 23921-24576
Group 3: (Blocks 98304-131071) [ITABLE_ZEROED]
Checksum 0x4254, unused inodes 0
Backup superblock at 98304, Group descriptors at 98305-98363
Reserved GDT blocks at 98364-99328
Block bitmap at 1028 (bg #0 + 1028), Inode bitmap at 1044 (bg #0 + 1044)
Inode table at 2593-3104 (bg #0 + 2593)
31743 free blocks, 8192 free inodes, 0 directories
Free blocks: 99334-99339, 99438-99443, 99456-99459, <...>
Free inodes: 24585-32768
Group 4: (Blocks 131072-163839) [ITABLE_ZEROED]
Checksum 0x6a00, unused inodes 0
Block bitmap at 1029 (bg #0 + 1029), Inode bitmap at 1045 (bg #0 + 1045)
Inode table at 3105-3616 (bg #0 + 3105)
32768 free blocks, 8192 free inodes, 0 directories
Free blocks: 131074-131075, 131124-131129, <...>
Free inodes: 32769-40960
Group 5: (Blocks 163840-196607) [ITABLE_ZEROED]
Checksum 0x37e0, unused inodes 0
Backup superblock at 163840, Group descriptors at 163841-163899
Reserved GDT blocks at 163900-164864
Block bitmap at 1030 (bg #0 + 1030), Inode bitmap at 1046 (bg #0 + 1046)
Inode table at 3617-4128 (bg #0 + 3617)
31743 free blocks, 8192 free inodes, 0 directories
Free blocks: 164968-164970, 164979, <...>
Free inodes: 40961-49152
Group 6: (Blocks 196608-229375) [ITABLE_ZEROED]
<...>
답변1
이 질문을 봐. 나는 이것이 당신의 문제에 익숙하다고 생각합니다.
RAID-1을 다시 생성하거나 동기화해도 데이터가 파괴되어서는 안 됩니다. 분명히 MD 장치는 이제 다른 오프셋에서 시작됩니다. 따라서 마운트가 슈퍼블록을 찾는 곳에는 데이터가 있습니다. 이는 최소한 두 가지 방법으로 발생할 수 있습니다.
- 사용자(또는 기본값)가 다른 슈퍼블록 형식으로 새 배열을 생성했습니다( 참조
--metadata)man mdadm. 따라서 슈퍼블록은 이제 다른 위치에 있습니다(또는 다른 크기를 갖습니다). 너 혹시 그런 일이 있니?알다이전 메타데이터 형식은 무엇입니까? - 동일한 형식을 사용하더라도 기본 오프셋이 다르기 때문에 오프셋이 변경됩니다.
mdadm --examine /dev/sdb1(질문에 출력 추가)을 참조하세요 .
디스크의 첫 번째 영역(/dev/sdb1)에서 슈퍼블록을 찾아야 합니다. 어쩌면 이것은 또는 유사한 도구를 사용하여 수행할 수 있습니다 parted. 그러나 해당 파티션을 삭제해야 할 수도 있습니다(파티션 테이블을 쉽게 백업하고 복원할 수 있으므로 문제 없습니다).
또는 오프셋이 증가하는 루프 장치/DM 장치를 생성하고(전체 디스크에 반드시 필요한 것은 아니며 몇 MiB이면 충분함) dumpe2fs -h이를 사용해 보십시오. 이 작업을 수행하고 싶지만 방법을 모르는 경우 이에 대한 몇 가지 쉘 코드를 제공할 수 있습니다.
최악의 시나리오는 새 MD 슈퍼블록이 파일 시스템 슈퍼블록을 덮어쓰는 것입니다. 이 경우 슈퍼블록 복제본을 검색할 수 있습니다(출력 참조 mke2fs). 동일한 크기의 가상 장치에서 실행하면 mke2fs슈퍼블록 복제본이 어디에 있는지 알 수 있습니다.
편집 1:
이제 나는 그것을 읽었다그리고당신의 결과물을 알아보세요 dumpe2fs. 기존 RAID-1의 끝에는 슈퍼블록(0.9 또는 1.0)이 있습니다. 아마도 지금쯤에는 1.2가 있을 것이므로 파일 시스템의 일부를 덮어쓰게 됩니다. 피해 규모를 가늠할 수 없다. 이것은 사건입니다 e2fsck. 하지만 먼저 RAID를 이전 유형으로 재설정해야 합니다. 이전 버전에 대해 알아보는 데 도움이 됩니다.
/dev/sdb1전체 디스크에 DM 장치를 배치하고 /dev/sdc1해당 장치의 스냅샷을 찍으면(그리고 스냅샷 위에 새 어레이를 생성하면) 위험을 줄일 수 있습니다 dmsetup directly. 이렇게 하면 디스크의 관련 부분이 기록되지 않습니다. 출력에서 dumpe2fs우리는 MD 장치 크기가 1000202174464바이트여야 하며 테스트가 생성된 후 즉시 확인해야 한다는 것을 알고 있습니다.