mdadm raid5 phục hồi lỗi đĩa đôi - với một twist (thứ tự ổ đĩa)


14

Trước tiên, hãy để tôi thừa nhận rằng tôi đã mắc lỗi và tôi có một bản sao lưu cho hầu hết nhưng không phải tất cả dữ liệu trên RAID này. Tôi vẫn có hy vọng khôi phục phần còn lại của dữ liệu. Tôi không có tiền để mang các ổ đĩa đến một công ty chuyên gia phục hồi.

Sai lầm # 0, không có bản sao lưu 100%. Tôi biết.

Tôi có mdadmhệ thống RAID5 4x3TB. Ổ đĩa / dev / sd [be], tất cả chỉ có một phân vùng /dev/sd[b-e]1. Tôi biết rằng RAID5 trên các ổ đĩa rất lớn là rủi ro, nhưng dù sao tôi cũng đã làm được.

Sự kiện gần đây

RAID trở nên xuống cấp sau một lỗi hai ổ đĩa. Một ổ [/ dev / sdc] đã thực sự biến mất, [/ dev / sde] khác đã hoạt động trở lại sau một chu kỳ nguồn, nhưng không được tự động thêm lại vào RAID. Vì vậy, tôi chỉ còn lại một RAID 4 thiết bị chỉ có 2 ổ đĩa hoạt động [/ dev / sdb và / dev / sdd].

Sai lầm # 1, không sử dụng bản sao dd của các ổ đĩa để khôi phục RAID. Tôi không có ổ đĩa hoặc thời gian. Sai lầm # 2, không tạo bản sao lưu của siêu khối và mdadm -Ecác ổ đĩa còn lại.

Cố gắng phục hồi

Tôi đã lắp lại RAID ở chế độ xuống cấp với

mdadm --assemble --force /dev/md0, using /dev/sd[bde]1.

Sau đó tôi có thể truy cập dữ liệu của mình. Tôi thay thế /dev/sdcbằng một phụ tùng; trống; ổ đĩa giống hệt nhau.

Tôi đã gỡ bỏ bản cũ /dev/sdc1khỏi RAID

mdadm --fail /dev/md0 /dev/sdc1

Sai lầm # 3, không làm điều này trước khi thay thế ổ đĩa

Sau đó tôi phân vùng cái mới /dev/sdcvà thêm nó vào RAID.

mdadm --add /dev/md0 /dev/sdc1

Sau đó nó bắt đầu khôi phục RAID. ETA 300 phút. Tôi đã làm theo quy trình thông qua /proc/mdstatđến 2% và sau đó đi làm việc khác.

Kiểm tra kết quả

Vài giờ (nhưng ít hơn 300 phút) sau, tôi đã kiểm tra quy trình. Nó đã dừng lại do lỗi đọc trên /dev/sde1.

Đây là nơi rắc rối thực sự bắt đầu

Sau đó tôi gỡ bỏ /dev/sde1RAID và thêm lại. Tôi không thể nhớ tại sao tôi làm điều này; Muộn rồi.

mdadm --manage /dev/md0 --remove /dev/sde1
mdadm --manage /dev/md0 --add /dev/sde1

Tuy nhiên, /dev/sde1bây giờ đã được đánh dấu là phụ tùng. Vì vậy, tôi quyết định tạo lại toàn bộ mảng bằng cách sử dụng --assume-clean bằng cách sử dụng thứ tôi nghĩ là đúng thứ tự và /dev/sdc1bị thiếu.

mdadm --create /dev/md0 --assume-clean -l5 -n4 /dev/sdb1 missing /dev/sdd1 /dev/sde1

Điều đó đã làm việc, nhưng hệ thống tập tin đã không được nhận ra trong khi cố gắng gắn kết. (Đáng lẽ phải là EXT4).

Đặt hàng thiết bị

Sau đó tôi đã kiểm tra một bản sao lưu gần đây mà tôi có /proc/mdstatvà tôi đã tìm thấy thứ tự ổ đĩa.

md0 : active raid5 sdb1[0] sde1[4] sdd1[2] sdc1[1]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

Sau đó, tôi nhớ rằng RAID này đã bị mất ổ đĩa khoảng một năm trước và đã phục hồi từ nó bằng cách thay thế ổ đĩa bị lỗi bằng một ổ đĩa dự phòng. Điều đó có thể đã xáo trộn thứ tự thiết bị một chút ... vì vậy không có ổ đĩa [3] mà chỉ có [0], [1], [2] và [4].

