☰

RAID 5가 충돌합니다...가능한 한 저장하려고 합니다. [닫기]

tag-icon • tag-icon mdadm raid5 qnap
RAID 5가 충돌합니다...가능한 한 저장하려고 합니다. [닫기]

8개의 디스크가 있는 QNAP 서버가 있습니다. 사용하지 않은 백업/추가 디스크가 2개 있습니다. (돈이 있고 결국 실행 중인 디스크를 교체해야 한다는 것을 알고 있습니다.) 전체 어레이는 각각 6TB의 8개 디스크에 분산되어 있습니다... 수학... 하지만 현재 1/3 미만이 채워져 있다고 확신합니다 .

QNAP 담당자가 이 문제를 해결했는데 이중 디스크 다이빙은 복구가 불가능할 가능성이 높다고 말했습니다. 담당자가 자신에게 허용된 작업/할 수 있는 작업이 무엇인지 알고 있다고 생각합니다. 하지만...

나는 사람들이 이런 재난에서 회복하는 것을 보았습니다. 시스템에 따르면 모든 디스크가 그대로 유지되기를 바랍니다. ? ?

"잘못된 매직 넘버"/"유효한 파일 시스템 슈퍼블록을 찾을 수 없습니다" 오류 발생

표현 전후의 장치 진단 출력은 다음과 같습니다.

**** 앞으로****:

RAID metadata found!
UUID:       cccd0319:89c30791:58322cfe:12ed5c64
Level:      raid5
Devices:    8
Name:       md1
Chunk Size: 64K
md Version: 1.0
Creation Time:  Mar 23 11:49:45 2017
Status:     OFFLINE
===============================================================================
 Disk | Device | # | Status |   Last Update Time   | Events | Array State
===============================================================================
   5  /dev/sdl3  0   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
   6  /dev/sdk3  1   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
   7  /dev/sdj3  2   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
 --------------  3  Missing   -------------------------------------------
   9  /dev/sdh3  4   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
  10  /dev/sdg3  5   Active   Apr 23 15:03:27 2019     3515   AAAAAAAA                 
  11  /dev/sdf3  6   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
  12  /dev/sde3  7   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
===============================================================================

**** 뒤쪽에****:

RAID metadata found!
UUID:       a6860c7d:0b020f8d:1a61ec72:4684aeb7
Level:      raid5
Devices:    8
Name:       md1
Chunk Size: 64K
md Version: 1.0
Creation Time:  Apr 29 14:08:04 2019
Status:         ONLINE (md1) [UU_UUUUU]
===============================================================================
 Disk | Device | # | Status |   Last Update Time   | Events | Array State
===============================================================================
  12  /dev/sde3  0   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
  11  /dev/sdf3  1   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
  10  /dev/sdg3  2  Rebuild   Apr 29 14:38:42 2019      331   AAAAAAAA                 
   9  /dev/sdh3  3   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
   8  /dev/sdi3  4   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
   7  /dev/sdj3  5   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
   6  /dev/sdk3  6   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
   5  /dev/sdl3  7   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
===============================================================================

답변1

전후 사이에 무슨 일이 일어났는지 정확히 아는 사람이 아무도 없기 때문에 실제로 대답하는 것은 거의 불가능합니다. 아래의 제 추론을 냉정하게 받아들이십시오. 이것이 어떻게 발생했는지 확실하게 말할 수는 없지만, 귀하가 제공한 데이터에 따르면 이것이 사실인 것 같습니다.

귀하의 드라이브(이전)에는 드라이브 1개가 완전히 누락되었으며 다른 드라이브는 확실히 사용되지 않는 것으로 표시되었습니다. (4월 23일과 4월 28일, 이벤트 수는 3515와 3927입니다).

너의 (이후) 엉망. 이벤트 카운트 재설정(331), 드라이브 순서가 완전히 다릅니다(sde3은 #7, 현재 #0. sdf3은 #6, 현재 #1 등). 손실된 드라이브를 복구하는 방법이 불분명하며 사용되지 않는 드라이브를 강제로 넣습니다. 구성으로 돌아갑니다. . 또한 드라이브 #3이 누락되고 드라이브 #5가 만료되었음에도 불구하고 드라이브 #2가 재구축되고 있음을 보여줍니다.

기본적으로 누군가 올바르게 수행되면 작동할 RAID를 다시 만든 것처럼 보이지만,당신이 무엇을 하고 있는지 정말로 알고 있지만 그렇지 않은 경우에만. 드라이브 순서 변경을 설명할 수 없다면 여기서는 올바르게 수행된 것 같지 않습니다.

이러한 가정이 정확하다면 (이전) 상태에서 데이터를 복구할 가능성이 여전히 높습니다. 파일 시스템 자체가 손상되더라도 오류 이벤트(4월 23일) 이후 수정되지 않은 모든 파일은 손상되지 않고 어느 정도 복구 가능해야 합니다.

다시 동기화된 드라이브가 다시 생성되고 재구축이 진행되면서 드라이브 #7 및 #2의 데이터가 손상될 가능성이 있으므로 이러한 복구 가능성은 이제 0이거나 오히려 청크 크기보다 작은 파일로 줄어듭니다. 정확히 64K. 코드 조각으로는 충분하지만 그 외에는 많지 않습니다.

이 시점에서 당신을 구할 수 있는 한 가지는 누락된 드라이브가 실제로 고장난 것이 아니라 무작위로 제거되었으며 4월 23일 이전에 제거되지 않은 경우입니다. 실제로 드라이브가 물리적으로 교체되었는지 여부는 명시하지 않습니다.

손실된 드라이브에 실제로 결함이 없고 여전히 유효한 데이터가 있고 어레이에서 계속 회전하는 경우 드라이브의 순서가 잘못된 경우에도 드라이브를 다시 생성하면 추가 손상이 발생하지 않을 수 있습니다. 이는 XOR 패리티 계산이 작동하는 방식(순서에 상관없음)으로 인해 raid5에 가능한 마술입니다.

관련 정보