mdadm raid5는 이중 디스크 오류 복구-트위스트 (드라이브 순서)


14

먼저 실수를 저질렀으며이 RAID의 모든 데이터에 대한 백업은 하지는 않습니다 . 나는 여전히 나머지 데이터를 복구하기를 희망합니다. 복구 전문가 회사로 드라이브를 가져갈 돈이 없습니다.

100 % 백업이없는 실수 # 0. 알아.

mdadm4x3TB 의 RAID5 시스템이 있습니다. 하나의 파티션으로 / dev / sd [be]를 구동합니다 /dev/sd[b-e]1. 매우 큰 드라이브의 RAID5가 위험하다는 것을 알고 있지만 어쨌든 그렇게했습니다.

최근 이벤트

두 개의 드라이브 장애 후 RAID 성능이 저하됩니다. 하나의 드라이브 [/ dev / sdc]는 실제로 사라졌고 다른 [/ dev / sde]는 전원을 껐다 켠 후에 백업되었지만 RAID에 자동으로 다시 추가되지 않았습니다. 따라서 2 개의 활성 드라이브 [/ dev / sdb 및 / dev / sdd] 만있는 4 개의 장치 RAID가 남았습니다.

RAID 복원을 위해 드라이브의 dd 사본을 사용하지 않는 실수 # 1. 나는 드라이브 나 시간이 없었다. 실수 # 2, 수퍼 블록 및 mdadm -E나머지 드라이브의 백업을 만들지 않습니다 .

복구 시도

RAID를 성능 저하 모드로 재 조립했습니다.

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

그런 다음 내 데이터에 액세스 할 수 있습니다. 나는 /dev/sdc여분으로 교체 했다. 빈; 동일한 드라이브.

/dev/sdc1RAID 에서 오래된 것을 제거했습니다

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

실수 # 3, 드라이브 교체 하기 전에이 작업을 수행하지 않음

그런 다음 새 파티션을 분할 /dev/sdc하여 RAID에 추가했습니다.

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

그런 다음 RAID를 복원하기 시작했습니다. ETA 300 분 나는 과정 /proc/mdstat을 2 %로 진행 한 다음 다른 일을했습니다.

결과 확인

몇 시간 후 (300 분 미만) 프로세스를 확인했습니다. 의 읽기 오류로 인해 중지되었습니다 /dev/sde1.

문제가 실제로 시작되는 곳

그런 다음 /dev/sde1RAID에서 제거 했다가 다시 추가했습니다. 내가 왜 이런 짓을했는지 기억이 나지 않습니다. 늦었다.

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

그러나 /dev/sde1이제 여분으로 표시되었습니다. 그래서 올바른 순서라고 생각한 것을 사용하여 --assume-clean을 사용하여 전체 배열을 다시 작성하기로 결정했습니다 /dev/sdc1.

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

그것은 효과가 있었지만 마운트하려고 할 때 파일 시스템이 인식되지 않았습니다. (EXT4 여야합니다).

장치 순서

그런 다음 최근에 보유한 백업을 확인한 후 /proc/mdstat드라이브 순서를 찾았습니다.

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]

그런 다음이 RAID가 약 1 년 전에 드라이브 손실을 겪었다는 것을 기억하고 결함이있는 드라이브를 예비 드라이브로 교체하여 복구했습니다. 장치 순서가 약간 뒤섞 였을 수 있습니다. 따라서 드라이브 [3]은없고 [0], [1], [2] 및 [4] 만있었습니다.

Permute_array 스크립트로 드라이브 순서를 찾으려고했습니다 : https://raid.wiki.kernel.org/index.php/Permute_array.pl 그러나 올바른 순서를 찾지 못했습니다.

질문

