3개의 SATA 하드 드라이브가 있는 서버가 있습니다. 각 파티션에는 2개의 파티션이 있습니다. 작은 부분은 raid1 배열(/boot)인 /dev/md0의 일부이고 나머지는 lvm 물리 볼륨인 raid5 배열(/dev/md1)의 일부입니다. 그 안에는 3개의 (IIRC) 논리 볼륨이 있습니다. 그 중 하나는 약 100GB의 데이터를 저장할 수 있는 reiserfs 3.6 fs입니다.
어제 서버가 다운됐어요. 시작 시 SMART는 드라이브 중 하나가 손상되었다는 메시지를 표시합니다. 그는 정말 불쾌한 소리를 냈습니다. 그래서 고장난 드라이브를 제거하고 나머지 2개의 디스크에서 시스템을 다시 시작해 보았습니다. 실패했습니다.
라이브 CD를 사용하여 부팅하고 어레이를 재부팅해 보았습니다. 불행하게도 mdadm은 남은 디스크 2개 중 하나에도 오류가 발생했다고 생각하기 때문에 이 작업을 거부합니다.
그러므로 다음에 나오는 조언을 따르십시오.손상된 Linux md RAID5 어레이를 복구하는 방법은 무엇입니까?제 경우에는 효과가 있을 것 같습니다. 아마도 어리석은 짓을 했을 것입니다.
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sd[ab]2 missing
이제 실제로 어레이를 부팅할 수 있지만 lvm 도구(vgscan, vgdisplay, pvck)는 어레이에서 lvm과 관련된 어떤 것도 찾을 수 없으며 데이터를 전혀 가져올 수 없습니다. 방금 모든 lvm 메타데이터를 지웠나요?
제 느낌에는 실제 데이터가 손상되지 않고 그대로 남아 있다는 것입니다(lvm 메타데이터 제외). 데이터를 다시 가져올 가능성이 있나요? 어떻게?
고쳐 쓰다:
psusi의 조언(아래)에 따라 배열을 다시 생성하는 다음 방법을 각각 시도했습니다.
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sdb2 /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sdb2 /dev/sda2
이는 -c64 및 -c512를 포함하여 기본적으로 가능한 모든 명령입니다. 모든 테스트 후에는 vgscan을 실행합니다. 아무도 아무것도 발견하지 못했습니다. 어쩌면 vgscan을 사용하지 말고 다른 도구를 사용해야 할까요?
업데이트 2:
고장난 하드 드라이브를 다시 연결해 보았습니다. 기적적으로 효과가 있는 것 같습니다. 적어도 그것을 확인하기에 충분합니다.
root@debian:~# mdadm --examine /dev/sda2
/dev/sda2:
Magic : a92b4efc
Version : 0.90.00
UUID : 1f5462ab:6945560d:019b01a5:914dd464
Creation Time : Fri Oct 17 12:40:40 2008
Raid Level : raid5
Used Dev Size : 160015360 (152.60 GiB 163.86 GB)
Array Size : 320030720 (305.21 GiB 327.71 GB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 1
Update Time : Tue Apr 12 08:15:03 2011
State : active
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Checksum : 64d514fb - correct
Events : 137
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 0 8 2 0 active sync /dev/sda2
0 0 8 2 0 active sync /dev/sda2
1 1 8 18 1 active sync /dev/sdb2
2 2 8 34 2 active sync /dev/sdc2
그렇다면 어레이를 "제대로" 부팅할 수 있도록 이 슈퍼블록을 다른 두 장치에 복사할 수 있는 방법이 있습니까?
답변1
저도 비슷한 설정을 갖고 있으며 드라이브당 작은 파티션에 전체 Linux를 설치하는 것을 제안할 수 있습니다.아니요이러한 작은 파티션을 미러링하되 개별적으로 완전히 부팅 가능하게 만드세요.
sync설치 중에 일부 중요한 파일( /etc/fstab, grub 구성) 을 제외 할 수 있습니다 . 이렇게 하면 더 많은 공간이 필요할 뿐만 아니라 /boot문제가 발생할 때 많은 시간을 절약할 수 있습니다.
답변2
이전과 같은 순서로 드라이브를 조립하지 않았을 수도 있고, 이전과 같은 블록 크기를 사용하지 않았을 수도 있습니다. 이전 순서가 무엇인지 파악하고 배열을 다시 만들 때 동일한 순서를 사용해야 합니다. 즉, 세 번째 디스크가 죽은 것이 아니라 첫 번째 또는 두 번째 디스크가 sda와 sdb를 혼동했을 수도 있습니다.
답변3
처럼 @푸수시 힌트메타데이터 형식은 kye이며 다음과 같습니다. 이제 "0.9" 대신 "1.2"가 기본값입니다. 불행하게도 1.2에서는 4KiB 오프셋을 사용하므로 데이터 손실이 발생할 수 있습니다.
1, 1.0, 1.1 및 1.2는 기본적으로 새로운 버전-1 형식 슈퍼블록을 사용합니다. 이는 덜 제한적입니다. 엔디안이 다른 호스트 간에 쉽게 이동할 수 있으며 복구 작업을 검사하고 다시 시작할 수 있습니다. 다양한 하위 버전은 장치의 끝 부분(1.0의 경우), 시작 부분(1.1의 경우) 또는 처음부터 4K(1.2의 경우) 등 장치의 서로 다른 위치에 슈퍼블록을 저장합니다.
한 가지 조언(늦었지만): -B-build를 사용하지 않고 배열을 다시 생성하려고 서두르지 마십시오.
-B, --build Build a legacy array without superblocks
UPD.: 결과는 -BRAID-5 구축을 거부합니다...:-/