재사용하지 않고 새 어레이를 생성 한 후 RAID 5 데이터 복구


35

사람들은 제발 도와주세요-나는 큰 두통을 앓고있는 새로운 사람입니다 (완벽한 폭풍 상황).

소프트웨어 우습 5로 구성된 우분투 11.04에 3 1TB의 HDD가 있습니다. 데이터는 완전히 실패하고 버릴 때까지 매주 컴퓨터 하드 드라이브의 다른 별도 드라이브에 복사되었습니다. 며칠 전에 정전이 발생하여 재부팅 한 후 상자를 습격하지 않았습니다. 나의 무한한 지혜로 나는 들어갔다

mdadm --create -f...

대신 명령

mdadm --assemble

그리고 내가 끝까지했던 비극을 눈치 채지 못했습니다. 어레이의 성능이 저하되고 ~ 10 시간이 소요되는 구축 및 동기화가 진행되었습니다. 내가 돌아온 후 나는 어레이가 성공적으로 작동하고 있음을 보았지만 공격대는 그렇지 않다는 것을 알았다.

개별 드라이브가 파티션되어 f8있지만 (파티션 유형 ) md0장치가 아닙니다. 내가 한 일을 공포에서 깨닫고 나는 해결책을 찾으려고 노력하고있다. --create하드 드라이버의 전체 내용을 덮어 쓰지 않기를 기도합니다 .

누군가 나를 도와 줄 수 있습니까? 드라이브에있는 데이터는 매우 중요하고 ~ 10 년 동안의 사진, 문서 등 고유합니다.

참여하는 하드 드라이브를 잘못된 순서로 지정하면 mdadm덮어 쓸 수 있습니까? 내가 할 때

mdadm --examine --scan 

나는 같은 것을 얻는다 ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

흥미롭게도 충분한 이름이 '공격'이었고 호스트 햄이 아닌 : 0이 추가되었습니다.

'sanitized'구성 항목은 다음과 같습니다.

DEVICE /dev/sdf1 /dev/sde1 /dev/sdd1

CREATE owner=root group=disk mode=0660 auto=yes

HOMEHOST <system>

MAILADDR root


ARRAY /dev/md0 metadata=1.2 name=tanserv:0 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b


Here is the output from mdstat

cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sdd1[0] sdf1[3] sde1[1]
1953517568 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>


fdisk shows the following:

fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bf62e

Device Boot Start End Blocks Id System
/dev/sda1 * 1 9443 75846656 83 Linux
/dev/sda2 9443 9730 2301953 5 Extended
/dev/sda5 9443 9730 2301952 82 Linux swap / Solaris

Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000de8dd

Device Boot Start End Blocks Id System
/dev/sdb1 1 91201 732572001 8e Linux LVM

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00056a17

Device Boot Start End Blocks Id System
/dev/sdc1 1 60801 488384001 8e Linux LVM

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ca948

Device Boot Start End Blocks Id System
/dev/sdd1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/dm-0: 1250.3 GB, 1250254913536 bytes
255 heads, 63 sectors/track, 152001 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/sde: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x93a66687

Device Boot Start End Blocks Id System
/dev/sde1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe6edc059

Device Boot Start End Blocks Id System
/dev/sdf1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/md0: 2000.4 GB, 2000401989632 bytes
2 heads, 4 sectors/track, 488379392 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

제안에 따라 수퍼 블록을 정리하고 --assume-clean옵션으로 배열을 다시 만들었지 만 운이 전혀 없습니다.

최소한 일부 데이터를 되살리는 데 도움이되는 도구가 있습니까? 누군가가 데이터를 파괴하기 위해 동기화 할 때 mdadm --create가 무엇을 어떻게 수행하는지 말해 줄 수 있습니까?

공격대를 재 작성한 후 fsck.ext4 / dev / md0을 실행하면 다음과 같이 출력됩니다.

root @ tanserv : / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41.14 (2010 년 12 월 22 일) fsck.ext4 : 수퍼 블록이 유효하지 않고 백업 블록을 시도 중 ... fsck.ext4 : 수퍼 블록의 잘못된 마법 번호 / dev / md0을 열려고 시도하는 동안 차단

수퍼 블록을 읽을 수 없거나 올바른 ext2 파일 시스템을 설명하지 않습니다. 장치가 유효하고 실제로 ext2 파일 시스템을 포함하고 (스왑 또는 ufs 또는 다른 것이 아닌) 슈퍼 블록이 손상된 경우 대체 슈퍼 블록으로 e2fsck를 실행하려고 할 수 있습니다. e2fsck -b 8193


내가 시도한 Per Shanes의 제안

root@tanserv:/home/mushegh# mkfs.ext4 -n /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
122101760 inodes, 488379392 blocks
24418969 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
14905 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

모든 백업 블록과 함께 fsck.ext4를 실행하지만 모두 다음을 반환했습니다.

root@tanserv:/home/mushegh# fsck.ext4 -b 214990848 /dev/md0
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Invalid argument while trying to open /dev/md0

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
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>

어떤 제안?

문안 인사!


1
아마도 언젠가 사람들은 왜 RAID5가 끔찍한 아이디어인지 깨달을 것입니다. 그때까지 1) 사람들은 데이터를 잃게됩니다. 2) 이와 같은 질문이 있습니다.
Tom O'Connor

