Ok, đây là những gì tôi đã làm. Có thể nó sẽ giúp người tiếp theo.
Tìm kiếm sự thật
Đầu tiên, tôi gắn tất cả các đĩa vào HBA. GNU/Linux cố gắng lắp ráp
đột kích, nhưng thực sự đã tìm thấy (ít nhất) hai tập đột kích (và thêm một chút). Tôi
sau đó tạo bản sao lưu của 32 MB đầu tiên và 32 MB cuối cùng của mỗi đĩa, được lập chỉ mục bởi
WWID/WWN của họ.
Sau đó, tôi đã tải xuống thông số kỹ thuật SNIA DDF
(https://www.snia.org/tech_activities/standards/curr_standards/ddf)
bởi vì tôi biết rằng megaraid/dell (một phần) đã triển khai nó (ddf
ma thuật khối neo không phải là de11de11 tình cờ :), và sau đó đã viết rất
kịch bản xấu xí để giải mã dữ liệu và hiểu ý nghĩa của nó.
Điều này cho tôi thấy rằng trên thực tế, mảng được chia thành ba mảng khác nhau
cấu hình, một cái bao gồm một đĩa, một cái khác bao gồm cái đó
đĩa và 4 đĩa khác, và một đĩa khác chứa 2 đĩa còn lại.
Bản thân kịch bản không hữu ích lắm nếu không hiểu bạn đang làm gì, vì vậy tôi không đưa nó vào đây.
Cuối cùng, điều này cho phép tôi tìm ra đúng thứ tự ban đầu của
các đĩa. Gợi ý: sau khi tạo mảng, ghi lại thứ tự các WWN
(perccli /c0/s0 hiển thị tất cả | grep WWN) và kích thước dải, ít nhất.
Quá trình này cũng mang lại cho tôi phần bù bắt đầu (luôn bằng 0) và kích thước của
phân vùng (19531825152 sector).
Biến thể raid5 được sử dụng bởi H740P (và có thể là tất cả megaraid
bộ điều khiển) được gọi là đối xứng trái hoặc "RAID-5 Rotating Parity N với
Tiếp tục dữ liệu (PRL=05, RLQ=03)".
Lắp ráp lại các đĩa để kiểm tra
Sau đó, tôi đã thử lắp ráp lại cuộc đột kích bằng cách sử dụng mdadm --build. Thật không may, mdadm từ chối lắp ráp các mảng đột kích5 - bạn
có để ghi vào mảng và hủy dữ liệu :(
Như một giải pháp thay thế, để kiểm tra xem thứ tự có đúng không, tôi đã bắt đầu một kvm
trong chế độ chụp nhanh với một số hình ảnh khởi động GNU/Linux ngẫu nhiên như /dev/sda và các đĩa dưới dạng đĩa virtio:
exec kvmb -snapshot -m 16384 \
-drive file=linux.img,snapshot=off \
-drive file=/dev/sdm,if=virtio,snapshot=on \
-drive file=/dev/sdl,if=virtio,snapshot=on \
-drive file=/dev/sdk,if=virtio,snapshot=on \
-drive file=/dev/sdi,if=virtio,snapshot=on \
-drive file=/dev/sdg,if=virtio,snapshot=on \
-drive file=/dev/sdf,if=virtio,snapshot=on \
-drive file=/dev/sdh,if=virtio,snapshot=on
Điều này làm cho các đĩa xuất hiện theo thứ tự được chỉ định như /dev/vda, /dev/vdb v.v. và cho phép tôi thử nghiệm các tùy chọn khác nhau một cách dễ dàng. Lần thử đầu tiên bên trong VM đã thành công:
mdadm --create /dev/md0 -f \
--metadata 1.0 \
--raid-thiết bị 7 \
-z $((19531825152/2))K -c 256K \
-l đột kích5 -p ddf-N-tiếp tục \
--assume-clean -k resync \
/dev/vd?
Đối với raid5, kích thước phân vùng là không cần thiết - nếu lớn hơn, GPT của bạn
bảng phân vùng bị hỏng và bạn có thêm dữ liệu, nhưng phần còn lại của
đĩa vẫn có thể đọc được.
Tôi đã xác minh tính chính xác của dữ liệu bằng cách gắn phân vùng (sẽ
không ném lỗi, nhưng có thể thành công ngay cả khi thứ tự sai) và sử dụng
chà btrfs, kiểm tra tổng kiểm tra của siêu dữ liệu và khối dữ liệu, đây là thử nghiệm cuối cùng và là điểm cộng chính của btrfs.
Sau đó tôi chạy lại backzp.
Sau đó, tôi đã ghi lại WWN của tất cả các đĩa theo thứ tự, để tôi có thể tạo lại nó
với perccli. Tôi cũng đã sao lưu 1GB dữ liệu đầu tiên và cuối cùng của
chính âm lượng đó, trong trường hợp bộ điều khiển đột kích sẽ ghi đè lên những âm lượng đó.
Di chuyển âm lượng trở lại bộ điều khiển đột kích
Vì khoảng 14TB dữ liệu không được sao lưu (do dữ liệu có thể bị
lấy từ những nơi khác với một số nỗ lực và tôi đã quá thiếu kiên nhẫn để
đợi một bản sao), khôi phục hoàn toàn không phải là một tùy chọn mà tôi mong đợi
đến, vì vậy tôi đã cố gắng di chuyển mảng trở lại bộ điều khiển.
Nỗ lực đầu tiên của tôi là định dạng mảng dưới dạng vùng chứa DDF bằng lệnh đột kích5
âm lượng bên trong, sử dụng các tham số giống như bộ điều khiển sử dụng, nhưng thật không may, bộ điều khiển megaraid - trong khi sử dụng
Bản thân DDF - không hỗ trợ DDF "nước ngoài" để nhập và chỉ hiển thị các đĩa
là "tốt chưa được định cấu hình".
Sau đó, tôi đã cố gắng tạo lại mảng chỉ bằng cách thêm lại mảng đó, ví dụ:
perccli /c0 add vd r5 name=XXX drive=3,6,9,1,2,3,0 pdcache=off wb ra strip=256
Thực hiện điều này trên hệ thống đã khởi động với perccli đảm bảo rằng bộ điều khiển đột kích
sẽ thực hiện khởi tạo nền, không phá hoại và với RAID5,
thậm chí sẽ không hủy dữ liệu khi thứ tự đĩa hoặc kích thước dải bị sai, vì
miễn là bạn sử dụng chính xác tất cả các đĩa từ mảng ban đầu theo bất kỳ thứ tự nào, không bỏ sót một đĩa nào hoặc cho quá nhiều đĩa.
Đây là chỗ tôi đã thất bại - bằng cách nào đó, tôi đã hoàn toàn xáo trộn thứ tự các đĩa,
và cũng đã làm hỏng 1,5 MB đầu tiên của ổ đĩa. tôi hoàn toàn có
không biết đã xảy ra lỗi gì, nhưng tôi đã thử nhiều hoán vị và không thấy
dữ liệu chính xác, đến mức tôi nghĩ bộ điều khiển đột kích sẽ
bằng cách nào đó sắp xếp lại các đĩa của tôi (nhưng không phải, nó chính xác theo thứ tự như
quy định).
Tóm lại, tôi đã gắn lại các đĩa vào HBA và thử và
không hiểu được ý nghĩa của nó. Đây là nơi sao lưu ban đầu của tôi có ích:
mặc dù tôi đã đánh mất thứ tự các đĩa, nhưng tôi đã xem kỹ bản sao lưu và
hạ thấp thứ tự tiềm năng xuống hai hoán vị có thể chỉ bằng cách nhìn chằm chằm vào các kết xuất lục giác. Tạo mảng với mdadm và kiểm tra dữ liệu đã cho tôi thứ tự chính xác.
Sau đó, tôi lại ghi lại thứ tự của các WWN, đính kèm các đĩa vào
bộ điều khiển, đã khởi động và đã làm perccli/c0 thêm.... Sau đó tôi đã khôi phục lần đầu tiên
1,5 MB dung lượng (bao gồm phân vùng GPT và nhãn LVM và
một số dữ liệu rác cũ còn sót lại rất hữu ích trong quá trình đoán xem
thứ tự có thể là). Một mức độ tự tin nhất định trong việc có thể hoàn tác
sai lầm là hữu ích trong tình huống này.
Kết quả: mảng đã hoạt động trở lại, btrfs nhất quán và bộ điều khiển hiện đang khởi chạy nền, điều này làm cho toàn bộ hệ thống chậm lại trong vài ngày, nhưng cái giá phải trả không nhỏ.
Những điều đã học
Tôi học được rất nhiều!
Bộ điều khiển perc (và có thể là tất cả bộ điều khiển megaraid) không xử lý được
tốt với các sự cố đĩa nhanh và không liên tục thường xuyên - Tôi nghi ngờ việc các đĩa biến mất và quay trở lại nhanh chóng đã gây ra tình trạng chạy đua trong đó bộ điều khiển đang cố ghi cấu hình mới vào các đĩa và chỉ thành công một phần với một số đĩa, cuối cùng chia cuộc đột kích thành hai . Đây rõ ràng là một lỗi phần sụn. Nhưng sau đó, ai có thể mong đợi dây cáp điện bị lỗi ...
mdadm không hữu ích lắm trong việc hiểu hoặc hiển thị các tiêu đề DDF -
Tôi chỉ đơn giản là không thể hiểu được dữ liệu được hiển thị và khi tôi phát hiện ra
khi tự giải mã các tiêu đề, điều này là do rất nhiều thông tin được
mất tích từ --chi tiết và --nghiên cứu đầu ra.Nó cũng không hữu ích lắm trong việc thử nghiệm, vì nó từ chối thực hiện lắp ráp chỉ đọc không phá hủy.
bộ điều khiển perc/megaraid sử dụng định dạng SNIA DDF bên trong và đây là một
đặc điểm kỹ thuật có thể truy cập công khai, cực kỳ hữu ích, mặc dù cuối cùng tôi đã tìm ra thứ mình cần mà không cần thông tin này.
Có thể đoán đúng thứ tự của các dải đột kích chỉ từ dữ liệu
là rất hữu ích. Rác còn sót lại và dữ liệu khác có thể giúp ích cho việc này
cũng rất hữu ích. Tôi sẽ cân nhắc viết "đĩa 1", "đĩa 2", v.v. vào
các vùng "trống" trong tiêu đề ổ đĩa RAID của tôi kể từ giờ trở đi (có các đoạn dài 0 byte trong 2MB đầu tiên).
Rất dễ bị lừa - tên thiết bị, số thành viên đột kích, WWN,
số vị trí, v.v. tất cả đều khác nhau có thể có nghĩa là rất nhiều dữ liệu
quản lý, và WWN đã dài và đôi mắt già của tôi không còn tốt nữa. Thêm vào đó, tôi không có đầu óc tổ chức và quá tự tin :/
Tạo và xóa một mảng bằng đĩa có dữ liệu trên đó
sẽ không xóa dữ liệu, ít nhất là với RAID5 và sử dụng nền
khởi tạo. Khởi tạo tiền cảnh gần như chắc chắn sẽ bằng không
các đĩa. Điều đó có nghĩa là bạn có thể tạo và xóa mảng bao nhiêu
nhiều lần như bạn muốn mà không gặp rủi ro mất dữ liệu, với một ngoại lệ có thể xảy ra:
xóa một mảng đôi khi yêu cầu tùy chọn bắt buộc vì RAID
bộ điều khiển cho rằng nó "đang được sử dụng" do nhãn phân vùng hợp lệ. Và điều này có thể loại bỏ nhãn GPT - YMMV và đảm bảo bạn có bản sao lưu của
vài megabyte đầu tiên đề phòng.
Perc/megaraid không hiểu các thùng chứa DDF không phải của Dell/megaraid. Tại
ít nhất là tôi đã không tìm ra cách làm cho bộ điều khiển của mình chấp nhận DDF do mdadm tạo
hộp đựng. Việc có thể định dạng đĩa trong GNU/Linux và di chuyển chúng trở lại bộ điều khiển sẽ giúp ích rất nhiều và sẽ tránh được nhiều giờ đau buồn cho tôi.
Tóm lược
Tôi đã lấy lại mọi thứ mà không cần khôi phục từ bản sao lưu, với chi phí là một
thời gian khởi tạo nền chậm vài ngày.Tôi đã viết ra giải pháp của mình
ở trên, trong trường hợp một số trong đó có thể hữu ích cho những người khác trong
những tình huống tương tự.
