Khôi phục dữ liệu RAID 5 sau khi tạo mảng mới thay vì sử dụng lại


35

Mọi người hãy giúp đỡ - Tôi là một người mới với một cơn đau đầu lớn trong tay (tình huống bão hoàn hảo).

Tôi có một hdd 3 1tb trên Ubuntu 11.04 được cấu hình như một cuộc đột kích phần mềm 5. Dữ liệu đã được sao chép hàng tuần vào một ổ cứng khác của máy tính cho đến khi hoàn toàn thất bại và bị ném đi. Vài ngày trước, chúng tôi bị mất điện và sau khi khởi động lại, hộp của tôi sẽ không đột kích. Trong trí tuệ vô hạn của tôi, tôi đã nhập

mdadm --create -f...

lệnh thay vì

mdadm --assemble

và không nhận thấy chuyến đi mà tôi đã làm cho đến sau đó. Nó bắt đầu mảng xuống cấp và tiến hành xây dựng và đồng bộ hóa nó mất ~ 10 giờ. Sau khi tôi trở lại, tôi thấy rằng mảng đã hoạt động thành công nhưng cuộc đột kích thì không

Tôi có nghĩa là các ổ đĩa riêng lẻ được phân vùng (loại phân vùng f8) nhưng md0thiết bị thì không. Nhận ra trong nỗi kinh hoàng những gì tôi đã làm tôi đang cố gắng tìm một số giải pháp. Tôi chỉ cầu nguyện rằng --createđã không ghi đè lên toàn bộ nội dung của trình điều khiển cứng.

Ai đó có thể giúp tôi giải quyết vấn đề này không - dữ liệu trên ổ đĩa rất quan trọng và duy nhất ~ 10 năm ảnh, tài liệu, v.v.

Có thể bằng cách chỉ định các ổ đĩa cứng tham gia sai thứ tự có thể mdadmghi đè lên chúng? khi tôi làm

mdadm --examine --scan 

Tôi nhận được một cái gì đó như ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

Điều thú vị là tên đã từng là 'đột kích' và không phải là chủ nhà hame với: 0 được thêm vào.

Dưới đây là các mục cấu hình 'được khử trùng':

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

Theo từng gợi ý, tôi đã dọn sạch các siêu khóa và tạo lại mảng với --assume-cleantùy chọn nhưng không có chút may mắn nào.

Có công cụ nào giúp tôi hồi sinh ít nhất một số dữ liệu không? Ai đó có thể cho tôi biết những gì và làm thế nào mdadm - tạo ra khi đồng bộ hóa để hủy dữ liệu để tôi có thể viết một công cụ để bỏ làm bất cứ điều gì đã được thực hiện?

Sau khi tạo lại cuộc đột kích, tôi chạy fsck.ext4 / dev / md0 và đây là đầu ra

root @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41,14 (22 tháng 12 năm 2010) fsck.ext4: Superblock không hợp lệ, thử các khối sao lưu ... fsck.ext4: Số ma thuật xấu trong siêu- chặn trong khi cố gắng mở / dev / md0

Superblock không thể được đọc hoặc không mô tả một hệ thống tập tin ext2 chính xác. Nếu thiết bị hợp lệ và nó thực sự chứa một hệ thống tập tin ext2 (và không trao đổi hoặc ufs hoặc thứ gì khác), thì siêu khối bị hỏng và bạn có thể thử chạy e2fsck với một siêu khối thay thế: e2fsck -b 8193


Tôi đã thử gợi ý của 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

và chạy fsck.ext4 với mọi khối sao lưu nhưng tất cả đều trả về như sau:

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>

Bất kỳ đề xuất?

Trân trọng!


1
Có lẽ một ngày nào đó mọi người có thể nhận ra tại sao RAID5 là một ý tưởng tồi tệ. Cho đến lúc đó, 1) mọi người sẽ mất dữ liệu. 2) Chúng tôi sẽ nhận được câu hỏi như thế này.
Tom O'Connor

11
@Tom O'Connor ... vì rõ ràng, RAID5 là lỗi của người dùng. : xe đẩy:
trích xuất thực tế