11
@Tom O'Connor ... 분명히, RAID5는 사용자 오류에 대한 책임이 있기 때문입니다. : rolleyes :
Reality Extractor

2
Shane의 답변이 데이터를 절약 할 수 있기를 바라지 만 RAID만으로는 스토리지에 가장 적합한 이유를 입증 할 수 있기를 바랍니다. 백업도 필요합니다. (하지만 질문과 서사시 답변에 +1)
tombull89

4
자주 반복되는 것을 알고 있지만 습격은 백업 솔루션이 아닙니다 . 메시지는 실제로 집으로 운전해야합니다.
Sirex

답변:


89

Ok-문제에 대해 무언가를 괴롭 히고 있었기 때문에 VM을 시작하여 예상되는 동작에 뛰어 들었습니다. 나는 잠시 후에 나를 괴롭히는 것에 도착할 것이다. 먼저 이것을 말하겠습니다.

무엇이든 시도하기 전에이 드라이브를 백업하십시오 !!

재 동기화를 넘어 이미 손상을 입었을 수 있습니다. 당신이 말했을 때의 의미를 명확히 할 수 있습니까?

제안에 따라 수퍼 블록을 정리하고 --assume-clean 옵션을 사용하여 배열을 다시 만들었지 만 운이 없었습니다.

를 실행했다면 mdadm --misc --zero-superblock괜찮을 것입니다.

어쨌든, 새로운 디스크를 청소하고 디스크에 더 이상 쓸 수있는 작업을하기 전에 정확한 현재 이미지를 가져옵니다.

dd if=/dev/sdd of=/path/to/store/sdd.img

그것은 .. 이것들에 저장된 데이터는 놀랍게도 재 동기화에 충격적으로 탄력적 인 것처럼 보입니다. 계속 읽으십시오. 희망이 있으며 이것이 대답 길이 제한에 도달 한 날 일 수 있습니다.


최고의 시나리오

시나리오를 재현하기 위해 VM을 함께 던졌습니다. 드라이브는 단지 100MB이므로 각 재 동기화에서 영원히 기다리지 않을 것입니다. 그렇지 않으면 꽤 정확한 표현이어야합니다.

512k 청크, 왼쪽 대칭 레이아웃, 문자 순서의 디스크 등 가능한 일반적으로 기본 배열을 구축했습니다. 특별한 것은 없습니다.

root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

여태까지는 그런대로 잘됐다; 파일 시스템을 만들어서 데이터를 만들어 봅시다.

root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

승인. 파일 시스템과 일부 데이터 ( "data" datafile, 5MB 상당의 임의의 SHA1 해시가있는 임의 데이터 randomdata)가 있습니다. 다시 만들 때 어떤 일이 발생하는지 봅시다.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

이 작은 디스크로 재 동기화가 매우 빠르게 완료되었지만 발생했습니다. 여기에 저를 괴롭히는 것이 있습니다. 당신의 fdisk -l출력. md장치 에 파티션 테이블 이없는 것은 전혀 문제가되지 않습니다. 파일 시스템은 파티션 테이블이없는 가짜 블록 장치에 직접 상주합니다.

root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn't contain a valid partition table

예, 파티션 테이블이 없습니다. 그러나...

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

재 동기화 후 완벽하게 유효한 파일 시스템. 그래서 좋습니다. 데이터 파일을 확인합시다 :

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

견고 – 데이터 손상이 전혀 없습니다! 그러나 이것은 정확히 동일한 설정이므로 두 RAID 그룹간에 다르게 매핑 된 것은 없습니다. 우리가 그것을 깨뜨리기 전에 이것을 떨어 뜨리 자.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1

물러나

이 문제를 해결하기 전에 왜 깨지기 어려운지 이야기 해 봅시다. RAID 5는 어레이의 다른 모든 디스크에있는 블록과 동일한 크기의 영역을 보호하는 패리티 블록을 사용하여 작동합니다. 패리티는 하나의 특정 디스크에만있는 것이 아니라 정상적인 작동 상태에서 디스크 전체에 읽기로드를 더 잘 분산시키기 위해 디스크를 균등하게 회전시킵니다.

패리티를 계산하는 XOR 연산은 다음과 같습니다.

DISK1  DISK2  DISK3  DISK4  PARITY
1      0      1      1    = 1
0      0      1      1    = 0
1      1      1      1    = 0

따라서 패리티는 디스크간에 분산됩니다.

DISK1  DISK2  DISK3  DISK4  DISK5
DATA   DATA   DATA   DATA   PARITY
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA

재 동기는 일반적으로 사용하지 않거나 누락 된 디스크를 교체 할 때 수행됩니다. mdadm create디스크의 데이터가 RAID의 구조와 일치하는지 확인하기 위해 수행되었습니다 . 이 경우 어레이 사양의 마지막 디스크는 '동기화'된 디스크입니다. 다른 디스크의 기존 데이터는 모두 동기화에 사용됩니다.

따라서 '새'디스크의 모든 데이터가 지워지고 다시 작성됩니다. 거기에 있었던 것에 대한 패리티 블록으로부터 새로운 데이터 블록을 구축하거나, 새로운 패리티 블록을 구축하는 것.