Tôi đã cố gắng tìm thứ tự ổ đĩa với tập lệnh Permute_array: https://ston.wiki.kernel.org/index.php/Permute_array.pl nhưng không tìm thấy thứ tự đúng.

Câu hỏi

Bây giờ tôi có hai câu hỏi chính:

  1. Tôi đã vặn tất cả các siêu khóa trên các ổ đĩa, nhưng chỉ đưa ra:

    mdadm --create --assume-clean
    

    các lệnh (vì vậy tôi không nên ghi đè lên dữ liệu /dev/sd[bde]1. Tôi có đúng rằng về mặt lý thuyết , RAID có thể được khôi phục [giả sử trong giây lát /dev/sde1là ổn] nếu tôi chỉ tìm đúng thứ tự thiết bị?

  2. Điều quan trọng là /dev/sde1được cung cấp số thiết bị [4] trong RAID? Khi tôi tạo nó với

    mdadm --create /dev/md0 --assume-clean -l5 -n4 \
      /dev/sdb1 missing /dev/sdd1 /dev/sde1
    

    nó được gán số [3]. Tôi tự hỏi nếu điều đó có liên quan đến việc tính toán các khối chẵn lẻ. Nếu nó trở nên quan trọng, làm thế nào tôi có thể tạo lại mảng /dev/sdb1[0]bị thiếu [1] /dev/sdd1[2] /dev/sde1[4]? Nếu tôi có thể làm cho nó hoạt động, tôi có thể khởi động nó ở chế độ xuống cấp và thêm ổ đĩa mới /dev/sdc1và để nó đồng bộ lại.

Sẽ ổn thôi nếu bạn muốn chỉ ra cho tôi rằng đây có thể không phải là cách hành động tốt nhất, nhưng bạn sẽ thấy rằng tôi đã nhận ra điều này. Sẽ thật tuyệt nếu có ai có bất cứ lời đề nghị nào.


1
+1 Đây là một câu hỏi được suy nghĩ rất kỹ và được ghi lại. Tôi ước tôi có một câu trả lời cho bạn.
Cấp

Cảm ơn bạn đã bình luận của bạn, tôi đoán đây là một khó khăn.
Peter Bos

Bạn đã từ bỏ việc này, hay bạn vẫn đang làm việc với nó? Nếu bạn đang làm việc với nó, lời khuyên của tôi, hãy thu thập tất cả các ổ đĩa bạn đặt xung quanh và tạo JBOD trên một máy khác mà bạn có thể tạo hình ảnh DD, cách tốt hơn là xử lý theo cách đó vì bạn có thể tiếp tục thử lại . (Sử dụng LVM và sau đó sử dụng ảnh chụp nhanh sau khi kết thúc, vì vậy bạn có thể tiếp tục xóa ảnh chụp nhanh và không phải sao chép lại toàn bộ nội dung). Tôi đã ở trong một chiếc thuyền tương tự, và tôi đã tìm cách khôi phục mảng với hầu hết các dữ liệu còn nguyên vẹn.
Regan

Cảm ơn phản ứng của bạn. Sau một thời gian tôi đã từ bỏ việc này, thay thế hai ổ đĩa bằng ổ đĩa mới, phục hồi 98% từ bản sao lưu, chấp nhận mất 2% dữ liệu và tiếp tục. Tôi hiện đang sử dụng RAID-Z và đã cập nhật chiến lược sao lưu của mình. Càng xa càng tốt.
Peter Bos

Câu trả lời:


3

Để trả lời câu hỏi của bạn,

  1. Nó có thể được phục hồi?

    • Điều đầu tiên - DỪNG, ngồi lại và suy nghĩ một chút. Có, thuật toán, kích thước khối và thứ tự đĩa là rất quan trọng để có được bất kỳ hệ thống tập tin nào có mặt, để lắp ráp lại đúng cách. Nhưng vì bạn đã ghi đè lên các siêu khóa, giờ bạn đã gặp phải lỗi và thử.
    • Thứ hai, có cách nào bạn có thể lấy bố cục đĩa trước không? Tôi luôn luôn thực hiện một mdadm --detail> backupfile chỉ để giữ cho bố cục đĩa đó ở nơi an toàn. Kiểm tra dmesg, / var / log xem có bằng chứng nào về cách các đĩa được cấu hình trong cuộc đột kích không.
    • Cuối cùng, nếu bạn khớp với kích thước khối và thứ tự đĩa trước đó, bạn có thể đã làm hỏng siêu khối ext4 - có nhiều cách để quét các siêu khóa khác (và có một chương trình tiện lợi có tên là TestDisk quét các siêu khóa của các hệ thống tệp hiện có và cố gắng duyệt chúng theo cách thủ công: http://www.cgsecurity.org/wiki/Main_Page )
  2. Vì sdc là mới, tôi sẽ tiếp tục thử và lắp ráp thủ công thông qua mệnh đề còn thiếu và vâng, sde phải theo đúng thứ tự để nó lắp ráp ở chế độ xuống cấp. Khi bạn tìm thấy bố cục chính xác - sao chép tất cả dữ liệu khỏi mảng và bắt đầu lại, ghi lại bố cục (để bạn không gặp phải vấn đề này nữa).

Chúc may mắn


1
ext3 / 4 viết superblocks dự phòng. Bạn có thể chuyển bù siêu khối làm đối số để gắn kết hoặc fsck để sử dụng các siêu khóa sao lưu thay thế. Tuy nhiên, hai ổ đĩa trong RAID 5 = trò chơi kết thúc.
dmourati

1

Trước khi bạn thực hiện BẤT CỨ điều gì khác, hãy chụp 'mdadm --examine / dev / sdX1' cho mỗi ổ đĩa có trong mảng của bạn và 'mdadm --detail / dev / md0' từ đó, bạn sẽ có thể xác định cách bố trí chính xác.

Tôi chỉ phải tự làm điều này để khôi phục một mảng Synology trong một câu hỏi riêng biệt:

Làm cách nào để khôi phục một mảng mdadm trên Synology NAS với ổ đĩa ở trạng thái "E"?

Chỉnh sửa: Xin lỗi, chỉ cần thấy rằng bạn nói bạn đã mất các siêu khóa trên tất cả các ổ đĩa.

Các lệnh sau của bạn XEM chính xác. Tùy chọn đơn giản nhất có thể là chạy các tạo với mỗi thứ tự có thể, và sau đó xem liệu bạn có thể gắn kết và truy cập hệ thống tệp trên chúng chỉ đọc.


1

Câu hỏi này đã cũ và tôi chắc chắn không ai có thể giúp bạn bây giờ, nhưng đối với những người khác đang đọc:

lỗi nguy hiểm nhất bạn mắc phải không phải là lỗi bạn đã đánh số, đó là chạy:

mdadm --create ...

trên các đĩa gốc, trước khi bạn chuẩn bị biết phải làm gì. Điều này đã ghi đè lên siêu dữ liệu, do đó bạn không có bản ghi thứ tự ổ đĩa, bù dữ liệu, kích thước khối, v.v.

Để phục hồi từ điều này, bạn cần ghi đè lên chúng một lần nữa với các giá trị chính xác. Cách dễ nhất để biết điều này là xem siêu dữ liệu, nhưng bạn đã phá hủy nó. Cách tiếp theo là đoán. Đoán các kết hợp khác nhau của một lệnh như thế này, với các giá trị khác nhau cho bất kỳ tùy chọn nào ngoại trừ những gì bạn biết (4 thiết bị, cấp 5) và thứ tự đĩa khác nhau:

mdadm --create /dev/md0 --assume-clean --metadata=1.2 --raid-devices=4 --level=5 --layout=... --chunk=512 --data-offset=128M /dev/sdb1 missing /dev/sdd1 /dev/sde1

Nhưng vì bạn KHÔNG biết kết quả chính xác, một lần nữa, bạn không nên chạy nó trên các đĩa cũ phá hủy chúng thêm nữa, gây ra lỗi tương tự. Thay vào đó, sử dụng lớp phủ; ví dụ quy trình này nên hoạt động để giữ an toàn cho bản gốc.

Khi bạn đã tìm thấy một số đối số tạo ra một mảng hoạt động mà bạn có thể fsck hoặc mount và xác minh (ví dụ: kiểm tra tổng kiểm tra của một tệp đủ lớn để vượt qua tất cả các thành viên đột kích như một iso mà bạn nên lưu trữ với tổng kiểm tra / pgp của nó chữ ký, hoặc giải nén -t hoặc gunzip -ta lưu trữ lớn)


Cảm ơn bạn. Trong khi đó, tôi đã chuyển sang sử dụng ZFS (RAIDZ2). Tuy nhiên, nó rất thú vị để đọc ghi chú của bạn. Bây giờ tôi nhận ra rằng lệnh tạo đã ghi đè lên siêu dữ liệu, trong khi tại thời điểm đó tôi cho rằng nó sẽ không. Ngoài ra, tôi không biết về các tập tin lớp phủ. Đó là thực sự gọn gàng! Cảm ơn!
Peter Bos
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.