데이터 풀로 인해 액세스 할 수없는 zpool에 몇 TB의 매우 유용한 개인 데이터가 있습니다. 풀은 원래 2009 년에 우분투 8.04 시스템의 VMWare 가상 머신 내에서 실행되는 FreeBSD 7.2 시스템에 다시 설정되었습니다. FreeBSD VM은 여전히 사용 가능하고 잘 작동하고 있으며 호스트 OS 만 이제 데비안 6으로 변경되었습니다. 하드 드라이브는 VMWare 일반 SCSI 장치 (총 12 개)를 통해 게스트 VM에 액세스 할 수 있습니다.
2 개의 수영장이 있습니다 :
- zpool01 : 2x 4x 500GB
- zpool02 : 1x 4x 160GB
작동하는 것은 비어 있고 깨진 것은 모든 중요한 데이터를 보유합니다.
[user@host~]$ uname -a
FreeBSD host.domain 7.2-RELEASE FreeBSD 7.2-RELEASE #0: \
Fri May 1 07:18:07 UTC 2009 \
root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
[user@host ~]$ dmesg | grep ZFS
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
ZFS filesystem version 6
ZFS storage pool version 6
[user@host ~]$ sudo zpool status
pool: zpool01
state: UNAVAIL
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool01 UNAVAIL 0 0 0 insufficient replicas
raidz1 UNAVAIL 0 0 0 corrupted data
da5 ONLINE 0 0 0
da6 ONLINE 0 0 0
da7 ONLINE 0 0 0
da8 ONLINE 0 0 0
raidz1 ONLINE 0 0 0
da1 ONLINE 0 0 0
da2 ONLINE 0 0 0
da3 ONLINE 0 0 0
da4 ONLINE 0 0 0
pool: zpool02
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool02 ONLINE 0 0 0
raidz1 ONLINE 0 0 0
da9 ONLINE 0 0 0
da10 ONLINE 0 0 0
da11 ONLINE 0 0 0
da12 ONLINE 0 0 0
errors: No known data errors
몇 주 전에 수영장에 접근 할 수있었습니다. 그 이후로 호스트 시스템의 거의 모든 하드웨어를 교체하고 여러 호스트 운영 체제를 설치해야했습니다.
이 OS 설치 중 하나가 부트 로더 (또는 무엇이든)를 500GB 드라이브 중 하나 (첫 번째?)에 작성하고 일부 zpool 메타 데이터 (또는 무엇이든)를 파괴했다는 것입니다. 그 주제는 정확히 내 강점이 아닙니다 ...
ZFS에 관한 많은 웹 사이트, 블로그, 메일 링리스트 등이 있습니다. 나는이 질문이 제 데이터를 되 찾을 수 있도록 제정신, 구조적, 통제, 정보, 지식이 풍부한 접근 방법에 대한 충분한 정보를 수집하고 동일한 상황에서 다른 사람을 도울 수 있기를 희망하여 여기에 게시합니다.
'zfs recover'인터넷 검색시 첫 번째 검색 결과 는 Solaris ZFS 관리 설명서 의 ZFS 문제 해결 및 데이터 복구 장입니다. 첫 번째 ZFS 실패 모드 섹션에서는 '손상된 ZFS 데이터'단락에 다음과 같이 표시됩니다.
데이터 손상은 항상 영구적이며 복구 중에 특별히 고려해야합니다. 기본 장치를 수리하거나 교체하더라도 원본 데이터는 영구적으로 손실됩니다.
다소 실망.
그러나 두 번째 Google 검색 결과는 Max Bruning의 웹 블로그 이며 거기에서 읽었습니다.
최근 10TB ZFS 풀에 15 년 동안 비디오와 음악을 저장 한 사람으로부터 정전이 발생한 후 결함이 발생한 이메일을 보냈습니다. 불행히도 백업이 없었습니다. 그는 FreeBSD 7에서 ZFS 버전 6을 사용하고있었습니다. [...] 디스크에서 데이터를 검사하는 데 약 1 주일이 지난 후, 기본적으로 모든 것을 복원 할 수있었습니다.
과
ZFS가 데이터를 잃어 버린 것에 대해서는 의심합니다. 나는 당신의 데이터가 거기에 있다고 생각하지만, 그것을 얻는 올바른 방법을 찾아야합니다.
(내가 듣고 싶은 것보다 훨씬 더 들린다 ...)
첫 번째 단계 : 문제가 정확히 무엇입니까?
정확히 zpool이 손상된 것으로보고 된 이유를 어떻게 진단 할 수 있습니까? 웹의 어느 곳에서나 Sun 또는 Oracle이 공식적으로 문서화하지 않은 zdb가 있습니다. 매뉴얼 페이지에서 :
NAME
zdb - ZFS debugger
SYNOPSIS
zdb pool
DESCRIPTION
The zdb command is used by support engineers to diagnose failures and
gather statistics. Since the ZFS file system is always consistent on
disk and is self-repairing, zdb should only be run under the direction
by a support engineer.
If no arguments are specified, zdb, performs basic consistency checks
on the pool and associated datasets, and report any problems detected.
Any options supported by this command are internal to Sun and subject
to change at any time.
또한 Ben Rockwood는 자세한 기사 를 게시했으며 2008 년 6 월 28 일 프라하에서 열린 Solaris 개발자 컨퍼런스에서 Max Bruning에 대한 비디오 (및 mdb)에 대한 비디오 가 있습니다.
손상된 zpool에서 zdb를 루트로 실행하면 다음과 같은 출력이 나타납니다.
[user@host ~]$ sudo zdb zpool01
version=6
name='zpool01'
state=0
txg=83216
pool_guid=16471197341102820829
hostid=3885370542
hostname='host.domain'
vdev_tree
type='root'
id=0
guid=16471197341102820829
children[0]
type='raidz'
id=0
guid=48739167677596410
nparity=1
metaslab_array=14
metaslab_shift=34
ashift=9
asize=2000412475392
children[0]
type='disk'
id=0
guid=4795262086800816238
path='/dev/da5'
whole_disk=0
DTL=202
children[1]
type='disk'
id=1
guid=16218262712375173260
path='/dev/da6'
whole_disk=0
DTL=201
children[2]
type='disk'
id=2
guid=15597847700365748450
path='/dev/da7'
whole_disk=0
DTL=200
children[3]
type='disk'
id=3
guid=9839399967725049819
path='/dev/da8'
whole_disk=0
DTL=199
children[1]
type='raidz'
id=1
guid=8910308849729789724
nparity=1
metaslab_array=119
metaslab_shift=34
ashift=9
asize=2000412475392
children[0]
type='disk'
id=0
guid=5438331695267373463
path='/dev/da1'
whole_disk=0
DTL=198
children[1]
type='disk'
id=1
guid=2722163893739409369
path='/dev/da2'
whole_disk=0
DTL=197
children[2]
type='disk'
id=2
guid=11729319950433483953
path='/dev/da3'
whole_disk=0
DTL=196
children[3]
type='disk'
id=3
guid=7885201945644860203
path='/dev/da4'
whole_disk=0
DTL=195
zdb: can't open zpool01: Invalid argument
zpool01이 실제로 존재하지 않기 때문에 끝에 '유효하지 않은 인수'오류가 발생한다고 가정합니다. 작업중 인 zpool02에서는 발생하지 않지만 더 이상 출력되지 않는 것 같습니다 ...
이 단계에서는 기사가 너무 길어지기 전에 게시하는 것이 좋습니다.
어쩌면 누군가가 여기에서 앞으로 나아갈 수있는 방법에 대해 조언을 줄 수 있으며 응답을 기다리는 동안 비디오를보고 위의 zdb 출력에 대한 세부 사항을 살펴보고 Bens 기사를 읽고 무엇이 무엇인지 알아 내려고 시도합니다. 뭐...
20110806-1600 + 1000
업데이트 01 :
나는 근본 원인을 발견했다고 생각합니다. Max Bruning은 내 이메일에 매우 빠르게 응답하여의 출력을 요구하는 친절했습니다 zdb -lll. 풀의 'good'raidz1 절반에있는 4 개의 하드 드라이브에서 출력은 위에서 게시 한 것과 비슷합니다. 그러나 '손상된'절반에있는 4 개의 드라이브 중 첫 번째 3 개에는 레이블 2 및 3에 대한 zdb보고서 failed to unpack label가 있습니다. 풀의 네 번째 드라이브 zdb는 모든 레이블을 표시합니다.
해당 오류 메시지를 검색하면 이 게시물이 나타납니다 . 첫 번째 응답에서 해당 게시물로 :
ZFS를 사용하면 각 물리적 vdev에 4 개의 동일한 레이블 (이 경우 단일 하드 드라이브)이 있습니다. vdev 시작시 L0 / L1, vdev 종료시 L2 / L3
풀의 8 개 드라이브는 모두 Seagate Barracuda 500GB 와 동일한 모델 입니다. 그러나 4 개의 드라이브로 풀을 시작한 후 그 중 하나가 사망하고 Seagate의 보증에 따라 교체 된 것을 기억합니다. 나중에 또 다른 4 개의 드라이브를 추가했습니다. 이러한 이유로 드라이브 및 펌웨어 식별자는 다릅니다.
[user@host ~]$ dmesg | egrep '^da.*?: <'
da0: <VMware, VMware Virtual S 1.0> Fixed Direct Access SCSI-2 device
da1: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da2: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da3: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da4: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da5: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da6: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da7: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da8: <ATA ST3500418AS CC35> Fixed Direct Access SCSI-5 device
da9: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da10: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da11: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da12: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
모든 드라이브의 크기가 같았다는 것을 기억합니다. 이제 드라이브를 살펴보면 3 개 크기가 2MB 씩 줄었다는 것을 보여줍니다.
[user@host ~]$ dmesg | egrep '^da.*?: .*?MB '
da0: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C)
da1: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da2: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da3: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da4: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da5: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da6: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da7: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da8: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da9: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da10: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da11: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da12: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
따라서 외관상으로는 이전에 가정 한 것처럼 드라이브 하나에 부트 로더를 작성한 OS 설치 중 하나가 아니며 실제로 2MB 호스트를 만드는 새로운 마더 보드 ( ASUS P8P67 LE ) 였습니다 ZFS 메타 데이터를 엉망으로 만든 3 개의 드라이브 끝에 보호 영역이 있습니다 .
모든 드라이브에서 HPA를 작성하지 않은 이유는 무엇입니까? HPA 작성은 나중에 Seagate 하드 드라이브 BIOS 업데이트로 수정 된 버그가있는 구형 드라이브에서만 수행 되었기 때문입니다.이 전체 사건이 몇 주 전에 시작되면 Seagate의 SeaTools 를 실행 하여 드라이브에 물리적으로 문제가있는 것 (오래된 하드웨어에도 불구하고)에는 일부 드라이브에 BIOS 업데이트가 필요하다는 메시지가 표시됩니다. 지금은 그 메시지와 펌웨어 업데이트 다운로드 링크의 정확한 세부 사항을 재현하기 위해 노력하고, 메인 보드가 HPA를 생성하기 때문에, 모두 SeaTools는 DOS 버전이 문제의 하드 드라이브가 2 개이고을 감지하는 데 실패 할 것 같다 - 빠른 invalid partition또는 이와 유사한 그들이 시작할 때 깜박입니다. 아이러니하게도 그들은 삼성 드라이브 세트를 발견합니다.
(네트워크에 연결되지 않은 시스템의 FreeDOS 셸에서 나사로 조이는 고통스럽고 시간이 많이 걸리고 결과적으로 결실이없는 부분은 건너 뛰었습니다.) 결국 SeaTools Windows를 실행하기 위해 별도의 컴퓨터에 Windows 7을 설치했습니다. 버전 1.2.0.5. DOS SeaTools는 약 그냥 마지막 발언 : 마 그들을 부팅을 시도하고 귀찮게하지 독립형 - 대신, 몇 분을 투자하고 멋진로 부팅 가능한 USB 스틱을 만드는 궁극적 인 부팅 CD - 떨어져 DOS SeaTools는에서도 정말 많은 많은 다른 얻는다 유용한 도구.
Windows 용 SeaTools가 시작되면이 대화 상자가 나타납니다.
이 링크는 일련 번호 검사기 (어떤 이유로 보안 문자에 의해 보호됩니다-광산은 '침습적 사용자'였습니다) 및 펌웨어 업데이트에 대한 기술 자료 문서로 연결 됩니다. 아마도 하드 드라이브 모델 및 일부 다운로드에 대한 추가 링크가있을 수 있습니다.
파티션이 잘리고 손상된 스토리지 풀의 일부인 한 번에 세 개의 드라이브의 펌웨어를 업데이트하지는 않겠습니다. 문제가 생겼습니다. 우선 펌웨어 업데이트를 취소 할 수 없으며 데이터를 다시 가져올 수있는 기회를 잃을 수도 있습니다.
따라서 다음으로 할 첫 번째 작업은 드라이브 이미지를 만들고 복사본으로 작업하는 것이므로 문제가 발생하면 다시 돌아 가야 할 원본이 있습니다. ZFS는 동일한 하드 드라이브 모델에 비트 dd 사본이 있더라도 드라이브 일련 번호 또는 다른 UUID 등을 통해 드라이브가 스왑되었음을 알 수 있으므로 추가 복잡성이 발생할 수 있습니다. 게다가 zpool은 살아 있지도 않습니다. 소년, 이것은 까다로울 수 있습니다.
그러나 다른 옵션은 원본을 사용하여 미러링 된 드라이브를 백업으로 유지하는 것이지만 원본에 문제가있을 경우 복잡성을 극복 할 수 있습니다. 아냐, 좋지 않아
깨진 풀에있는 버그가있는 BIOS로 3 개의 드라이브를 대체 할 이미지로 사용되는 3 개의 하드 드라이브를 지우려면 지금 존재하는 항목에 대한 저장 공간을 만들어야합니다. 하드웨어 상자와 일부 오래된 드라이브에서 임시 zpool을 조립합니다. ZFS가 dd'd 드라이브 교체를 처리하는 방법을 테스트하는 데 사용할 수도 있습니다.
시간이 좀 걸릴 수 있습니다 ...
20111213-1930 + 1100
업데이트 02 :
실제로 시간이 걸렸습니다. 나는 책상에 여러 개의 열린 컴퓨터 케이스를 가지고 여러 달 동안 하드 드라이브 스택이 매달려 있고 귀마개로 몇 밤을 잤다. . 그러나 나는 마침내 승리했다! :-) 나는 또한 그 과정에서 많은 것을 배웠으며 비슷한 상황에있는 누군가를 위해 그 지식을 공유하고 싶습니다.
이 기사는 ZFS 파일 서버를 사용하지 않는 사람이 읽을 시간이있는 것보다 이미 더 길기 때문에 여기에서 자세한 내용을 살펴보고 아래에서 더 중요한 결과를 얻을 수 있습니다.
구식 하드웨어 상자를 깊이 파고 들어가서 결함이있는 드라이브가 미러링 된 단일 500GB 드라이브에서 물건을 옮길 수있는 충분한 저장 공간을 조립했습니다. 또한 USB 케이스에서 몇 개의 하드 드라이브를 제거해야했기 때문에 SATA를 통해 직접 연결할 수있었습니다. 더 관련이없는 관련 문제가 있었으며 zpool 교체가 필요한 조치로 되돌릴 때 오래된 드라이브 중 일부가 실패하기 시작했지만 건너 뛸 것입니다.
팁 : 어떤 단계에서는 총 30 개의 하드 드라이브가 관여했습니다. 하드웨어가 많으면 제대로 쌓아 두는 것이 큰 도움이됩니다. 케이블이 느슨해 지거나 하드 드라이브가 책상에서 떨어지면 프로세스에 도움이되지 않으며 데이터 무결성이 더 손상 될 수 있습니다.
나는 물건을 분류하는 데 실제로 도움이되는 임시 변통 하드 드라이브 비품을 만드는 데 몇 분을 보냈습니다.
아이러니하게도, 구식 드라이브를 처음 연결할 때 구식 zpool이 있다는 것을 깨달았습니다. 구식 zpool은 구 버전의 일부로 테스트하기 위해 만들어야했지만 누락 된 모든 개인 데이터가 아니기 때문에 데이터 손실이 발생했습니다. 다소 줄어든다는 것은 파일의 앞뒤로 추가 이동을 의미했습니다.
마지막으로 문제가있는 드라이브를 백업 드라이브에 미러링하고 zpool 용 드라이브를 사용하고 원래 드라이브를 연결 해제했습니다. 백업 드라이브에는 최신 펌웨어가 있으며, 최소한 SeaTools는 필요한 펌웨어 업데이트를보고하지 않습니다. 한 장치에서 다른 장치로 간단한 dd를 사용하여 미러링을 수행했습니다.
sudo dd if=/dev/sda of=/dev/sde
ZFS는 (하드 드라이브 UUID 등으로 인해) 하드웨어 변경을 인식하지만 신경 쓰지 않는 것 같습니다.
그러나 zpool은 여전히 동일한 상태에 있었으며 복제본이 불충분하고 데이터가 손상되었습니다.
앞에서 언급 한 HPA Wikipedia 기사에서 언급했듯이 호스트 보호 영역의 존재는 Linux 부팅시보고되며 hdparm을 사용하여 조사 할 수 있습니다 . 내가 아는 한 FreeBSD에는 hdparm 툴이 없지만, 지금까지 FreeBSD 8.2와 Debian 6.0을 듀얼 부트 시스템으로 설치 했으므로 리눅스로 부팅했습니다 :
user@host:~$ for i in {a..l}; do sudo hdparm -N /dev/sd$i; done
...
/dev/sdd:
max sectors = 976773168/976773168, HPA is disabled
/dev/sde:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdf:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdg:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdh:
max sectors = 976773168/976773168, HPA is disabled
...
따라서 문제는 새로운 마더 보드가 드라이브 끝에 두 개의 메가 바이트의 HPA를 생성하여 상단의 두 ZFS 레이블을 '숨겨'서 ZFS가이를 볼 수 없다는 점입니다.
HPA와 함께하는 것은 위험한 사업으로 보입니다. hdparm 매뉴얼 페이지에서 매개 변수 -N :
Get/set max visible number of sectors, also known as the Host Protected Area setting.
...
To change the current max (VERY DANGEROUS, DATA LOSS IS EXTREMELY LIKELY), a new value
should be provided (in base10) immediately following the -N option.
This value is specified as a count of sectors, rather than the "max sector address"
of the drive. Drives have the concept of a temporary (volatile) setting which is lost on
the next hardware reset, as well as a more permanent (non-volatile) value which survives
resets and power cycles. By default, -N affects only the temporary (volatile) setting.
To change the permanent (non-volatile) value, prepend a leading p character immediately
before the first digit of the value. Drives are supposed to allow only a single permanent
change per session. A hardware reset (or power cycle) is required before another
permanent -N operation can succeed.
...
필자의 경우 HPA는 다음과 같이 제거됩니다.
user@host:~$ sudo hdparm -Np976773168 /dev/sde
/dev/sde:
setting max visible sectors to 976773168 (permanent)
max sectors = 976773168/976773168, HPA is disabled
HPA를 사용하는 다른 드라이브에서도 마찬가지입니다. 잘못된 크기의 드라이브 나 지정한 크기 매개 변수에 대한 정보가 적합하지 않은 경우 hdparm은 충분히 똑똑합니다.
user@host:~$ sudo hdparm -Np976773168 /dev/sdx
/dev/sdx:
setting max visible sectors to 976773168 (permanent)
Use of -Nnnnnn is VERY DANGEROUS.
You have requested reducing the apparent size of the drive.
This is a BAD idea, and can easily destroy all of the drive's contents.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.
그 후 zpool이 원래 생성 된 FreeBSD 7.2 가상 머신을 다시 시작하고 zpool 상태가 작업 풀을 다시보고했습니다. 예! :-)
가상 시스템에서 풀을 내보내고 호스트 FreeBSD 8.2 시스템에서 다시 가져 왔습니다.
일부 주요 하드웨어 업그레이드, 다른 마더 보드 스왑, ZFS 4/15 로의 ZFS 풀 업데이트, 철저한 스크러빙 및 이제 zpool은 8x1TB와 8x500GB raidz2 부품으로 구성됩니다.
[user@host ~]$ sudo zpool status
pool: zpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool ONLINE 0 0 0
raidz2 ONLINE 0 0 0
ad0 ONLINE 0 0 0
ad1 ONLINE 0 0 0
ad2 ONLINE 0 0 0
ad3 ONLINE 0 0 0
ad8 ONLINE 0 0 0
ad10 ONLINE 0 0 0
ad14 ONLINE 0 0 0
ad16 ONLINE 0 0 0
raidz2 ONLINE 0 0 0
da0 ONLINE 0 0 0
da1 ONLINE 0 0 0
da2 ONLINE 0 0 0
da3 ONLINE 0 0 0
da4 ONLINE 0 0 0
da5 ONLINE 0 0 0
da6 ONLINE 0 0 0
da7 ONLINE 0 0 0
errors: No known data errors
[user@host ~]$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/label/root 29G 13G 14G 49% /
devfs 1.0K 1.0K 0B 100% /dev
zpool 8.0T 3.6T 4.5T 44% /mnt/zpool
마지막으로 ZFS 풀은 죽이기가 매우 어렵습니다. 그 시스템을 만든 Sun의 사람들은 파일 시스템의 마지막 단어라고 부르는 모든 이유를 가지고 있습니다. 존경!