2
Hy vọng rằng, câu trả lời của Shane có thể lưu dữ liệu, nhưng, một lần nữa, bằng chứng tại sao một mình RAID không tốt nhất để lưu trữ. Cần sao lưu quá. (nhưng +1 cho câu hỏi và câu trả lời hoành
tráng

4
Tôi biết nó được lặp đi lặp lại thường xuyên, nhưng đột kích không phải là một giải pháp dự phòng . Thông điệp thực sự cần lái xe về nhà.
Sirex

Câu trả lời:


89

Ok - một cái gì đó đã làm tôi khó chịu về vấn đề của bạn, vì vậy tôi đã kích hoạt một VM để đi sâu vào hành vi nên được mong đợi. Tôi sẽ nhận được những gì đang làm phiền tôi trong một phút; đầu tiên hãy để tôi nói điều này:

Sao lưu các ổ đĩa này trước khi thử bất cứ điều gì !!

Bạn có thể đã gây ra thiệt hại vượt quá những gì mà resync đã làm; bạn có thể nói rõ ý của bạn khi bạn nói:

Theo từng gợi ý, tôi đã dọn sạch các siêu khóa và tạo lại mảng với tùy chọn --assume-clean nhưng không có chút may mắn nào.

Nếu bạn chạy một mdadm --misc --zero-superblock, sau đó bạn sẽ ổn.

Dù sao, hãy nhặt sạch một số đĩa mới và lấy chính xác hình ảnh hiện tại của chúng trước khi làm bất cứ điều gì có thể ghi thêm vào các đĩa này.

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

Điều đó đang được nói .. có vẻ như dữ liệu được lưu trữ trên những thứ này có khả năng phục hồi đáng kinh ngạc đối với các resyncs bướng bỉnh. Đọc tiếp, có hy vọng, và đây có thể là ngày mà tôi đạt đến giới hạn độ dài câu trả lời.


Kịch bản trường hợp tốt nhất

Tôi đã cùng nhau tạo một VM để tạo lại kịch bản của bạn. Các ổ đĩa chỉ có 100 MB, vì vậy tôi sẽ không chờ đợi mãi trên mỗi đồng bộ lại, nhưng đây sẽ là một đại diện khá chính xác.

Xây dựng mảng càng rộng rãi và mặc định càng tốt - các khối 512k, bố cục đối xứng trái, các đĩa theo thứ tự chữ .. không có gì đặc biệt.

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>

Càng xa càng tốt; hãy tạo một hệ thống tập tin và đặt một số dữ liệu vào nó.

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

Được. Chúng tôi đã có một hệ thống tệp và một số dữ liệu ("dữ liệu" datafilevà dữ liệu ngẫu nhiên trị giá 5 MB với hàm băm SHA1 đó randomdata) trên đó; Hãy xem điều gì xảy ra khi chúng ta tạo lại.

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>

Đồng bộ lại kết thúc rất nhanh với các đĩa nhỏ này, nhưng nó đã xảy ra. Vì vậy, đây là những gì đã làm phiền tôi từ trước đó; fdisk -lđầu ra của bạn . Không có bảng phân vùng trên mdthiết bị hoàn toàn không phải là vấn đề. Hệ thống tập tin của bạn nằm trực tiếp trên thiết bị khối giả không có bảng phân vùng.

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

Vâng, không có bảng phân vùng. Nhưng...

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

Hệ thống tập tin hoàn toàn hợp lệ, sau khi đồng bộ lại. Vậy là tốt rồi; hãy kiểm tra các tệp dữ liệu của chúng tôi:

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

Rắn - không có dữ liệu tham nhũng! Nhưng đây là với cùng một cài đặt, vì vậy không có gì được ánh xạ khác nhau giữa hai nhóm RAID. Hãy bỏ thứ này xuống trước khi chúng ta cố gắng phá vỡ nó.

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

Lùi lại một bước

Trước khi chúng ta cố gắng phá vỡ điều này, hãy nói về lý do tại sao nó khó phá vỡ. RAID 5 hoạt động bằng cách sử dụng khối chẵn lẻ bảo vệ một khu vực có cùng kích thước với khối trên mọi đĩa khác trong mảng. Tính chẵn lẻ không chỉ trên một đĩa cụ thể, nó được xoay quanh các đĩa một cách đồng đều để phân tán tải đọc tốt hơn trên các đĩa trong hoạt động bình thường.

Thao tác XOR để tính chẵn lẻ trông như thế này:

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

Vì vậy, tính chẵn lẻ được trải ra giữa các đĩa.

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

Đồng bộ lại thường được thực hiện khi thay thế một đĩa chết hoặc mất tích; nó cũng được thực hiện mdadm createđể đảm bảo rằng dữ liệu trên các đĩa phù hợp với hình dạng của RAID được cho là như thế nào. Trong trường hợp đó, đĩa cuối cùng trong thông số mảng là ổ đĩa được 'đồng bộ hóa' - tất cả dữ liệu hiện có trên các đĩa khác được sử dụng để đồng bộ hóa.

Vì vậy, tất cả dữ liệu trên đĩa 'mới' bị xóa sạch và được xây dựng lại; hoặc xây dựng các khối dữ liệu mới từ các khối chẵn lẻ cho những gì đáng lẽ phải có ở đó, hoặc nếu không thì xây dựng các khối chẵn lẻ mới.

Điều thú vị là quy trình cho cả hai điều này hoàn toàn giống nhau: một thao tác XOR trên dữ liệu từ các đĩa còn lại. Quá trình đồng bộ hóa trong trường hợp này có thể có trong bố cục của nó rằng một khối nhất định phải là một khối chẵn lẻ và nghĩ rằng nó đang xây dựng một khối chẵn lẻ mới, trong khi thực tế nó đang tạo lại một khối dữ liệu cũ. Vì vậy, ngay cả khi nó nghĩ rằng nó đang xây dựng này:

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

... nó có thể được xây dựng lại DISK5từ cách bố trí ở trên.

Vì vậy, dữ liệu có thể duy trì ổn định ngay cả khi mảng được xây dựng sai.


Ném một con khỉ trong công trình

(không phải cờ lê; toàn bộ khỉ)

Bài kiểm tra 1:

Hãy tạo ra các mảng theo thứ tự sai! sdc, sau đó sdd, sau đó 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>

Ok, đó là tất cả tốt và tốt. Chúng ta có một hệ thống tập tin?

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>

Không! Tại sao vậy? Bởi vì trong khi dữ liệu ở đó, nó không đúng thứ tự; cái gì đã từng là 512KB của A, sau đó là 512KB của B, A, B, v.v. Đầu ra của mdadm --misc -D /dev/md1cho chúng tôi chi tiết hơn; Nó trông như thế này:

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

Khi nó sẽ trông như thế này:

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

Vì vậy, đó là tất cả tốt và tốt. Chúng tôi ghi đè lên một loạt các khối dữ liệu với các khối chẵn lẻ mới lần này. Tạo lại, với thứ tự đúng ngay bây giờ:

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

Không, vẫn còn một hệ thống tập tin ở đó! Vẫn có dữ liệu?

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

Sự thành công!

Kiểm tra 2

Ok, chúng ta hãy thay đổi kích thước khối và xem nếu điều đó làm cho chúng tôi một số bị hỏng.

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>

Vâng, vâng, nó hos khi thiết lập như thế này. Nhưng, chúng ta có thể phục hồi?

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

Thành công, một lần nữa!

Bài kiểm tra 3

Đây là cái mà tôi nghĩ sẽ giết dữ liệu chắc chắn - hãy thực hiện một thuật toán bố cục khác!

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).

