FreeBSD上のZFS：データ破損からの回復
Zpoolに数TBの非常に貴重な個人データがあり、データが破損しているためアクセスできません。このプールはもともと、2009年頃に、Ubuntu 8.04システム上のVMWare仮想マシン内で実行されているFreeBSD 7.2システムにセットアップされました。 FreeBSD VMは引き続き利用可能で正常に動作しています。ホストOSのみがDebian 6に変更されました。ゲストはハードドライブにアクセスできますVM VMWare汎用SCSIデバイスの手段、合計12。
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 \
[email protected]:/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管理ガイドの ZFSトラブルシューティングとデータ復旧/ の章です。最初の ZFS障害モード セクションでは、「破損したZFSデータ」段落に次のように記載されています。
データの破損は常に永続的であり、修復中に特別な考慮が必要です。基盤となるデバイスが修理または交換された場合でも、元のデータは永久に失われます。
やや落胆。
しかし、2番目のgoogle検索結果は Max Bruningのウェブログ であり、そこでは、
最近、停電後に故障した15 TBのビデオと音楽を10 TBのZFSプールに保存していた人からメールが送られてきました。残念ながら彼にはバックアップがありませんでした。彼はFreeBSD 7でZFSバージョン6を使用していました[...]ディスク上のデータを調査するのに約1週間を費やした後、基本的にすべてを復元することができました。
そして
ZFSがあなたのデータを失うことについては、私はそれを疑います。あなたのデータはそこにあると思いますが、それを取得する正しい方法を見つける必要があります。
（それは私が聞きたいもののように聞こえます...）
最初のステップ：問題は正確に何ですか？
Zpoolが破損していると正確に報告されている理由を診断するにはどうすればよいですか？ SunやOracleによって公式に文書化されていないように見えるzdbがWebのどこにもあるようです。その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が detailed article を投稿し、Max Bruningの video がそれについて話しています（そしてmdb）は、2008年6月28日にプラハで開催されるOpen Solaris Developer Conferenceで開催されました。
壊れた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では発生しませんが、それ以上の出力はないようです...
わかりました、この段階では、記事が長くなりすぎる前にこれを投稿することをお勧めします。
多分誰かがここから先に進む方法についていくつかのアドバイスをくれるかもしれません、そして私が応答を待っている間に、私はビデオを見て、上のzdb出力の詳細を調べ、Bensの記事を読んで何が何であるかを理解しようとします何...
20110806-1600 + 1000
アップデート01：
私は根本的な原因を見つけたと思います：Max Bruningは、私のメールにzdb -lllの出力を求める非常に迅速に応答してくれました。プールの「良い」raidz1半分にある4つのハードドライブのいずれでも、出力は上記で投稿したものと同様です。ただし、「壊れた」半分の4つのドライブの最初の3つでは、zdbはラベル2および3に対してfailed to unpack labelを報告します。プール内の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つではなく（以前に想定したとおり）、実際には新しいマザーボード（ ）でした。 ASUS P8P67 LE ）ZFSメタデータをめちゃくちゃにした3つのドライブの最後に2 MB ホスト保護領域 を作成します。
すべてのドライブに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スティックを作成してください。 /-DOS SeaToolsとは別に、他にも多くの便利なツールがたくさんあります。
起動すると、SeaTools for Windowsは次のダイアログを表示します。
リンクは、 シリアル番号チェッカー （何らかの理由でキャプチャによって保護されています-私は「侵略的なユーザー」でした）と につながります/ファームウェアの更新について/ knowledge base article おそらく、ハードドライブモデルと一部のダウンロードに固有のリンクが他にもあり、そうでないものもありますが、今のところそのパスをたどることはしません。
パーティションが切り捨てられ、壊れたストレージプールの一部である3つのドライブのファームウェアを一度に更新することはしません。それは問題を求めています。手始めに、ファームウェアの更新は元に戻せない可能性が最も高い-そしてそれは私のデータを取り戻す私のチャンスを取り返しのつかないほど台無しにするかもしれない。
したがって、次に最初に行うのは、ドライブのイメージを作成してコピーを操作することです。そのため、何か問題が発生した場合に元に戻すオリジナルがあります。同じハードドライブモデルへの完全なddコピーであるにもかかわらず、ZFSはおそらくドライブが（ドライブのシリアル番号または別のUUIDなどによって）スワップされたことに気付くため、これはさらに複雑になる可能性があります。さらに、zpoolは生きていません。少年、これはトリッキーになるかもしれません。
ただし、もう1つのオプションは、元のファイルを使用してミラードライブをバックアップとして保持することですが、元のファイルに問題が発生した場合は、おそらく上記の複雑さに遭遇します。いや、良くない。
壊れたプール内のバグのあるBIOSで3つのドライブのイメージ化された代替品として機能する3つのハードドライブをクリアするために、現在そこにあるもののためにいくつかのストレージスペースを作成する必要があるので、深く掘り下げますハードウェアボックスと、古いドライブから一時的なzpoolをアセンブルします。これを使用して、dd'dドライブのスワッピングをZFSがどのように処理するかをテストすることもできます。
しばらく時間がかかる場合があります...
20111213-1930 + 1100
アップデート02：
これには確かに少し時間がかかりました。机にいくつかの開いたコンピューターケースを置いて数か月を過ごしました。さまざまな量のハードドライブスタックがぶら下がっていて、耳栓で数晩眠りました。それは、長時間の重要な操作を実行していたため、寝る前にマシンをシャットダウンできなかったためです。 。しかし、ついに勝ちました！ :-)私はその過程で多くのことを学びました、そして私は同じような状況にいる人のためにここでその知識を共有したいと思います。
この記事は、ZFSファイルサーバーが動作していない人が読む時間よりもはるかに長いため、ここで詳細を説明し、以下の重要な調査結果を含む回答を作成します。
私は古いハードウェアボックスを深く掘り下げて、欠陥のあるドライブがミラーリングされた単一の500 GBドライブからものを移動するのに十分なストレージスペースを組み立てました。また、USBケースから数台のハードドライブを取り除いて、SATA経由で直接接続できるようにする必要がありました。さらに関連のない問題があり、古いドライブの一部がzpool replaceを必要とする動作に戻したときに失敗し始めましたが、スキップします。
ヒント：ある段階で、これには合計で約30台のハードドライブが関係していました。これだけ多くのハードウェアがあるため、それらを適切にスタックさせることは非常に役立ちます。ケーブルが外れたり、ハードドライブが机から落ちたりしても、このプロセスでは確実に役に立たず、データの整合性がさらに損なわれる可能性があります。
私は数分かけて、シフトの段ボールのハードドライブフィクスチャをいくつか作成しました。
皮肉なことに、古いドライブを初めて接続したときに、古いzpoolがそこにあることに気づきました。一部の古いバージョンを使用してテスト用に作成する必要がありますが、失われた個人データのすべてではないため、データ損失は多少減少しましたが、これはファイルの前後への追加のシフトを意味しました。
最後に、問題のあるドライブをバックアップドライブにミラーリングし、zpoolのドライブを使用して、元のドライブを切断したままにしました。バックアップドライブのファームウェアは最新です。少なくともSeaToolsは必要なファームウェアアップデートを報告しません。 1つのデバイスから別のデバイスへの単純なddを使用してミラーリングを行いました。
Sudo dd if=/dev/sda of=/dev/sde
ZFSはハードウェアの変更（ハードドライブのUUIDなど）に気づいていると思いますが、気にしていないようです。
ただし、zpoolは同じ状態で、レプリカが不十分でデータが破損しています。
前述の HPAウィキペディアの記事 で述べたように、ホスト保護領域の存在は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のステータスが作業プールを再度報告しました。わーい！ :-)
仮想システムにプールをエクスポートし、Host 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の人たちは、それをファイルシステムの最後のWordと呼ぶすべての理由があります。尊敬！
問題は、新しいマザーボードのBIOSが一部のドライブ上にホスト保護領域（HPA）を作成することでした。これは、OEMがシステム回復の目的で使用する小さなセクションで、通常はハードドライブの最後にあります。
ZFSは、パーティションメタ情報を含む4つのラベルを保持し、HPAはZFSが上位2つを見るのを防ぎます。
解決策：Linuxを起動し、hdparmを使用してHPAを検査して削除します。非常に注意してください。これにより、データが完全に破壊される可能性があります。詳細については、記事とhdparmのマニュアルページ（パラメーター-N）を参照してください。
問題は新しいマザーボードで発生しただけでなく、ドライブをSASコントローラカードに接続したときにも同様の問題がありました。解決策は同じです。
私が最初に行うことをお勧めするのは、いくつかのハードドライブを取得し、ddコマンドを使用して、データが保存されている8つのドライブのコピーを複製することです。そのようにして、それらを回復しようとする試みで事態が悪化した場合でも、このベースラインに戻ることができます。
私は以前にこれを行ったことがあり、それを必要としない時もありましたが、私がdid必要とする時は、それを完全に努力する価値がありました。
ネットなしで作業しないでください。
あなたはこれを解決することに順調に進んでいるようです。別の可能な新しい視点が必要な場合は、Solaris 11 ExpressライブCDを試すことができます。そこには多くの新しいコードが実行されており（Solarisのzpoolはバージョン31ですが、バージョン6になっています）、回復の可能性が高まる可能性があります。実行しないzpool upgradeただし、Solarisの場合、プールをFreeBSDでマウント可能な状態に保ちたい場合。
FreeBSD 10.3から11.1にアップグレードした後、同様の問題が発生しました。その後、zdb -lllが4つのラベルすべてを有効に戻しても、zpoolに障害が発生し、データを回復する方法がありませんでした。
どういうわけか、アップデートによってIntelストレージ管理ドライバーがディスクからソフトレイドミラーを作成するようになり（おそらく有効になりましたが、更新後までgeomのIntelプロバイダーによってサポートされていませんでした）、ZFSがディスクをマウントします。
それらをIntel RST起動時ファームウェアが有効になっている別のPCに接続し、softraidを無効にする（非常に重要：2つの方法がありますソフトレイドを解除するには、デフォルトでディスクを初期化（別名：フォーマット！）します。代わりに、データに触れずに無効にするオプションを選択する必要があります）次に、ZFSにミラーの最初のディスクを認識させます。残りのディスクがマシンの更新前のものと同じであることを識別するため。幸い、それはミラーリングされたzpoolであり、問題のプールにディスクを接続解除して再接続するだけで、復元はイベントなしで完了しました。
補足：私の場合、hdparm（ライブのUbuntu Server ISOから実行）は、すべてのディスクでHBAが無効になっていて、支援できないと報告しました。
FreeBSDメーリングリストは、検索の出発点として適しています。 FreeBSD-Stableと-Currentで同様のリクエストが行われるのを見たことを覚えています。データの重要性によっては、アクセスできないデータストレージプールを改ざんすると事態が悪化する可能性が高いため、専門の復旧会社に連絡することをお勧めします。