멋진 점은이 두 가지에 대한 절차가 동일하다는 것입니다. 나머지 디스크의 데이터에 대한 XOR 작업입니다. 이 경우의 재 동기화 프로세스는 레이아웃에서 특정 블록이 패리티 블록이어야한다는 사실을 알고있을 수 있으며 실제로는 오래된 데이터 블록을 다시 생성 할 때 새로운 패리티 블록을 구축한다고 생각합니다. 그래서 그것이 생각 하는 경우에도 :

DISK1  DISK2  DISK3  DISK4  DISK5
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA
DATA   DATA   PARITY DATA   DATA

... DISK5위의 레이아웃에서 다시 작성 중일 수 있습니다 .

따라서 어레이가 잘못 구축 된 경우에도 데이터가 일관되게 유지 될 수 있습니다.


작품에서 원숭이 던지기

(렌치가 아니라 원숭이 전체)

시험 1 :

배열을 잘못된 순서로 만들어 보자! sdc다음 sdd, 다음 sdb..

root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

좋아, 그게 다 잘 됐어. 파일 시스템이 있습니까?

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
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>

아니! 왜 그런가요? 데이터가 모두있는 동안 순서가 잘못 되었기 때문입니다. 한 번 512KB의 A, 그 다음 512KB의 B, A, B 등이 이제 B, A, B, A로 셔플되었습니다. 디스크는 이제 파일 시스템 검사기에서 흔들리는 것처럼 보이므로 실행되지 않습니다. 의 결과 mdadm --misc -D /dev/md1는 우리에게 더 자세한 정보 를 제공합니다. 다음과 같이 보입니다 :

Number   Major   Minor   RaidDevice State
   0       8       33        0      active sync   /dev/sdc1
   1       8       49        1      active sync   /dev/sdd1
   3       8       17        2      active sync   /dev/sdb1

다음과 같이 보일 때 :

Number   Major   Minor   RaidDevice State
   0       8       17        0      active sync   /dev/sdb1
   1       8       33        1      active sync   /dev/sdc1
   3       8       49        2      active sync   /dev/sdd1

그래서 그것은 모두 훌륭합니다. 이번에는 새로운 패리티 블록으로 모든 데이터 블록을 덮어 썼습니다. 올바른 순서로 다시 작성하십시오.

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

깔끔한, 여전히 파일 시스템이 있습니다! 여전히 데이터가 있습니까?

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

성공!

시험 2

자, 청크 크기를 변경하고 그것이 우리에게 약간의 파손을 가져 오는지 봅시다.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
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>

예, 이런 식으로 설정하면 문제가 발생합니다. 그러나 우리는 회복 할 수 있습니까?

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

다시 성공!

시험 3

이것은 내가 데이터를 확실히 죽일 것이라고 생각한 것입니다-다른 레이아웃 알고리즘을 수행합시다!

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).

무섭고 나쁜 것-그것은 무언가를 발견했다고 생각하고 약간의 수정을 원합니다! Ctrl+ C!

Clear<y>? cancelled!

fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1

좋아, 위기를 피했다. 잘못된 레이아웃으로 다시 동기화 한 후에도 데이터가 손상되지 않았는지 확인하십시오.

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

성공!

시험 4

또한 수퍼 블록 제로화가 그렇게 빨리 해롭지 않다는 것을 증명해 보자.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

예, 별거 아니에요

시험 5

우리가 가진 모든 것을 던져 보자. 이전의 모든 4 가지 테스트가 결합되었습니다.

  • 잘못된 기기 주문
  • 잘못된 청크 크기
  • 잘못된 레이아웃 알고리즘
  • 수퍼 블록 제로화 (두 가지 생성간에이 작업을 수행함)

앞으로!

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
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>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1

판결?

root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

와우.

따라서 이러한 작업 중 어떤 것도 데이터를 손상시키지 않은 것으로 보입니다. 솔직히이 결과에 놀랐습니다. 청크 크기 변경에서 중간 정도의 데이터 손실 가능성과 레이아웃 변경에서 약간의 손실이 예상되었습니다. 나는 오늘 무언가를 배웠다.


그래서 .. 어떻게 내 데이터를 얻을 수 있습니까 ??

기존 시스템에 대한 정보는 최대한 도움이 될 것입니다. 파일 시스템 유형을 알고있는 경우 /proc/mdstat드라이브 순서, 알고리즘, 청크 크기 및 메타 데이터 버전에 대한 정보 가있는 오래된 사본이있는 경우 . mdadm의 이메일 알림이 설정되어 있습니까? 그렇다면 오래된 것을 찾으십시오. 그렇지 않은 경우 확인하십시오 /var/spool/mail/root. ~/.bash_history원래 빌드가 있는지 확인하십시오 .

따라서해야 할 일 목록 :

  1. dd무엇이든하기 전에 디스크를 백업하십시오 !!
  2. fsck현재 활성화 된 md를 시도하십시오 -이전과 동일한 순서로 빌드했을 수 있습니다. 파일 시스템 유형을 알고 있다면 도움이됩니다. 특정 fsck도구를 사용하십시오. 도구 중 하나라도 문제를 해결하도록 제안한 경우 실제로 유효한 파일 시스템을 찾았는지 확실하지 않으면 도구를 사용하지 마십시오! 당신 fsck을 위해 무언가를 고치 겠다는 제안이 있다면, 실제로 도움이되는지 아니면 데이터를 핵화하려고하는지에 대한 의견을 남기십시오.
  3. 다른 매개 변수로 배열을 작성하십시오. 당신이 오래된 것을 가지고 있다면, 당신은 /proc/mdstat그것이 보여주는 것을 모방 할 수 있습니다. 그렇지 않다면, 당신은 어두움에 처해 있습니다. 다른 드라이브 주문을 모두 시도하는 것이 합리적이지만 가능한 모든 주문으로 가능한 모든 청크 크기를 확인하는 것은 쓸데없는 일입니다. 각각에 대해 fsck유망한 것이 있는지 확인하십시오.

