zpoolには非常に貴重な個人データが数TBありますが、データ破損のためアクセスできません。プールはもともと、Ubuntu 8.04システムの上にあるVMWare仮想マシン内で実行されているFreeBSD 7.2システムで2009年前後に設定されました。FreeBSD VMは引き続き利用可能で正常に動作します。ホストOSのみがDebian 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インストールの1つが500GBドライブの1つ（最初の？）にブートローダー（または何でも）を書き込み、いくつかのzpoolメタデータ（または何でも）を破壊したことです-「またはこれ」は非常に漠然としたアイデアであることを意味しますそして、その主題はまさに私の強い側面ではありません...
ZFSに関するWebサイト、ブログ、メーリングリストなどがたくさんあります。この質問は、データを取り戻すための健全で構造化され、制御された、情報に基づいた、知識豊富なアプローチに十分な情報を収集し、同じ状況で他の誰かに役立つことを願ってここに投稿します。
「zfs recover」のグーグル検索の最初の検索結果は、 『Solaris ZFS Administration Guide』の「ZFS Troubleshooting and Data Recovery」の章です。最初のZFS障害モードセクションでは、「破損したZFSデータ」段落で次のように述べています。
データの破損は常に永続的であり、修復中に特別な配慮が必要です。基礎となるデバイスが修理または交換されても、元のデータは永久に失われます。
やや落胆。
しかし、2番目のGoogle検索結果はMax Bruningのウェブログであり、そこに、
最近、私は15TBのビデオと音楽を10TB ZFSプールに保存していた人からメールを受け取りましたが、これは停電後に欠陥になりました。彼は残念ながらバックアップを持っていませんでした。彼はFreeBSD 7でZFSバージョン6を使用していました[...]ディスク上のデータを約1週間調べた後、基本的にすべてを復元することができました。
そして
ZFSがあなたのデータを失うことに関しては、私はそれを疑います。私はあなたのデータがそこにあると思うが、あなたはそれに到達する正しい方法を見つける必要がある。
（それは私が聞きたいもののように聞こえます...）
最初のステップ：問題は正確に何ですか？
zpoolが正確に破損していると報告される理由を診断するにはどうすればよいですか？zdbは、WebのどこにもSunやOracleによって公式に文書化されていないようです。そのmanページから：
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日にプラハで開催されたOpen Solaris Developer ConferenceでMax Bruningがそれについて話しているビデオ（およびmdb）があります。
壊れたzpoolでrootとして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では発生しませんが、それ以上の出力もありません...
OK、この段階では、記事が長くなりすぎる前にこれを投稿する方がおそらく良いでしょう。
ここから先に進む方法についてアドバイスをくれたり、応答を待っている間にビデオを見たり、上記のzdb出力の詳細を読んだり、Bensの記事を読んで、何を理解しようとするかもしれません何...
20110806-1600 + 1000
アップデート01：
私は根本原因を見つけたと思います：Max Bruningは私のメールに非常に迅速に応答し、の出力を要求するのに十分親切でしたzdb -lll。プールの半分の「良い」raidz1にある4台のハードドライブのいずれでも、出力は上に掲載したものと同様です。ただし、「壊れた」半分の4つのドライブのうち最初の3 zdbつではfailed to unpack label、ラベル2および3のレポートが表示されます。プール内の4番目のドライブは問題なく、zdbすべてのラベルが表示されます。
このエラーメッセージをグーグルで検索すると、この投稿が表示されます。その投稿への最初の応答から：
ZFSでは、各物理vdev、この場合は単一のハードドライブに4つの同一のラベルがあります。vdevの開始時にL0 / L1、vdevの終了時にL2 / L3。
プール内の8つのドライブはすべて同じモデルであるSeagate Barracuda 500GBです。ただし、4台のドライブでプールを開始した後、そのうち1台が死亡し、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つのドライブのサイズが変更され、2 MB縮小していることがわかります。
[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)
したがって、見た目では、「ブートローダーをドライブの1つに書き込んだ」OSインストールの1つではなく（以前に想定していた）、実際には2 MBのホストを作成する新しいマザーボード（ASUS P8P67 LE）でした ZFSメタデータを台無しにした3つのドライブの最後の保護領域。
すべてのドライブでHPAを作成しなかったのはなぜですか？私は、HPAの作成は唯一のSeagateハードドライブにより、BIOSのアップデートで、後に修正されたバグと古いドライブ上で行われるためであると考えている：この全体の事件が数週間前に始まったとき、私はSeagateの走り版SeaToolsをがあるかどうかをチェックしますドライブの物理的な問題（古いハードウェアでも）があり、一部のドライブでBIOSの更新が必要であるというメッセージが表示されました。現在、そのメッセージの正確な詳細とファームウェアアップデートダウンロードへのリンクを再現しようとしているので、マザーボードがHPAを作成したため、両方のSeaTools DOSバージョンが問題のハードドライブの検出に失敗するinvalid partitionようです。起動時に点滅します、それだけです。皮肉なことに、彼らはサムスン製ドライブのセットを見つけました。
（ネットワークに接続されていないシステムのFreeDOSシェルにねじ込むという、痛みを伴う、時間のかかる、最終的に実りのない詳細はスキップしました。）最後に、SeaTools Windowsを実行するためにWindows 7を別のマシンにインストールしましたバージョン1.2.0.5。DOS SeaToolsについての最後の発言：スタンドアロンで起動しようとしないでください-代わりに、数分を費やして、素晴らしいUltimate Boot CDで起動可能なUSBスティックを作成してください。便利なツール。
SeaTools for Windowsを起動すると、次のダイアログが表示されます。
リンクは、シリアル番号チェッカー（何らかの理由でキャプチャによって保護されています-私の場合は「侵入ユーザー」）とファームウェア更新に関するナレッジベース記事につながります。おそらく、ハードドライブモデルと一部のダウンロードに固有のリンクが他にもありますが、そうでない場合もありますが、現時点ではその道をたどりません。
パーティションが切り詰められ、破損したストレージプールの一部である3つのドライブのファームウェアを一度に更新することはありません。それはトラブルを求めています。手始めに、ファームウェアの更新は元に戻せない可能性が高い-そして、それは私のデータを取り戻すチャンスを取り消すことができなくなる可能性があります。
したがって、次に最初に行うことは、ドライブのイメージを作成し、コピーを操作することです。そのため、何か問題が発生した場合は元に戻す必要があります。ZFSは、同じハードドライブモデルへの正確なddコピーであっても、ドライブが（ドライブのシリアル番号またはさらに別のUUIDなどによって）スワップされていることに気付くため、これにより複雑さが増す可能性があります。さらに、zpoolはライブでもありません。少年、これは難しいかもしれません。
ただし、他のオプションは、オリジナルを使用してミラードライブをバックアップとして保持することですが、オリジナルに問題が発生した場合は、上記の複雑さに遭遇する可能性があります。ああ、良くない。
壊れたプールにバグのあるBIOSを搭載した3台のドライブのイメージの交換品として機能する3台のハードドライブをクリアするには、現在そこにあるもの用のストレージスペースを作成する必要があるので、深く掘り下げますハードウェアボックスを使用して、いくつかの古いドライブから一時的なzpoolを組み立てます。これは、ZFSがdd'dドライブのスワップをどのように処理するかをテストするためにも使用できます。
これにはしばらく時間がかかる場合があります...
20111213-1930 + 1100
アップデート02：
これには確かに時間がかかりました。私は机の上にいくつかの開いたコンピューターケースを置いて数ヶ月を費やし、さまざまな量のハードドライブスタックがぶら下がっていて、耳栓で数晩寝ました。しかし、ついに勝ちました！:-)私もその過程で多くのことを学んだので、同様の状況にある人のためにここでその知識を共有したいと思います。
この記事は、ZFSファイルサーバーが動作していない人が読む時間よりもはるかに長いので、ここで詳細を説明し、以下の重要な調査結果で回答を作成します。
時代遅れのハードウェアボックスを深く掘り下げて、欠陥のあるドライブがミラーリングされた単一の500GBドライブからデータを移動するのに十分なストレージスペースを組み立てました。また、USBケースからいくつかのハードドライブを取り出す必要があったため、SATAを介して直接接続できました。関係のない問題がいくつかあり、古いプールのいくつかは、zpool replaceを必要とする動作に戻したときに失敗し始めましたが、スキップします。
ヒント：ある段階で、合計約30台のハードドライブがこれに関係していました。これだけのハードウェアがあるので、それらを適切にスタックすることは非常に役立ちます。ケーブルが緩んだり、ハードドライブが机から落ちたりしても、確実にプロセスに役立たず、データの整合性がさらに損なわれる可能性があります。
数分かけて、物事を整理するのに本当に役立ついくつかの仮設段ボール製ハードドライブフィクスチャを作成しました。
皮肉なことに、最初に古いドライブを接続したときに、古い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がインストールされていたため、Linuxを起動しました。
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を作成し、それが上位2つの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の人たちは、それをファイルシステムの最後の言葉と呼ぶすべての理由を持っています。尊敬！