Đáng sợ và tồi tệ - nó nghĩ rằng nó đã tìm thấy một cái gì đó và muốn làm một số sửa chữa! Ctrl+ C!

Clear<y>? cancelled!

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

Ok, khủng hoảng đã biến mất. Hãy xem liệu dữ liệu có còn nguyên vẹn sau khi kết hợp lại với bố cục sai không:

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

Sự thành công!

Kiểm tra 4

Chúng ta cũng hãy chứng minh rằng superblock zeroing không gây hại thực sự nhanh chóng:

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

Vâng, không có vấn đề lớn.

Kiểm tra 5

Chúng ta hãy ném mọi thứ chúng ta có vào nó. Tất cả 4 bài kiểm tra trước đó, kết hợp.

  • Đặt hàng thiết bị sai
  • Kích thước chunk sai
  • Thuật toán bố trí sai
  • Superblocks không (chúng tôi sẽ làm điều này giữa cả hai sáng tạo)

Trở đi

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

Lời phán quyết?

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

Vì vậy, có vẻ như không có hành động nào trong số những hành động này làm hỏng dữ liệu theo bất kỳ cách nào. Tôi đã khá ngạc nhiên với kết quả này, thẳng thắn; Tôi dự kiến ​​tỷ lệ mất dữ liệu vừa phải khi thay đổi kích thước khối và một số mất mát nhất định về thay đổi bố cục. Tôi đã học được một cái gì đó ngày hôm nay.


Vậy .. làm thế nào để tôi có được dữ liệu của mình ??