그게 다야. 소설에 대해 죄송합니다. 궁금한 점이 있으면 언제든지 의견을 남겨주세요.

각주 : 22,000 자 미만; 길이 제한 8k + 부끄러워


8
그것은 놀라운 답변입니다.
Antoine Benkemoun

3
무슨 말을 해야할지 모르겠다 ... 브라보 !!! 셰인 매든에게 디스크를 백업하고 제안을 시작하겠습니다. 고마워요, 정말 고마워요 !!!
Brigadieren

3
그냥 ... 와우 훌륭한 답변. 30,000 자 (영문 기준)의 글자 수 한도를 깰 수있는 유일한 방법은 Evan Andersons의 "Subnetting 작동 방식"에세이 뿐이라고 생각합니다.
tombull89

3
내가 걱정하는 한 SF에 대한 최고의 답변.
Chopper3

14
당신은 인터넷에서 이깁니다.
Mark Henderson

5

좋으면 고장난 RAID-5 어레이를 읽을 수있는 복구 소프트웨어를 사용하여 파일을 복구하는 데 성공할 수 있습니다. Zero Assumption Recovery 는 이전에 성공한 것입니다.

그러나 새 배열을 만드는 프로세스가 진행되어 모든 데이터가 손상되었는지 확실하지 않으므로 마지막 기회가 될 수 있습니다.


고마워 마크. 나는 그것을 시도 할 것이다. 드라이브를 수정하는지 알고 있습니까? 그렇다면 디스크 사본을 만들고 다른 도구를 사용해 보도록하겠습니다.
Brigadieren

@Brigadieren-아니요, 죄송합니다. RAID5 작동 방식의 복잡한 점에 익숙하지 않습니다.
Mark Henderson

@Brigadieren mdadm documentation 에 따르면 작성 프로세스는 데이터를 파괴하지 않고 재 동기화하지만 원래와 일치하지 않는 지오메트리를 선택한 경우 새 패리티를 작성하여 데이터를 파괴했을 수 있습니다. 나중에 자유 시간이 있으면 VM에서 상황을 다시 작성하여 통찰력을 추가 할 수 있는지 확인할 수 있습니다. 디스크에 쓰는 복구 단계를 시도하기 전에 드라이브의 전체 복사본을 가져 오는 것이 좋습니다. 추가 드라이브를 만들어 복사 할 수도 있습니다.
Shane Madden

동기화의 원인이 무엇인지 잘 모르겠습니다. 정전으로 인해 어레이가 성능이 저하되었다는 사실 또는 다른 점이 있습니까? mdadm --create가 원래 제공된 순서와 다르게 드라이브 순서를 지정하는지 여부를 구별하는지 궁금합니다.
Brigadieren

@Brigadieren 동기화는 항상 생성시 발생합니다.
Shane Madden

5

비슷한 문제가있었습니다 :
소프트웨어 RAID5 어레이의 고장 후 나는 mdadm --create그것을주지 않고 발사 --assume-clean하여 더 이상 어레이를 마운트 할 수 없었습니다. 2 주 동안 파고 난 후에 마침내 모든 데이터를 복원했습니다. 아래 절차를 통해 누군가의 시간을 절약 할 수 있기를 바랍니다.

긴 이야기 짧은

이 문제는 mdadm --create두 가지 측면에서 원래 배열과 다른 새 배열을 만들었 기 때문에 발생했습니다 .

  • 다른 순서의 파티션
  • 다른 RAID 데이터 오프셋

이 화려한에 표시 된 것으로 셰인 매든 의해 답변 , mdadm --create대부분의 경우 데이터를 파괴하지 않습니다! 파티션 순서와 데이터 오프셋을 찾은 후 배열을 복원하고 배열에서 모든 데이터를 추출 할 수 있습니다.

전제 조건

RAID 수퍼 블록의 백업이 없었기 때문에 Xubuntu 12.04.0을 설치하는 동안 생성 된 8 개의 파티션에있는 RAID5 어레이라는 것을 알았습니다. ext4 파일 시스템이있었습니다. 또 다른 중요한 지식은 RAID 어레이에도 저장된 파일의 사본이었습니다.

도구

Xubuntu 12.04.1 라이브 CD는 모든 작업을 수행하는 데 사용되었습니다. 상황에 따라 다음 도구 중 일부가 필요할 수 있습니다.

데이터 오프셋을 지정할 수있는 mdadm 버전

sudo apt-get install binutils-dev git
git clone -b data_offset git://neil.brown.name/mdadm
cd mdadm
make

bgrep-이진 데이터 검색

curl -L 'https://github.com/tmbinc/bgrep/raw/master/bgrep.c' | gcc -O2 -x c -o bgrep -

hexdump, e2fsck, mount 및 16 진수 계산기 -repos의 표준 도구

전체 백업으로 시작

