얼마 전 ZFS 풀로 작업하는 동안 몇 가지 중요한 실수를 저질렀고(수정을 위한 일부 온라인 조언을 잘못 읽음) 실수로 backup. (예, -f불만이 제기된 후에 해당 옵션을 사용했습니다. 이제 다시는 그렇게 하지 않는다는 것을 압니다.)
어쨌든, 나는 몇 달 전에 우연히 같은 풀에서 세 번째 미러 드라이브를 가져갔습니다. 그 드라이브가 오래되고 실패하기 시작할 때까지 기다리고 싶지 않았기 때문입니다. 그래서 이 드라이브를 교체하여 풀을 복원하는 데 사용할 수 있다고 생각했습니다. (저는 지난 몇 달 간의 백업을 놓쳤는데, 대부분 이 풀의 용도입니다.)
하지만 이 오래된 드라이브를 사용하여 풀을 가져올 수 없는 것 같습니다. 처음에는 이것이 backup실수로 만든(그리고 나서 파괴된) 새 풀의 이름 충돌과 관련이 있을 수 있다고 생각했습니다. 그러나 GUID를 통해 가져오려고 해도 아무 것도 얻지 못합니다.
이것은 zdb -l /dev/sdb1의 출력입니다(세 번째 드라이브입니다).
------------------------------------
LABEL 0
------------------------------------
version: 5000
name: 'backup'
state: 0
txg: 0
pool_guid: 3936176493905234028
errata: 0
hostid: 8323329
hostname: [omitted]
top_guid: 14695910886267065742
guid: 17986383713788026938
vdev_children: 1
vdev_tree:
type: 'mirror'
id: 0
guid: 14695910886267065742
whole_disk: 0
metaslab_array: 34
metaslab_shift: 33
ashift: 12
asize: 1000197324800
is_log: 0
create_txg: 4
children[0]:
type: 'disk'
id: 0
guid: 17914838236907067293
path: '/dev/sdd1'
whole_disk: 0
DTL: 143
create_txg: 4
children[1]:
type: 'disk'
id: 1
guid: 17986383713788026938
path: '/dev/sdb1'
whole_disk: 0
DTL: 141
children[2]:
type: 'disk'
id: 2
guid: 1683783279473519399
path: '/dev/sdc1'
whole_disk: 0
DTL: 145
create_txg: 4
features_for_read:
com.delphix:hole_birth
com.delphix:embedded_data
create_txg: 0
labels = 0 1 2 3
따라서 zdb에 따르면 드라이브와 드라이브의 풀 데이터가 손상되지 않은 것처럼 보입니다. 그러나 풀을 가져오면( -f및/또는 을 사용하더라도 -F) "가져올 수 없습니다... 사용할 수 있는 풀이 없습니다." 오류가 발생합니다. 또한 위 정보에서 다양한 GUID를 사용해 보았지만(GUID가 관련성이 있는지 확실하지 않기 때문에) zpool import 3936176493905234028이러한 명령 중 어느 것도 "해당 풀을 사용할 수 없습니다"라는 메시지 외에는 아무 것도 얻지 못했습니다.
드라이브를 삭제한 후 새 버전의 Linux OS를 설치했기 때문에 zpool.cache이전 OS에서 복구한 이전 파일을 사용하면 차이가 있을 수 있다고 생각했습니다. 그러나 명령은 zpool import -c zpool.cache다음을 제공합니다.
pool: backup
id: 3936176493905234028
state: UNAVAIL
status: One or more devices contains corrupted data.
action: The pool cannot be imported due to damaged devices or data.
see: http://zfsonlinux.org/msg/ZFS-8000-5E
config:
backup UNAVAIL insufficient replicas
mirror-0 UNAVAIL insufficient replicas
sdd1 FAULTED corrupted data
sdc1 FAULTED corrupted data
이는 어느 정도 예상할 수 있는 일입니다. 이는 내 create 명령이 풀을 위해 다루는 두 개의 디스크입니다. 그러나 sdb1은 잠재적인 드라이브로 나열되지 않습니다. 아마도 디스크를 제거한 후 풀에서 제거했기 때문일 것입니다. 그럼에도 불구하고 나는 sdb1에 이전 미러 데이터의 전체 복사본을 가지고 있다고 생각하며 zdb도 이에 동의합니다. 왜 수입하지 않습니까?
시도해 볼 만한 다른 제안이 있나요? 다른 진단 명령을 실행하시겠습니까?
참고: 나는 시도했다서버 장애에서 이 질문을 해보세요(제 상황에 대한 자세한 내용은 링크를 참조하세요.) 그러나 어떤 피드백도 얻지 못했고 이 문제를 해결하는 방법을 알아내는 데 특정 Linux 구현이 중요할 수 있다는 것을 깨달았습니다. 어떤 의견이나 제안이라도 진심으로 감사드립니다.
고쳐 쓰다:제 생각에는 문제를 발견한 것 같습니다. detach명령을 내리기 전에 예비 드라이브를 제거했다고 생각했습니다 . 태그 정보(다른 온라인 소스가 손상된 풀 메타데이터를 나타내는 것처럼 보일 때)가 여전히 표시된다는 사실이 detach이를 확인하는 것 같습니다. 나는 단순히 zdb -l backup태그 정보를 입력하고 얻을 수 있다는 것을 알았습니다(그리고 get uberblock information을 사용합니다 -u). 그래서 zfs는 장치를 명시적으로 가리키지 않고도 풀을 볼 수 있는 것처럼 보였습니다. 어떤 이유로 든 가져오고 싶지 않습니다.
그러나 더 이상 상태가 확실하지 않습니다 detach. 나는 우연히 우연히 발견했다이 오래된 스레드분리된 미러에서 ZFS 풀을 복원하는 경우 암시적으로 txg0 값을 인용합니다. 슈퍼 블록이 0으로 처리된다는 점은 다른 곳에서도 언급되어 있습니다 detach.
backup글쎄, 내 풀의 uberblock은 목록을 표시합니다 txg = 0(다른 곳에 있는 활성 zpool은 해당 필드에 0이 아닌 큰 숫자를 가지고 있습니다). 기존 슈퍼블록은 있지만 하나만 있고, 나머지는 backup'무효'로 기재돼 있다. 불행히도 zdb온라인에서 문서를 쉽게 찾을 수 없는 것 같습니다 .
이것이 예비 세 번째 드라이브가 분리되었음을 의미한다고 가정합니까? 누구든지 내 설명을 확인할 수 있나요? 그런데 드라이브 데이터가 손상되지 않은 경우 복구할 수 있는 방법이 있나요? 하지만인터넷에서 몇 가지 제안분리된 미러는 재동기화 없이 복원할 수 없음을 보여주는데, 위에 링크한 스레드에는 태그가 uberblock에 문제가 없다고 생각하도록 속이는 매우 간단한 기능을 수행하는 것으로 보이는 Solaris 코드가 있습니다. 더 많이 탐색하고 나를 발견하세요이 유틸리티의 업데이트된 Solaris 버전불과 3년 전부터 시작했습니다.
내 이해가 정확하고 세 번째 이미지가 분리되었다고 가정하면 Linux에서 유사한 uberblock 태그 수정을 시도할 수 있습니까? Solaris 코드를 다시 작성하여 Linux로 이식하려는 시도가 유일한 선택입니까? (내가 그 일을 할 수 있을지 잘 모르겠습니다.)
솔직히 말해서 온라인에서 이 시나리오에 대한 많은 참조를 고려할 때 ZFS에 대한 합리적인 데이터 복구 도구가 부족하다는 사실에 놀랐습니다. 것 같다마지막으로 몇 가지 옵션이 있습니다일반적인 문제에 대한 기본 데이터 복구(명령으로 덮어쓴 풀을 복구하는 가능성 포함 create. 이 기능은 나에게 적합하지 않은 것 같습니다.) 그러나 Solaris용 일회성 스크립트 외에는 처리할 수 있는 것이 없습니다. 장치의 내용. 실망스럽게도 ZFS 풀을 가져오지 못하는 데에는 최소 12가지 이유(때때로 쉽게 복구할 수 있는 사소한 이유)가 있으며 문제 해결, 올바른 오류 코드 또는 문서가 거의 없습니다.
다시 한번 말씀드리지만, 어떤 도움, 아이디어, 제안이라도 대단히 감사하겠습니다. 누구든지 이 질문을 할 수 있는 더 좋은 장소를 추천해 주시면 정말 감사하겠습니다.
업데이트 2:offline장치가 내가 생각했던 곳에 배치 되었을 수도 있습니다 . 오프라인 장치도 결국 단일 이미지로 가져오지 못할 수 있다는 다양한 게시물을 읽었습니다. ZFS의 메타데이터와 zdb 출력은 제대로 문서화되어 있지 않기 때문에 수천 줄의 소스 코드를 읽지 않고는 uberblock과 태그 데이터가 무엇을 의미하는지 확인하는 방법을 실제로 알지 못합니다.
답변1
글쎄요, 거의 가까워졌고 회복의 길을 찾은 것 같습니다. 아직 다른 사람의 의견을 들어본 적이 없기 때문에 지금까지 배운 내용을 게시하겠습니다.
요약:
labelfix가져올 수 없는 풀을 가져올 수 있도록 만드는 데 사용할 수 있는 특정 유형의 손상된(및 오프라인/분리된) ZFS 볼륨의 레이블을 복구하기 위해 유지 관리 되지 않고 비공식적으로 지원되는 유틸리티가 있습니다 .- 어떤 작업을 수행하기 전에 이전 대기 데이터베이스를 복제하고 복제본만 복제하십시오.
- 질문에 설명된 상황(버그나 기타 오류로 인해)이 같은 이름을 가진 두 개의 풀이 있는 경우
create복원하려는 특정 풀에 대한 장치만 연결했는지 확인하세요. - 또한 복원 중이지만 실패한 풀과 연결되었을 수 있는 모든 장치를 제거하십시오. (이는 다른 풀을 완전히 파괴하고 해당 장치의 연결을 끊었다고 생각하는 경우에도 적용됩니다. 복구 도구는 이전 풀의 조각을 하나로 모으고 장비와 데이터를 결합하지 않기 위해 이전 태그/수퍼블록을 읽을 수 있습니다. 예측 방식).
자세한 내용은:
Linux의 zpool에서 오프라인 및 분리된 드라이브를 복구하는 방법이 있는 것 같습니다. 사용자 jjwhitney가 생성함labelfix 유틸리티용 포트나는 원래 Jeff Bonwick(ZFS 발명가)이 작성한 질문에서 언급했습니다.거의 12년 전. 제가 이해할 수 없는 이유로 이 유틸리티는 아직 ZFS 버전에 통합되지 않았습니다. 하지만 잘못된 태그로 인해 여러 가지 이유로 가져오기가 실패할 경우 전체 풀의 데이터를 복구할 수 있습니다. (이 문제에 대한 일부 논의여기.)
(참고: 이 프로세스를 통해 제가 깨닫게 된 한 가지는 ZFS 복구 도구가 심각하게 부족하며 누구도 이 파일 시스템을 사용해서는 안 된다는 것입니다.아무것항상 실행되는 데이터의 전체 백업은 없습니다. 그리고 그것이 중요하다고 확신하지 않는 한, 옷장에 있는 오래된 미러링 드라이브를 최후의 백업 기회로 의존하지 마십시오. ZFS는 협업과 관련하여 데이터 무결성을 유지하는 데는 매우 뛰어나지만 매우 취약합니다. 데이터가 손상되거나 사소하지만 어리석은 일을 하면 데이터가 손상되지 않았더라도 데이터에 완전히 액세스하거나 읽을 수 없게 될 수 있습니다. )
그럼에도 불구하고 labelfix 유틸리티는 5년 동안 업데이트되지 않았으므로 최신 ZFS 라이브러리로 컴파일할 수 없습니다. 운 좋게도 원래 OS 버전이 아직 설치되어 있고 해당 버전으로 부팅한 다음 이전 OS 버전을 다운로드할 수 있습니다.Linux의 ZFStarball을 소싱하고 이를 사용하여 적절한 ZFS 라이브러리를 얻고 모든 것이 여전히 작동하는 시스템에 환경을 구축합니다. (최신 ZFS 라이브러리를 사용하려고 labelfix 유틸리티를 적용하기 시작했지만 현재 코드베이스에 대응하기 위해 수정해야 하는 모든 내부 사항에 대한 아이디어가 거의 없었기 때문에 조금 위험해 보였습니다. 빌드하기가 더 쉬울 것입니다. 이전 버전 위에 있습니다.)
보라, labelfix내 장치의 라벨을 zpool import최소한 설명 가능한 것으로 즉각적이고 쉽게 다시 작성할 수 있습니다!
나는 ddrescue어떤 작업을 시도하기 전에 원본 드라이브의 전체 내용을 복사하곤 했습니다. 제가 했던 것처럼 실수가 있을 수 있기 때문에 이렇게 하는 것을 적극 권장합니다. 실수로 작성한 원래 풀의 이름이 지정 backup되어 zdb여러 버전의 다른 풀이 보이기 시작했고 backup모든 메타데이터가 일치하지 않는 이유를 알 수 없었습니다. vdev_validate_skip=1풀을 가져오기 위해 ZFS 커널 모듈을 조정해야 했지만 그 다음에는최신 backup수영장(내가 원했던 것이 아님). 원하는 드라이브의 정확한 경로를 지정하더라도 이 문제가 발생합니다 import. 이 방법을 사용하여 강제로 가져오면 내 지정을 완전히 무시하고 목록에 나열되지 않은 파일과 동일한 파일을 사용하는 것 같습니다. 장치의 구성이 다릅니다. 주문하다.
운 좋게도 다른 드라이브 복제를 이미 만들었기 때문에 다시 실행해 볼 수 있었습니다. 그러나 labelfix현재 드라이브 구성을 읽는 것처럼 보일 만큼 똑똑하기 때문에 backup첫 번째 풀에 "데이터가 손상"된 오래된 드라이브 2개가 있다는 것을 발견했습니다. 불행하게도 손상은 "수정됨" 레이블이 풀을 "불가능"으로 나열할 뿐만 아니라 "불가능"으로 DEGRADED도 나열함을 의미합니다 .FAULTEDimport
이 시점에서 나는 복구 시도를 망치는 것을 피하기 위해 기존 드라이브를 모두 분리하고 시스템에서 드라이브 없이 작업할 수 있다는 것을 깨달았습니다. 안타깝게도 labelfix이 문제는 한 번만 수정할 수 있는 것 같으므로 이제 해당 드라이브의 #3을 복제하겠습니다(현재 첫 번째 백업에서 복제 중). 복제 프로세스가 완료되면 labelfix다른 기존 드라이브 없이 실행 되며 DEGRADED작업할 수 있는 풀이 생길 것입니다 import.