Nhiều thông tin như bạn có về hệ thống cũ sẽ cực kỳ hữu ích cho bạn. Nếu bạn biết loại hệ thống tập tin, nếu bạn có bất kỳ bản sao cũ nào của bạn /proc/mdstatvới thông tin về thứ tự ổ đĩa, thuật toán, kích thước khối và phiên bản siêu dữ liệu. Bạn có thiết lập cảnh báo email của mdadm không? Nếu vậy, tìm một cái cũ; nếu không, kiểm tra /var/spool/mail/root. Kiểm tra ~/.bash_historyxem nếu bản dựng ban đầu của bạn ở trong đó.

Vì vậy, danh sách những điều bạn nên làm:

  1. Sao lưu các đĩa với ddtrước khi làm bất cứ điều gì !!
  2. Hãy thử với fsckmd hiện tại, hoạt động - bạn có thể đã tình cờ xây dựng theo thứ tự như trước đây. Nếu bạn biết loại hệ thống tập tin, điều đó hữu ích; sử dụng fsckcông cụ cụ thể đó . Nếu bất kỳ công cụ nào đề nghị sửa bất cứ điều gì, đừng để chúng trừ khi bạn chắc chắn rằng chúng thực sự đã tìm thấy hệ thống tập tin hợp lệ! Nếu một fsckđề nghị sửa chữa một cái gì đó cho bạn, đừng ngần ngại để lại một bình luận để hỏi liệu nó thực sự có ích hay chỉ sắp sửa dữ liệu.
  3. Hãy thử xây dựng các mảng với các tham số khác nhau. Nếu bạn có một cái cũ /proc/mdstat, thì bạn có thể bắt chước những gì nó thể hiện; nếu không, thì bạn đang ở trong bóng tối - thử tất cả các đơn đặt hàng ổ đĩa khác nhau là hợp lý, nhưng kiểm tra mọi kích thước khối có thể với mỗi đơn hàng có thể là vô ích. Đối với mỗi, fscknó để xem nếu bạn nhận được bất cứ điều gì hứa hẹn.

Vì vậy, đó là. Xin lỗi cho cuốn tiểu thuyết, hãy để lại nhận xét nếu bạn có bất kỳ câu hỏi nào, và chúc may mắn!

chú thích: dưới 22 nghìn ký tự; 8k + ngại giới hạn chiều dài


8
Đó là một câu trả lời tuyệt vời.
Antoine Benkemoun

3
Tôi thậm chí không biết phải nói gì ... BRAVO !!! Thanh danh cho Shane Madden. Tôi sẽ sao lưu các đĩa và bắt đầu với các đề xuất của bạn. Cảm ơn, không thực sự là một lời cảm ơn lớn !!!
Chuẩn tướng

3
Tôi chỉ ... wow. Rực rỡ trả lời. Tôi nghĩ rằng câu trả lời duy nhất để phá vỡ giới hạn 30.000 ký tự là bài tiểu luận "Làm thế nào để thay thế công việc" của Evan Andersons.
Tombull89

3
Câu trả lời hay nhất về SF từ trước đến nay.
Chopper3

14
Bạn, thưa ông, giành được internet.
Mark Henderson

5

Nếu bạn may mắn, bạn có thể có một số thành công với việc lấy lại các tệp của mình bằng phần mềm khôi phục có thể đọc được một mảng RAID-5 bị hỏng. Phục hồi giả định bằng không là một trong những điều tôi đã thành công trước đó.

Tuy nhiên, tôi không chắc liệu quá trình tạo một mảng mới có biến mất và phá hủy tất cả dữ liệu hay không, vì vậy đây có thể là nỗ lực cơ hội cuối cùng.


Cảm ơn Mark rất nhiều. Tôi sẽ cho nó nó một cơ hội. Bạn có biết nếu nó sửa đổi các ổ đĩa? Nếu vậy tôi sẽ tạo một bản sao đĩa và cũng thử với các công cụ khác.
Chuẩn tướng

@Brigadieren - không, xin lỗi, tôi không đủ quen thuộc với những rắc rối về cách thức hoạt động của RAID5.
Mark Henderson

@Brigadieren Theo tài liệu của mdadm , quá trình tạo sẽ không hủy dữ liệu, chỉ đồng bộ lại - nhưng nếu nó chọn hình học không khớp với bản gốc của bạn, thì nó có thể đã phá hủy dữ liệu bằng cách viết chẵn lẻ mới. Nếu sau này tôi có thời gian rảnh tôi có thể thấy về việc tạo lại tình huống của bạn trong VM, để xem liệu tôi có thể thêm bất kỳ thông tin chi tiết nào không. Tôi khuyên bạn nên lấy các bản sao đầy đủ của các ổ đĩa trước khi thử bất kỳ bước khôi phục nào ghi vào các ổ đĩa - bạn có thể muốn xem xét thêm các ổ đĩa để tạo các bản sao.
Shane Madden