장치 파일의 이름 지정 /dev/sda2 /dev/sdb2등은 영구적이지 않으므로 다음과 같이 드라이브 일련 번호를 기록하는 것이 좋습니다.

sudo hdparm -I /dev/sda

그런 다음 외장 HDD를 연결하고 다음과 같이 RAID 어레이의 모든 파티션을 백업하십시오.

sudo dd if=/dev/sda2 bs=4M | gzip > serial-number.gz

원래 RAID5 레이아웃 결정

다양한 레이아웃이 여기에 설명되어 있습니다 http://www.accs.com/p_and_p/RAID/LinuxRAID.html
데이터의 스트립은 원래 배열에 조직되었다 방법을 찾기 위해, 당신은 당신이 있었는지하는 임의 보이는 파일의 사본이 필요합니다 배열에 저장됩니다. 현재 사용되는 기본 청크 크기 mdadm는 512KB입니다. N 개의 파티션 배열의 경우 최소한 (N + 1) * 512KB 크기의 파일이 필요합니다. JPEG 또는 비디오는 이진 데이터의 상대적으로 고유 한 하위 문자열을 제공하므로 좋습니다. 파일이라고 가정 해 봅시다 picture.jpg. 100k에서 시작하여 512k 씩 증가하는 N + 1 위치에서 32 바이트의 데이터를 읽습니다.

hexdump -n32 -s100k -v -e '/1 "%02X"' picture.jpg ; echo
DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2
hexdump -n32 -s612k -v -e '/1 "%02X"' picture.jpg ; echo
AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7
hexdump -n32 -s1124k -v -e '/1 "%02X"' picture.jpg ; echo
BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA
...

그런 다음 모든 원시 파티션에서 이러한 바이트 스트링을 모두 검색하므로 총 (N + 1) * N 명령은 다음과 같습니다.

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sda2
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdb2
...
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdh2
/dev/sdh2: 52a7ff000
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/sda2
/dev/sdb2: 52a87f000
...

이러한 명령은 다른 디스크에 대해 병렬로 실행될 수 있습니다. 38GB 파티션을 검사하는 데 약 12 ​​분이 걸렸습니다. 필자의 경우 모든 32 바이트 문자열은 8 개의 드라이브 중 한 번만 발견되었습니다. bgrep에 의해 리턴 된 오프셋을 비교함으로써 다음과 같은 그림을 얻을 수 있습니다 :

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          | P |   |   |   |   |   |   | 1 |
| 52a87f000          | 2 | 3 | 4 | 5 | 6 | 7 | 8 | P |
| 52a8ff000          |   |   |   |   |   |   | P | 9 |

일반적인 왼쪽 대칭 레이아웃이 기본 설정입니다 mdadm. 더 중요한 것은 이제 파티션 순서를 알고 있다는 것입니다. 그러나 순환 적으로 이동할 수 있으므로 어레이에서 첫 번째 파티션이 무엇인지 알 수 없습니다.

발견 된 오프셋 사이의 거리도 기록하십시오. 제 경우에는 512KB였습니다. 청크 크기는 실제로이 거리보다 작을 수 있으며,이 경우 실제 레이아웃이 다릅니다.

원래 청크 크기 찾기

동일한 파일 picture.jpg을 사용하여 서로 다른 간격으로 32 바이트의 데이터를 읽습니다. 우리는 위에서 오프셋 100k의 데이터가 놓여 있고 /dev/sdh2오프셋 612k가에 /dev/sdb2있고 1124k가에 있다는 것을 알고 있습니다 /dev/sdd2. 이는 청크 크기가 512KB보다 크지 않음을 나타냅니다. 512KB보다 작지 않은지 확인합니다. 이를 위해 오프셋 356k에서 바이트 문자열을 덤프하고 그것이 어떤 파티션에 있는지 살펴보십시오.

hexdump -n32 -s356k -v -e '/1 "%02X"' P1080801.JPG ; echo
7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A
sudo ./bgrep 7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A /dev/sdb2
/dev/sdb2: 52a83f000

청크 크기가 256KB가 아님을 나타내는 오프셋 612k와 동일한 파티션에 있습니다. 비슷한 방식으로 더 작은 청크 크기를 제거합니다. 512KB 청크가 유일한 가능성이었습니다.

레이아웃에서 첫 번째 파티션 찾기

이제 파티션의 순서는 알지만 어떤 파티션이 첫 번째 파티션인지, 어떤 RAID 데이터 오프셋이 사용되었는지는 알 수 없습니다. 이 두 가지 미지수를 찾기 위해 올바른 청크 레이아웃과 작은 데이터 오프셋을 가진 RAID5 어레이를 생성하고이 새로운 어레이에서 파일 시스템의 시작을 검색합니다.

먼저 올바른 순서의 파티션으로 배열을 만듭니다.

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sda2 /dev/sdh2

우리는 명령을 통해 주문이 준수되는지 확인합니다.

sudo mdadm --misc -D /dev/md126
...
Number   Major   Minor   RaidDevice State
   0       8       18        0      active sync   /dev/sdb2
   1       8       50        1      active sync   /dev/sdd2
   2       8       34        2      active sync   /dev/sdc2
   3       8       66        3      active sync   /dev/sde2
   4       8       82        4      active sync   /dev/sdf2
   5       8       98        5      active sync   /dev/sdg2
   6       8        2        6      active sync   /dev/sda2
   7       8      114        7      active sync   /dev/sdh2

