나는 오늘 이름이 기존 Linux zpool에 세 번째 미러를 추가하려고 시도하면서 매우 어리석은 짓을 했습니다 backup. 몇 년마다 디스크를 교체하는 것 외에 ZFS에 대해 많은 관리 작업을 수행하지 않기 때문에 몇 가지 오류를 범했다고만 말하면 충분합니다. 그리고 이를 수정하려고 시도하면서 풀을 다시 생성하라는 온라인 조언을 잘못 읽고 이름이 새 풀을 생성하여 backup기존 풀을 파괴했습니다. (예, 불만이 제기된 후에 옵션을 사용했습니다 -f. 예, 저는 바보입니다. 이제 다시는 그런 일을 하지 않을 것이라는 것을 압니다. 계속 진행하겠습니다.)
온라인에서 읽은 내용에 따르면 backup내가 "만든" 원래 풀은 복구할 수 없을 가능성이 높습니다. 이름이 붙은 데는 이유가 있기 때문에 괜찮습니다 backup. 대부분 약 15년 전의 백업을 보관하기 위한 것입니다. 그러나 다시 가져오면 좋을 몇 가지 사항(임시로 옮긴 일부 비필수 데이터)과 백업 설정과 관련하여 다시 설정하는 데 며칠이 걸리는 몇 가지 사항이 있습니다. 해당 볼륨에 상주했습니다. (이제 나는 그 자료를 다른 곳에 백업하는 방법을 알고 있으므로 이것이 학습 경험이 될 것입니다.)
하지만 백업에 대한 백업이 있습니다. 몇 달 전에 시스템을 업그레이드하는 동안(OS 업그레이드와 함께) 제거한 드라이브에 대한 세 번째 미러를 오늘 교체하려고 했습니다. 그 드라이브는 실제로 고장이 나지 않았지만 오래되었고 몇 개의 불량 섹터가 쌓이기 시작했기 때문에 손상될 때까지 기다리기보다는 그냥 꺼내는 것이 좋겠다고 생각했습니다.
어쨌든, 나는 아직도 그 오래된 드라이브를 가지고 있기 때문에 그것을 내 시스템에 다시 넣고 거기에서 풀 데이터를 복구할 수 있다고 생각했습니다. 지난 몇 달 동안의 백업 데이터만 누락되었을 뿐입니다. 이제 저는 해당 드라이브 등의 풀을 공식적으로 내보낸 적이 없습니다. 그 이후로 OS를 업그레이드했기 때문에 해당 드라이브가 자동으로 감지될 것이라고는 예상하지 못했습니다. (몇몇 드라이브를 옮겨봤기 때문에 동일한 SATA 포트에 연결되어 있는지 여부는 알 수 없습니다.)
그러나 zpool import명령이 자동으로 아무것도 찾지 못하는 것 같습니다. 몇 가지 옵션을 가지고 놀면서 zpool import(지금은 파괴된) 풀의 두 번째 버전을 볼 수 있지만 backup그것은 제가 실수로 다른 두 드라이브에 만든 빈 풀일 뿐입니다.
이 세 번째 디스크의 데이터를 읽을 수 있는 방법에 대한 조언이 있습니까? 내가 기억하는 한 그것은 몇 달 전 케이스에서 꺼내기 전까지 ZFS 풀의 완벽한 기능을 갖춘 최신 미러였습니다. 특히:
backup이 오래된 풀을 감지하고 복구/가져오기를 시도하는 기능을 잠재적으로 방해하는 파괴된 풀이 있다는 사실입니까 ? 그 문제를 해결할 방법이 있나요?- 이전 디스크를 사용할 때 실행 중이었던 것으로 생각되는 이전 OS 설치가 내 서버에 아직 남아 있습니다. ZFS 풀을 감지할 수 있는지 확인하기 위해 부팅을 시도했지만 감지하지 못했습니다. (다시 말하지만, 드라이브가 같은 위치에 연결되어 있지 않을 수도 있습니다.) 그러나 이전 풀의 메타데이터나 ID 번호 또는 내가 입력한 내용을 포함할 수 있는 ZFS 로그 파일이나 기타 항목을 가져올 수 있습니까? 잠재적으로 ZFS가 이 드라이브에 온전한 미러여야 하는 항목을 가져오도록 할 수 있습니까?
- 처음 두 디스크의 풀이 명령을 통해 파괴되었다고 가정합니다
create -f. 그러나 누군가 내가 그곳에서 첫 번째 풀을 직접 복구할 수 있는 방법에 대한 아이디어를 가지고 있다면 분명히 좋을 것입니다. - ZFS가 이전 세 번째 미러를 ZFS 풀 디스크로 감지하지 못하는 다른 이유가 있습니까? 그렇다면 다른 제안은 없나요? 시도해 볼 수 있는 다른 복구 도구가 있나요?
도움이나 제안을 보내주셔서 감사합니다.
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
이것을 올바르게 해석하면 상태 0은 풀이 손상되지 않았음을 의미합니다. 그러나 풀 GUID를 사용하여 가져오기를 시도하면 zpool import 3936176493905234028"가져올 수 없습니다... 사용할 수 있는 풀이 없습니다." 오류가 발생합니다. (pool_guid를 사용해야 한다고 가정하고 있지만 guid와 top_guid도 사용해 보았지만 아무것도 작동하지 않는 것 같습니다.)
EDIT2: 이 풀이 활성화되어 있던 원래 OS에서 zpool.cache 파일을 복구하여 시도했는데 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도 이에 동의합니다. 왜 수입되지 않습니까?