Tôi chỉ không chắc chắn điều gì đã gây ra sự đồng bộ - thực tế là mảng đã bị xuống cấp ngay từ đầu (do mất điện) hoặc điều gì khác? Tôi tự hỏi nếu mdadm --create có phân biệt liệu tôi có chỉ định thứ tự ổ đĩa khác với ban đầu không?
Chuẩn tướng

@Brigadieren Sync luôn xảy ra khi tạo.
Shane Madden

5

Tôi đã gặp một vấn đề tương tự:
sau sự cố của mảng RAID5 phần mềm, tôi đã bắn mdadm --createmà không cho nó --assume-cleanvà không thể gắn kết mảng đó nữa. Sau hai tuần đào cuối cùng tôi đã khôi phục lại tất cả dữ liệu. Tôi hy vọng thủ tục dưới đây sẽ tiết kiệm thời gian của ai đó.

Mẩu chuyện dài

Vấn đề được gây ra bởi thực tế là mdadm --createtạo ra một mảng mới khác với bản gốc ở hai khía cạnh:

  • thứ tự khác nhau của phân vùng
  • bù dữ liệu RAID khác nhau

Như đã được Shane Madden thể hiện trong câu trả lời xuất sắc , mdadm --createkhông phá hủy dữ liệu trong hầu hết các trường hợp! Sau khi tìm thấy thứ tự phân vùng và dữ liệu bù, tôi có thể khôi phục mảng và trích xuất tất cả dữ liệu từ nó.

Điều kiện tiên quyết

Tôi không có bản sao lưu của các siêu khóa RAID, vì vậy tất cả những gì tôi biết là đó là một mảng RAID5 trên 8 phân vùng được tạo trong quá trình cài đặt Xubfox 12.04.0. Nó có một hệ thống tập tin ext4. Một kiến ​​thức quan trọng khác là một bản sao của một tệp cũng được lưu trữ trên mảng RAID.

Công cụ

CD trực tiếp Xubfox 12.04.1 đã được sử dụng để thực hiện tất cả công việc. Tùy thuộc vào tình huống của bạn, bạn có thể cần một số công cụ sau:

phiên bản của mdadm cho phép chỉ định bù dữ liệu

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

bgrep - tìm kiếm dữ liệu nhị phân

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

hexdump, e2fsck, mount và máy tính thập lục phân - các công cụ tiêu chuẩn từ repos

Bắt đầu với Sao lưu đầy đủ

Việc đặt tên tệp thiết bị, /dev/sda2 /dev/sdb2v.v., không liên tục, vì vậy tốt hơn là ghi lại số sê-ri của ổ đĩa của bạn được cung cấp bởi

sudo hdparm -I /dev/sda

Sau đó kết nối một ổ cứng gắn ngoài và sao lưu mọi phân vùng của mảng RAID của bạn như thế này:

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

Xác định bố cục RAID5 gốc

Các cách bố trí khác nhau được mô tả ở đây: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Để tìm cách sắp xếp các dải dữ liệu trên mảng ban đầu, bạn cần một bản sao của tệp trông ngẫu nhiên mà bạn biết là lưu trữ trên mảng. Kích thước khối mặc định hiện đang được sử dụng mdadmlà 512KB. Đối với một mảng các phân vùng N, bạn cần một tệp có kích thước tối thiểu (N + 1) * 512KB. Một jpeg hoặc video là tốt vì nó cung cấp các chuỗi dữ liệu nhị phân tương đối độc đáo. Giả sử tập tin của chúng tôi được gọi picture.jpg. Chúng tôi đọc 32 byte dữ liệu tại các vị trí N + 1 bắt đầu từ 100k và tăng thêm 512k:

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
...

Sau đó, chúng tôi tìm kiếm sự xuất hiện của tất cả các chuỗi phụ này trên tất cả các phân vùng thô của chúng tôi, do đó, trong tổng số (N + 1) * N lệnh, như thế này:

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
...

Các lệnh này có thể được chạy song song cho các đĩa khác nhau. Quét phân vùng 38GB mất khoảng 12 phút. Trong trường hợp của tôi, mỗi chuỗi 32 byte chỉ được tìm thấy một lần trong số tất cả tám ổ đĩa. Bằng cách so sánh các offset được trả về bởi bgrep, bạn sẽ có được một hình ảnh như thế này:

| 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 |