이제 RAID 어레이에서 N + 1 알려진 바이트 스트링의 오프셋을 결정합니다. 나는 밤 동안 스크립트를 실행합니다 (Live CD는 sudo에서 암호를 요구하지 않습니다 :).

#!/bin/bash
echo "1st:"
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126
echo "2nd:"
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/md126
echo "3rd:"
sudo ./bgrep BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA /dev/md126
...
echo "9th:"
sudo ./bgrep 99B5A96F21BB74D4A630C519B463954EC096E062B0F5E325FE8D731C6D1B4D37 /dev/md126

주석이있는 출력 :

1st:
/dev/md126: 2428fff000 # 1st
2nd:
/dev/md126: 242947f000 # 480000 after 1st
3rd:                   # 3rd not found
4th:
/dev/md126: 242917f000 # 180000 after 1st
5th:
/dev/md126: 24291ff000 # 200000 after 1st
6th:
/dev/md126: 242927f000 # 280000 after 1st
7th:
/dev/md126: 24292ff000 # 300000 after 1st
8th:
/dev/md126: 242937f000 # 380000 after 1st
9th:
/dev/md126: 24297ff000 # 800000 after 1st

이 데이터를 바탕으로 세 번째 문자열을 찾을 수 없음을 알 수 있습니다. 이것은 덩어리 /dev/sdd2가 패리티에 사용됨을 의미합니다 . 다음은 새 배열의 패리티 위치를 보여줍니다.

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          |   |   | P |   |   |   |   | 1 |
| 52a87f000          | 2 | P | 4 | 5 | 6 | 7 | 8 |   |
| 52a8ff000          | P |   |   |   |   |   |   | 9 |

우리의 목표는 패리티 청크를 올바른 위치로 옮기기 위해 어레이를 시작할 파티션을 추론하는 것입니다. 패리티는 두 개의 청크를 왼쪽으로 이동해야하기 때문에 파티션 순서는 두 단계를 오른쪽으로 이동해야합니다. 따라서이 데이터 오프셋의 올바른 레이아웃은 ahbdcefg다음과 같습니다.

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sda2 /dev/sdh2 /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 

이 시점에서 RAID 어레이는 올바른 형식의 데이터를 포함합니다. RAID 데이터 오프셋이 원래 어레이와 같도록 운이 좋으면 파티션을 마운트 할 수 있습니다. 불행히도 이것은 나의 경우가 아닙니다.

데이터 일관성 확인

picture.jpg어레이에서 복사본을 추출하여 데이터가 청크 스트립에서 일관성이 있는지 확인합니다 . 이를 위해 100 바이트에서 32 바이트 문자열의 오프셋을 찾습니다.

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

그런 다음 결과에서 100 * 1024를 빼고에 대해 얻은 10 진수 값을 skip=매개 변수에 사용 dd합니다. 의 count=크기는 picture.jpg바이트 단위입니다.

sudo dd if=/dev/md126 of=./extract.jpg bs=1 skip=155311300608 count=4536208

extract.jpg와 같은지 확인하십시오 picture.jpg.

RAID 데이터 오프셋 찾기

참고 : mdadm버전 3.2.3의 기본 데이터 오프셋 은 2048 섹터입니다. 그러나이 값은 시간이 지남에 따라 변경되었습니다. 원래의 배열이 작은 데이터가 현재보다 오프셋을 사용하는 경우 mdadm, 다음 mdadm --create없이 --assume-clean하여 파일 시스템의 시작을 덮어 쓸 수 있습니다.

이전 섹션에서 RAID 어레이를 만들었습니다. 개별 파티션 중 일부를 발행하여 어떤 RAID 데이터 오프셋이 있는지 확인하십시오.

sudo mdadm --examine /dev/sdb2
...
    Data Offset : 2048 sectors
...

2048 512 바이트 섹터는 1MB입니다. 청크 크기가 512KB이므로 현재 데이터 오프셋은 두 청크입니다.

이 시점에서 두 개의 청크 오프셋이 있으면 충분히 작으므로이 단락을 건너 뛸 수 있습니다.
512KB 청크의 데이터 오프셋으로 RAID5 어레이를 만듭니다. 한 청크를 일찍 시작하면 패리티가 한 단계 왼쪽으로 이동하므로 파티션 시퀀스를 한 단계 왼쪽으로 이동하여 보상합니다. 따라서 512KB 데이터 오프셋의 경우 올바른 레이아웃은 hbdcefga입니다. mdadm데이터 오프셋을 지원 하는 버전을 사용합니다 (도구 섹션 참조). 킬로바이트 단위의 오프셋이 필요합니다.

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdh2:512 /dev/sdb2:512 /dev/sdd2:512 /dev/sdc2:512 /dev/sde2:512 /dev/sdf2:512 /dev/sdg2:512 /dev/sda2:512

이제 유효한 ext4 수퍼 블록을 검색합니다. 수퍼 블록 구조는 여기에서 찾을 수 있습니다 : https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
우리는 배열의 시작 부분에서 매직 넘버가 나오는지 그리고 s_magic다음에 나오는지를 검사합니다 . 찾을 바이트 문자열은 다음과 같습니다.s_states_errors

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

명령 예 :

sudo ./bgrep 53EF01000100 /dev/md126
/dev/md126: 0dc80438