이제 두 가지 주요 질문이 있습니다.

  1. 드라이브의 모든 수퍼 블록을 망 쳤지 만 다음과 같은 결과 만 얻었습니다.

    mdadm --create --assume-clean
    

    명령 (따라서 데이터 자체를 덮어 쓰면 안됩니다 /dev/sd[bde]1. 이론적으로/dev/sde1 올바른 장치 순서를 찾으면 RAID가 복원 될 수 있다는 것이 옳습니까?

  2. /dev/sde1RAID에서 장치 번호 [4]를받는 것이 중요 합니까? 내가 그것을 만들 때

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

    숫자 [3]이 할당됩니다. 그것이 패리티 블록의 계산과 관련이 있는지 궁금합니다. 중요한 것으로 판명되면 /dev/sdb1[0]missing [1]을 사용하여 배열을 어떻게 다시 만들 수 /dev/sdd1[2] /dev/sde1[4]있습니까? 작동시킬 수 있다면 성능 저하 모드에서 시작하여 새 드라이브를 추가하고 /dev/sdc1다시 동기화 할 수 있습니다.

이것이 최선의 행동 과정이 아니 었음을 나에게 지적하고 싶더라도 괜찮습니다. 그러나 이것을 깨달았습니다. 누군가 제안이 있으면 좋을 것입니다.


1
+1 이것은 매우 잘 생각되고 문서화 된 질문입니다. 나는 당신에게 대답을 바랍니다.
Grant

귀하의 의견에 감사드립니다, 이것은 힘든 것 같아요.
피터 보스

당신은 이것을 포기 했습니까, 아니면 여전히 노력하고 있습니까? 내 조언에 따라 작업하고 있다면, 주변에있는 모든 드라이브를 정리하고 DD 이미지를 만들 수있는 다른 컴퓨터에서 JBOD를 만드십시오. 계속 반복해서 시도 할 수 있기 때문에 그 방법으로 처리하는 것이 좋습니다 . (LVM을 사용한 다음 스냅 샷이 완료되면 스냅 샷을 사용하므로 스냅 샷을 계속 삭제하고 전체를 다시 복사 할 필요가 없습니다). 나는 비슷한 보트에 있었고 대부분의 데이터를 그대로 유지하면서 어레이를 복구했습니다.
Regan

당신의 반응에 감사드립니다. 잠시 후, 나는 이것을 포기하고 두 개의 드라이브를 새로운 드라이브로 교체하고 백업에서 98 %를 복구하고 2 %의 데이터 손실을 받아들이고 계속 진행했습니다. RAID-Z를 사용하고 있으며 백업 전략을 업데이트했습니다. 여태까지는 그런대로 잘됐다.
피터 보스

답변:


3

질문에 대답하기 위해

  1. 복원 할 수 있습니까?

    • 가장 먼저-중지하고, 앉아서 조금 생각하십시오. 그렇습니다. 알고리즘, 청크 크기 및 디스크 순서는 존재하는 모든 파일 시스템을 올바르게 재 조립하는 데 필수적입니다. 그러나 수퍼 블록을 덮어 쓰기 때문에 시행 착오가 끝났습니다.
    • 둘째, 이전 디스크 레이아웃을 검색 할 수있는 방법이 있습니까? 디스크 레이아웃을 안전한 곳에 유지하기 위해 항상 mdadm --detail> backupfile을 수행합니다. RAID가 디스크를 구성한 방법에 대한 증거는 dmesg, / var / log를 확인하십시오.
    • 마지막으로, 이전 청크 크기와 디스크 순서와 일치하는 경우 ext4 수퍼 블록을 손상했을 수 있습니다. 다른 수퍼 블록을 신속하게 스캔하는 방법이 있습니다 (기존 파일 시스템의 수퍼 블록을 검색하여 찾아 보려고 시도하는 TestDisk라는 멋진 프로그램이 있습니다) 수동 : http://www.cgsecurity.org/wiki/Main_Page )
  2. sdc가 새롭기 때문에 누락 된 절을 통해 계속 수동으로 시도하고 시도 할 것입니다. 그렇습니다 .sde가 성능 저하 모드에서 조립하려면 올바른 순서에 있어야합니다. 올바른 레이아웃을 찾으면 배열에서 모든 데이터를 복사하고 다시 시작하여 레이아웃을 문서화하십시오 (따라서이 문제가 다시 발생하지 않습니다).

행운을 빕니다


1
ext3 / 4는 중복 수퍼 블록을 작성합니다. 수퍼 블록 오프셋을 마운트 또는 fsck의 인수로 전달하여 백업 수퍼 블록을 대신 사용할 수 있습니다. 그래도 RAID 5 = 게임 오버에서 두 개의 드라이브가 다운되었습니다.
dmourati

1

다른 작업을 수행하기 전에 어레이에있는 각 드라이브에 대해 'mdadm --examine / dev / sdX1'을 캡처하고 그로부터 'mdadm --detail / dev / md0'을 결정하십시오. 정확한 레이아웃.

별도의 질문으로 Synology 어레이를 복구하기 위해이 작업을 직접 수행해야했습니다.

"E"상태의 드라이브로 Synology NAS에서 mdadm 어레이를 복구하는 방법은 무엇입니까?

편집 : 죄송합니다. 모든 드라이브에서 수퍼 블록을 잃었다 고 말한 것을 보았습니다.

나중의 명령은 올바른 것을 찾습니다. 가장 간단한 옵션은 가능한 순서대로 작성을 실행 한 다음 파일 시스템을 읽기 전용으로 마운트하고 액세스 할 수 있는지 확인하는 것입니다.


1

이 질문은 오래되었으며 지금은 아무도 당신을 도울 수 없지만 다른 사람들에게는 다음과 같은 내용이 있습니다.

당신이 한 가장 위험한 실수는 당신이 번호 매기기 한 실수가 아니며, 실행해야했습니다.

mdadm --create ...

수행 할 작업을 알기 전에 원본 디스크에 저장하십시오. 메타 데이터를 덮어 써서 드라이브 순서, 데이터 오프셋, 청크 크기 등의 기록이 없습니다.

이를 복구하려면 올바른 값으로 다시 덮어 써야합니다. 이것을 아는 가장 쉬운 방법은 메타 데이터를 보는 것이지만 이미 파괴했습니다. 다음 방법은 추측하는 것입니다. 알고있는 것 (4 개 장치, 레벨 5) 및 다른 디스크 순서를 제외한 모든 옵션에 대해 다른 값을 사용하여 이와 같은 명령의 다른 조합을 추측하십시오.

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

그러나 올바른 결과를 모르므로 다시 오래된 디스크에서 실행하여 디스크를 더 이상 파괴하여 동일한 치명적인 실수를해서는 안됩니다. 대신 오버레이를 사용하십시오. 예를 들어이 절차 는 원본을 안전하게 유지하는 데 효과적입니다.

fsck 또는 마운트 및 검증 할 수있는 작업 배열을 생성하는 일부 인수를 찾으면 (예 : 체크섬 / pgp로 저장해야하는 iso와 같은 모든 레이드 멤버에 걸쳐있을만큼 큰 파일의 체크섬 확인) 서명 또는 압축 풀기 -t 또는 gunzip -ta 큰 아카이브)


감사합니다. 한편 ZFS (RAIDZ2) 사용으로 넘어갔습니다. 그러나 노트를 읽는 것은 매우 흥미로 웠습니다. 나는 create 명령 메타 데이터를 덮어 썼다는 것을 알았지 만 그 당시에는 그렇지 않았다고 생각했습니다. 또한 오버레이 파일에 대해 몰랐습니다. 정말 깔끔합니다! 감사!
Peter Bos
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.