Chúng tôi thấy một bố cục đối xứng trái bình thường , được mặc định cho mdadm. Quan trọng hơn, bây giờ chúng ta biết thứ tự của các phân vùng. Tuy nhiên, chúng tôi không biết phân vùng nào là đầu tiên trong mảng, vì chúng có thể được dịch chuyển theo chu kỳ.

Cũng lưu ý khoảng cách giữa các độ lệch tìm thấy. Trong trường hợp của tôi, nó là 512KB. Kích thước chunk thực sự có thể nhỏ hơn khoảng cách này, trong trường hợp đó bố cục thực tế sẽ khác nhau.

Tìm kích thước chunk gốc

Chúng tôi sử dụng cùng một tệp picture.jpgđể đọc 32 byte dữ liệu theo các khoảng thời gian khác nhau. Chúng tôi biết từ phía trên rằng dữ liệu ở mức bù 100k đang nằm /dev/sdh2, ở mức bù 612k là tại /dev/sdb2và ở mức 1124k là tại /dev/sdd2. Điều này cho thấy kích thước khối không lớn hơn 512KB. Chúng tôi xác minh rằng nó không nhỏ hơn 512KB. Đối với điều này, chúng tôi kết xuất bytestring ở offset 356k và xem phân vùng nằm ở đâu:

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

Nó nằm trên cùng phân vùng với offset 612k, cho biết kích thước khối không phải là 256KB. Chúng tôi loại bỏ kích thước chunk nhỏ hơn trong thời trang tương tự. Tôi đã kết thúc với khối 512KB là khả năng duy nhất.

Tìm phân vùng đầu tiên trong bố cục

Bây giờ chúng ta đã biết thứ tự của các phân vùng, nhưng chúng ta không biết phân vùng nào sẽ là phân vùng đầu tiên và phần bù dữ liệu RAID nào được sử dụng. Để tìm ra hai ẩn số này, chúng tôi sẽ tạo một mảng RAID5 với bố cục chính xác và bù dữ liệu nhỏ và tìm kiếm sự khởi đầu của hệ thống tệp của chúng tôi trong mảng mới này.

Để bắt đầu, chúng tôi tạo một mảng với thứ tự đúng của các phân vùng, mà chúng tôi đã tìm thấy trước đó:

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

Chúng tôi xác minh rằng đơn đặt hàng được tuân theo bằng cách ban hành

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