매직 넘버는 0x38 바이트부터 수퍼 블록으로 시작하므로 0x38을 빼서 오프셋을 계산하고 전체 수퍼 블록을 검사합니다.

sudo hexdump -n84 -s0xDC80400 -v /dev/md126
dc80400 2000 00fe 1480 03f8 cdd3 0032 d2b2 0119
dc80410 ab16 00f7 0000 0000 0002 0000 0002 0000
dc80420 8000 0000 8000 0000 2000 0000 b363 51bd
dc80430 e406 5170 010d ffff ef53 0001 0001 0000
dc80440 3d3a 50af 0000 0000 0000 0000 0001 0000
dc80450 0000 0000                              

이것은 유효한 수퍼 블록 인 것 같습니다. s_log_block_size0x18의 필드는 0002이므로 블록 크기는 2 ^ (10 + 2) = 4096 바이트입니다. s_blocks_count_lo0x4에서 03f81480 블록은 254GB입니다. 좋아 보인다

이제 수퍼 블록의 첫 바이트가 있는지 스캔하여 사본을 찾습니다. 16 진 출력과 비교할 때 바이트 뒤집기를 참고하십시오.

sudo ./bgrep 0020fe008014f803d3cd3200 /dev/md126
/dev/md126: 0dc80400    # offset by 1024 bytes from the start of the FS        
/dev/md126: 15c80000    # 32768 blocks from FS start
/dev/md126: 25c80000    # 98304
/dev/md126: 35c80000    # 163840
/dev/md126: 45c80000    # 229376
/dev/md126: 55c80000    # 294912
/dev/md126: d5c80000    # 819200
/dev/md126: e5c80000    # 884736
/dev/md126: 195c80000
/dev/md126: 295c80000

이는 백업 수퍼 블록의 예상 위치와 완벽하게 일치합니다.

sudo mke2fs -n /dev/md126
...
Block size=4096 (log=2)
...
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

따라서 파일 시스템은 0xdc80000 오프셋에서 시작합니다 (예 : 파티션 시작에서 225792KB). 패리티를위한 8 개의 파티션이 있으므로 오프셋을 7로 나눕니다. 이는 모든 파티션에서 33030144 바이트의 오프셋을 제공하며, 이는 정확히 63 개의 RAID 청크입니다. 현재 RAID 데이터 오프셋은 하나의 청크이므로 원래 데이터 오프셋은 64 청크 또는 32768KB라고 결론지었습니다. hbdcefga오른쪽으로 63 번 이동 하면 레이아웃이 나타납니다 bdcefgah.

마지막으로 올바른 RAID 배열을 만듭니다.

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2:32768 /dev/sdd2:32768 /dev/sdc2:32768 /dev/sde2:32768 /dev/sdf2:32768 /dev/sdg2:32768 /dev/sda2:32768 /dev/sdh2:32768
sudo fsck.ext4 -n /dev/md126
e2fsck 1.42 (29-Nov-2011)
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/md126: clean, 423146/16654336 files, 48120270/66589824 blocks
sudo mount -t ext4 -r /dev/md126 /home/xubuntu/mp

oil!


훌륭한 연습. 한 가지 참고 사항-53EF00000100은 EXT4 헤더에 유효한 앵커가 아닌 것 같습니다. ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block 에 따르면 53EF 이후 두 바이트는 0100, 0200 또는 0400 일 수 있습니다.
matt

0

나는 비슷한 문제가 있었다. Ubuntu 12.04를 새로 설치하여 OS / 부팅 드라이브를 포맷하고 다시 설치 한 다음 mdadm --create ... 명령을 실행하여 마운트 할 수 없었습니다.

유효한 수퍼 블록이나 파티션이 없다고 말했습니다.

또한 mdadm raid를 중지하면 더 이상 일반 장치를 마운트 할 수 없습니다.

mke2fs 및 e2fsck로 수퍼 블록을 복구 할 수있었습니다.

root@blackbox:~# mke2fs -n /dev/sdc1
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
91578368 inodes, 366284000 blocks
18314200 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
11179 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
  4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
  102400000, 214990848

그런 다음 실행했습니다.

e2fsck -b 32768 -y /dev/sdc1

수퍼 블록을 복원하여 드라이브를 마운트하고 읽을 수있었습니다.

내가 사용했던 수퍼 블록이나 파티션을 파괴하지 않고 배열을 작동 시키려면 :

mdadm --build /dev/md0 --level=mirror --assume-clean --raid-devices=2  /dev/sdc1 missing 

데이터를 확인한 후 다른 드라이브를 추가하겠습니다.

mdadm --add /dev/md0 /sdd1

0

앞서 제공된 정보 중 일부만 업데이트하고 있습니다. 내 마더 보드가 죽었을 때 3 디스크 raid5 어레이가 제대로 작동했습니다. 이 어레이는 /home/1.2를 / home 파티션 1.2TB로, / dev / md3을 / var 파티션 300GB로 유지했습니다.

나는 "중요한"것들에 대한 두 개의 백업과 내가 실제로 겪고 선택적으로 버려야 할 인터넷의 여러 부분에서 얻은 임의의 것들을 가지고있었습니다. 대부분의 백업은 25GB 이하의 .tar.gz 파일로 분리되었으며 별도의 / etc 사본도 백업되었습니다.

