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
그렇다면 이 슈퍼블록을 다른 2개의 장치에 복사하여 어레이를 "제대로" 시작할 수 있는 방법이 있습니까?
답변1
저도 비슷한 설정을 갖고 있으며 각 드라이브의 작은 파티션에 완전한 Linux를 설치하는 것을 권장할 수 있습니다.~ 아니다이러한 작은 파티션을 미러링하되 별도로 완전히 부팅할 수 있도록 하십시오.
몇 가지 중요한 파일( , grub 구성) sync을 제외하고 설정할 수 있습니다 . /etc/fstab이는 단순한 것보다 더 많은 공간을 차지 /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.
-B, --build Build a legacy array without superblocks
UPD-B.: RAID-5 구축을 거부한 것으로 밝혀졌습니다 ... :-/