Bây giờ chúng tôi xác định độ lệch của N + 1 bytestrings được biết trong mảng RAID. Tôi chạy một kịch bản cho một đêm (Live CD không yêu cầu mật khẩu trên 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

Đầu ra với ý kiến:

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

Dựa trên dữ liệu này, chúng tôi thấy rằng chuỗi thứ 3 không được tìm thấy. Điều này có nghĩa là chunk tại /dev/sdd2được sử dụng cho tương đương. Dưới đây là một minh họa về các vị trí chẵn lẻ trong mảng mới:

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

Mục đích của chúng tôi là suy ra phân vùng nào để bắt đầu mảng từ đó, để chuyển các khối chẵn lẻ vào đúng vị trí. Vì chẵn lẻ nên được dịch chuyển hai khối sang trái, trình tự phân vùng nên được dịch chuyển hai bước sang phải. Do đó, bố cục chính xác cho phần bù dữ liệu này là 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 

Tại thời điểm này, mảng RAID của chúng tôi chứa dữ liệu ở dạng bên phải. Bạn có thể may mắn vì phần bù dữ liệu RAID giống như trong mảng ban đầu, và sau đó rất có thể bạn sẽ có thể gắn kết phân vùng. Thật không may, đây không phải là trường hợp của tôi.

Xác minh tính nhất quán của dữ liệu

Chúng tôi xác minh rằng dữ liệu phù hợp với một dải các đoạn bằng cách trích xuất một bản sao picture.jpgtừ mảng. Đối với điều này, chúng tôi xác định vị trí bù cho chuỗi 32 byte ở mức 100k:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Sau đó, chúng tôi trừ 100 * 1024 từ kết quả và sử dụng giá trị thập phân thu được trong skip=tham số cho dd. Các count=là kích thước của picture.jpgtính theo byte:

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

Kiểm tra extract.jpggiống nhưpicture.jpg .

Tìm dữ liệu RAID

Một sidenote: bù dữ liệu mặc định cho mdadmphiên bản 3.2.3 là 2048 cung. Nhưng giá trị này đã được thay đổi theo thời gian. Nếu mảng ban đầu sử dụng bù dữ liệu nhỏ hơn hiện tại của bạn mdadm, thì mdadm --createkhông có--assume-clean có thể ghi đè lên phần đầu của hệ thống tệp.

Trong phần trước chúng ta đã tạo một mảng RAID. Xác minh dữ liệu RAID nào đã bù bằng cách phát hành cho một số phân vùng riêng lẻ:

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

2048 cung 512 byte là 1MB. Vì kích thước khối là 512KB, bù dữ liệu hiện tại là hai khối.

Nếu tại thời điểm này bạn có phần bù hai phần, nó có thể đủ nhỏ và bạn có thể bỏ qua đoạn này.
Chúng tôi tạo một mảng RAID5 với độ lệch dữ liệu của một đoạn 512KB. Bắt đầu một đoạn trước đó sẽ chuyển một bước chẵn lẻ sang trái, do đó chúng ta bù lại bằng cách dịch chuyển chuỗi phân vùng một bước sang trái. Do đó đối với dữ liệu bù 512KB, bố cục chính xác là hbdcefga. Chúng tôi sử dụng phiên bản mdadmhỗ trợ bù dữ liệu (xem phần Công cụ). Nó bù đắp bằng kilobyte:

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

Bây giờ chúng tôi tìm kiếm một siêu khối ext4 hợp lệ. Cấu trúc siêu khối có thể được tìm thấy ở đây: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Chúng tôi quét phần đầu của mảng để tìm các số ma thuật s_magictheo sau s_states_errors. Các bytestrings để tìm là:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Lệnh ví dụ:

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

Số ma thuật bắt đầu 0x38 byte vào siêu khối, vì vậy chúng tôi trừ 0x38 để tính toán bù và kiểm tra toàn bộ siêu khối:

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                              

Đây dường như là một siêu khối hợp lệ. s_log_block_sizetrường tại 0x18 là 0002, có nghĩa là kích thước khối là 2 ^ (10 + 2) = 4096 byte.s_blocks_count_lotại 0x4 là 03f81480 khối là 254GB. Có vẻ tốt.

Bây giờ chúng tôi quét các lần xuất hiện của các byte đầu tiên của siêu khối để tìm các bản sao của nó. Lưu ý lật byte so với đầu ra hexdump:

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

Điều này phù hợp hoàn hảo với các vị trí dự kiến ​​của các siêu khóa dự phòng:

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

Do đó, hệ thống tệp bắt đầu ở phần bù 0xdc80000, tức là 225792KB từ phân vùng bắt đầu. Vì chúng tôi có 8 phân vùng, trong đó một phân vùng là chẵn lẻ, chúng tôi chia phần bù cho 7. Điều này mang lại cho 33049544 byte bù trên mỗi phân vùng, chính xác là 63 khối RAID. Và vì phần bù dữ liệu RAID hiện tại là một phần, chúng tôi kết luận rằng phần bù dữ liệu ban đầu là 64 phần, hoặc 32768KB. Dịch chuyển hbdcefga63 lần sang phải cho bố cục bdcefgah.

Cuối cùng chúng tôi cũng xây dựng được mảng RAID chính xác:

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

Võngà!


Hướng dẫn tuyệt vời. Một lưu ý - 53EF00000100 dường như không phải là mỏ neo hợp lệ cho tiêu đề EXT4. Theo ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block hai byte sau 53EF có thể chỉ là 0100, 0200 hoặc 0400.
matt

0

Tôi đã có một vấn đề tương tự. Tôi đã định dạng và cài đặt lại hệ điều hành / ổ đĩa khởi động của mình với bản cài đặt sạch Ubuntu 12.04, sau đó chạy lệnh mdadm --create ... và không thể cài đặt nó.

Nó nói rằng nó không có một siêu khối hoặc phân vùng hợp lệ.

Hơn nữa, khi tôi dừng cuộc đột kích mdadm, tôi không còn có thể gắn thiết bị thông thường nữa.

Tôi đã có thể sửa chữa siêu khối bằng mke2fs và 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

Rồi chạy:

e2fsck -b 32768 -y /dev/sdc1

Điều đó đã khôi phục siêu khối để tôi có thể gắn và đọc ổ đĩa.

Để làm cho mảng hoạt động mà không phá hủy siêu khối hoặc phân vùng tôi đã sử dụng bản dựng:

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

Sau khi xác minh dữ liệu, tôi sẽ thêm ổ đĩa khác:

mdadm --add /dev/md0 /sdd1

0

Tôi chỉ cập nhật một số thông tin được đưa ra trước đó. Tôi đã có một mảng raid5 3 đĩa hoạt động tốt khi bo mạch chủ của tôi chết. Mảng được giữ / dev / md2 là phân vùng / home 1.2TB và / dev / md3 là phân vùng / var 300GB.

Tôi đã có hai bản sao lưu của những thứ "quan trọng" và một loạt những thứ ngẫu nhiên tôi đã lấy từ nhiều nơi khác nhau trên internet mà tôi thực sự nên trải qua và bỏ đi một cách có chọn lọc. Hầu hết các bản sao lưu được chia thành các tệp .tar.gz từ 25 GB trở xuống và một bản sao / etc riêng biệt cũng được sao lưu.

Phần còn lại của hệ thống tập tin được giữ trên hai đĩa raid0 nhỏ 38GB.

Máy mới của tôi tương tự như phần cứng cũ và tôi đã khởi động máy một cách đơn giản bằng cách cắm tất cả năm đĩa vào và chọn một kernel chung cũ. Vì vậy, tôi đã có năm đĩa với hệ thống tệp sạch, mặc dù tôi không thể chắc chắn rằng các đĩa đó có đúng thứ tự và cần cài đặt phiên bản Debian Jessie mới để đảm bảo rằng tôi có thể nâng cấp máy khi cần và sắp xếp khác các vấn đề.

Với hệ thống chung mới được cài đặt trên hai đĩa Raid0, tôi bắt đầu đặt các mảng lại với nhau. Tôi muốn chắc chắn rằng tôi đã có các đĩa theo đúng thứ tự. Những gì tôi nên làm là phát hành:

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

Nhưng tôi đã không làm thế. Có vẻ như mdadm khá thông minh và được cung cấp một uuid, có thể tìm ra ổ đĩa đi đâu. Ngay cả khi bios chỉ định / dev / sdc là / sda, mdadm sẽ kết hợp nó một cách chính xác (mặc dù YMMV).

Thay vào đó tôi đã ban hành: mdadm --create /dev/md2 without the --assume-clean , và cho phép đồng bộ lại trên / dev / sde1 để hoàn thành. Lỗi tiếp theo tôi mắc phải là làm việc trên / dev / sdc1 thay vì ổ đĩa cuối cùng trong / dev / md2, / sde1. Bất cứ lúc nào mdadm nghĩ rằng có một vấn đề, đó là ổ đĩa cuối cùng bị loại bỏ hoặc đồng bộ hóa lại.

Sau đó, mdadm không thể tìm thấy bất kỳ siêu khối nào và e2fsck -n cũng không thể.

Sau khi tôi tìm thấy trang này, tôi đã làm thủ tục cố gắng tìm chuỗi cho các ổ đĩa (đã hoàn thành), kiểm tra dữ liệu hợp lệ (đã xác minh 6MB tệp 9 MB), lấy các đĩa theo đúng trình tự, cde, lấy các uuid của / md2 và / md3 từ /etc/mdadm.conf cũ và đã thử lắp ráp.

Vâng, đã /dev/md3bắt đầu và mdadm --misc -D /dev/md3hiển thị ba phân vùng khỏe mạnh và các đĩa theo đúng thứ tự. /dev/md2cũng có vẻ tốt, cho đến khi tôi cố gắng gắn kết hệ thống tập tin.

# 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.

Hệ thống tập tin từ chối được gắn kết và e2fsck không thể tìm thấy bất kỳ siêu khóa nào. Hơn nữa, khi kiểm tra các siêu khóa như mô tả ở trên, tổng số khối được tìm thấy là a880 0076 hoặc a880 0076 hoặc 5500 1176 không khớp với kích thước dung lượng ổ đĩa 1199,79 đã báo cáo mdadm của tôi. Ngoài ra, không có vị trí nào của "siêu khóa" được căn chỉnh với dữ liệu trong các bài viết ở trên.

Tôi đã sao lưu tất cả / var và chuẩn bị xóa sạch các đĩa. Để xem liệu có thể xóa chỉ / md2 không, (tôi không có gì khác để mất vào thời điểm này) Tôi bỏ qua những điều sau:

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

Tất cả có vẻ ổn, ngoại trừ việc thay đổi uuid. Vì vậy, sau một vài lần kiểm tra, tôi đã viết 600GB dữ liệu được sao lưu vào / dev / md2. Sau đó, ngắt kết nối và cố gắng gắn lại ổ đĩa:

# 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

Có phải bạn đang đùa tôi không? 600 GB của tôi trong tập tin thì sao?

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

Ah - dễ dàng sửa chữa. không ghi chú một dòng trong /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

Yippie!

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.