나머지 파일 시스템은 38GB의 두 개의 작은 raid0 디스크에 보관되었습니다.

내 새 컴퓨터는 이전 하드웨어와 비슷했으며 5 개의 디스크를 모두 꽂고 이전의 일반 커널을 선택하여 컴퓨터를 설치하고 실행했습니다. 그래서 깨끗한 파일 시스템을 가진 5 개의 디스크가 있었지만 디스크가 올바른 순서인지 확신 할 수 없었고 필요할 때 컴퓨터를 업그레이드하고 다른 것을 정리할 수 있도록 새로운 데비안 Jessie 버전을 설치해야했습니다 문제.

새로운 일반 시스템을 두 개의 Raid0 디스크에 설치 한 후 어레이를 다시 장착하기 시작했습니다. 디스크가 올바른 순서로 있는지 확인하고 싶었습니다. 내가해야 할 일은 다음을 발행하는 것이 었습니다.

mdadm --assemble /dev/md3 -o --no-degraded --uuid=82164ae7:9af3c5f1:f75f70a5:ba2a159a

그러나 나는하지 않았다. mdadm은 꽤 똑똑하고 uuid가 주어지면 어느 드라이브가 어디로 갈지 알아낼 수 있습니다. bios가 / dev / sdc를 / sda로 지정하더라도 mdadm은이를 올바르게 결합합니다 (YMMV).

대신 :을 발행 mdadm --create /dev/md2 without the --assume-clean하고 / dev / sde1의 재 동기화를 완료했습니다. 다음 실수는 / dev / md2, / sde1의 마지막 드라이브 대신 / dev / sdc1에서 작업하는 것이 었습니다. mdadm은 문제가 있다고 생각할 때마다 쫓겨나거나 다시 동기화되는 것이 마지막 드라이브입니다.

그 후 mdadm은 수퍼 블록을 찾을 수 없었으며 e2fsck -n도 찾을 수 없었습니다.

이 페이지를 찾은 후 드라이브의 시퀀스를 찾으려고 (완료), 유효한 데이터를 확인하고 (9MB 파일의 6MB 확인) 올바른 순서로 디스크를 가져 왔습니다 .cde, uuid를 잡았습니다. 이전 /etc/mdadm.conf에서 / md2 및 / md3을 찾아 조립을 시도했습니다.

글쎄, /dev/md3시작하고 mdadm --misc -D /dev/md3세 개의 건강한 파티션과 디스크를 올바른 순서로 보여주었습니다. /dev/md2파일 시스템을 마운트하려고 시도 할 때까지도 좋아 보였습니다.

# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.

파일 시스템의 마운트를 거부했으며 e2fsck가 수퍼 블록을 찾을 수 없습니다. 또한 위에서 설명한대로 수퍼 블록을 검사 할 때 a880 0076 또는 a880 0076 또는 5500 1176으로 발견 된 총 블록 수가 1199.79의 디스크 용량 크기와 일치하지 않아 내 mdadm이보고되었습니다. 또한 "슈퍼 블록"의 위치는 위의 게시물에있는 데이터와 일치하지 않습니다.

모든 / var을 백업하고 디스크를 닦을 준비를했습니다. / md2 만 지울 수 있는지 확인하려면 (이 시점에서 잃을 것이 아무것도 없었습니다) 다음을 무시합니다.

root@ced2:/home/richard# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
# mkfs.ext3 /dev/md2
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 292902912 4k blocks and 73228288 inodes
Filesystem UUID: a54e252f-78db-4ebb-b7ca-7dcd2edf57a4
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 


# hexdump -n84 -s0x00000400 -v /dev/md2
0000400 6000 045d 5800 1175 7799 00df 6ff0 112e
0000410 5ff5 045d 0000 0000 0002 0000 0002 0000
0000420 8000 0000 8000 0000 2000 0000 10d3 56b2
0000430 10d3 56b2 0002 ffff ef53 0001 0001 0000
0000440 0c42 56b2 0000 0000 0000 0000 0001 0000
0000450 0000 0000                              
0000454

#  ./bgrep 00605D0400587511 /dev/md2
/dev/md2: 00000400
/dev/md2: 08000000
/dev/md2: 18000000
/dev/md2: 28000000
/dev/md2: 38000000
/dev/md2: 48000000
/dev/md2: c8000000
/dev/md2: d8000000
/dev/md2: 188000000
/dev/md2: 288000000
/dev/md2: 3e8000000
/dev/md2: 798000000
/dev/md2: ab8000000
etc

UUID 로의 변경을 제외하고는 모두 괜찮아 보였다. 몇 번 더 검사 한 후 600GB의 백업 데이터를 / dev / md2에 썼습니다. 그런 다음 마운트를 해제하고 드라이브를 다시 마운트하려고했습니다.

# mdadm --assemble /dev/md2 uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7
mdadm: cannot open device uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7: No such file or directory
mdadm: uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 has no superblock - assembly aborted

장난하니? 파일의 600GB는 어떻습니까?

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 not identified in config file.

아-쉽게 고쳐. /etc/mdadm.conf에서 주석 해제 된 한 줄

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 has been started with 3 drives.

# e2fsck -n /dev/md2
e2fsck 1.42.12 (29-Aug-2014)
/dev/md2: clean, 731552/73228288 files, 182979586/292902912 blocks

이피!

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.