しばらく前にZFSプールで作業している間にいくつかの重要なミスを犯し（修正のためのいくつかのオンラインアドバイスを誤って読んだ）、誤ってbackup。 （はい、-f苦情が提起された後にそのオプションを使用しました。今度はそうしないことを知っています。）
とにかく、私は数ヶ月前に偶然に同じプールから3番目のミラードライブを取った。ドライブが古くて失敗し始めるのを待たないようにしたからです。そのため、このドライブを交換してプールを復元するために使用できると思いました。 （私は過去数ヶ月間のバックアップを見逃しましたが、ほとんどがこのプールの用途です。）
しかし、この古いドライブを使用してプールをインポートできないようです。最初は、これがbackup誤って作成された（そして破壊された）新しいプールの名前の衝突と関連している可能性があると思いました。しかし、GUIDを介してインポートしようとしても何も得られません。
これはzdb -l /dev/sdb1の出力です（3番目のドライブ）。
------------------------------------
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コマンドがプールのために扱う2つのディスクです。ただし、sdb1は潜在的なドライブとしてリストされていません。それはおそらく、ディスクを取り外した後にプールから削除したからです。それにもかかわらず、私はsdb1に以前のミラーデータの完全なコピーを持っていると思い、zdbもこれに同意します。なぜ輸入しないのですか？
試してみる他の提案がありますか？別の診断コマンドを実行しますか？
注: 私は試したサーバー障害でこの質問をしてください（私の状況の詳細についてはリンクを参照してください。）しかし、どのフィードバックも得られず、この問題を解決する方法を見つけるために特定のLinux実装が重要である可能性があることに気づきました。どんな意見や提案でも心から感謝します。
修正する:私の考えでは問題を発見したようです。detachコマンドを出す前にスペアドライブを取り外したと思いました。タグ情報（他のオンラインソースが破損したフルメタデータを示すように見える場合）がまだ表示されていることがdetachこれを確認しているようです。私は単にzdb -l backupタグ情報を入力して取得できることがわかりました（そしてget uberblock informationを使用します-u）。だからzfsはデバイスを明示的に指すことなくプールを見ることができるように見えました。何らかの理由でインポートしたくありません。
しかし、もはや状態がわからないdetach。私は偶然偶然発見したこの古いスレッド分離されたミラーからZFSプールを復元する場合は、暗黙的にtxgゼロ値を引用します。スーパーブロックがゼロとして扱われることは他の場所でも言及されていますdetach。
backupさて、私のプールのuberblockはリストを表示しますtxg = 0（他の場所のアクティブなzpoolはそのフィールドにゼロ以外の大きな数を持っています）。既存のスーパーブロックはあるが一つだけあり、残りはbackup「無効」と記載されている。残念ながらzdb、オンラインで文書を見つけるのは簡単ではないようです。
これは、予備の3台目のドライブが取り外されたことを意味すると思いますか？誰でも私の説明を確認できますか？しかし、ドライブデータが破損していない場合に回復する方法はありますか？しかし、インターネット上でいくつかの提案分離されたミラーは再同期なしで復元できないことを示しています。上記のリンクには、タグがuberblockに問題がないと思うように欺く非常に簡単な機能を実行しているように見えるSolarisコードがあります。もっと探索して私を見つけてくださいこのユーティリティの更新されたSolarisバージョンわずか3年前から始まりました。
私の理解が正確で、3番目の画像が分離されていると仮定すると、Linuxで同様のuberblockタグを修正しようとすることはできますか？ Solarisコードを書き換えてLinuxに移植しようとするのは唯一の選択肢ですか？ （私はそれができるかどうかわかりません。）
正直なところ、オンラインでこのシナリオへの多くの参照を考えると、ZFSの合理的なデータ復旧ツールが不足していることに驚きました。そうだ最後に、いくつかのオプションがあります一般的な問題に対する基本的なデータ復旧（コマンドで上書きされたプールを回復する可能性が含まれています。createこの機能は私には適していないようです）が、Solaris用の1回限りのスクリプト以外に処理できるものはありません。デバイスの内容。残念なことに、ZFSプールをインポートできないには、少なくとも12の理由（時々簡単に回復するためのマイナーな理由）があり、トラブルシューティング、正しいエラーコード、または文書がほとんどありません。
もう一度申し上げますが、どんな助け、アイデア、提案でも大変感謝します。 誰でもこの質問ができるより良い場所をお勧めいただきありがとうございます。
アップデート2：offlineデバイスが私が思った場所に配置されている可能性があります。オフラインデバイスも最終的に単一の画像にインポートできない可能性があるというさまざまな記事を読みました。 ZFSのメタデータとzdb出力は正しく文書化されていないため、何千行ものソースコードを読み取らないと、uberblockとタグデータが何を意味するのかを確認する方法がわかりません。
答え1
まあ、ほぼ近くになって回復の道を見つけたようです。まだ他人の意見を聞いたことがないので、今まで学んだ内容を投稿します。
要約：
labelfixインポートできないプールをインポートできるようにするために使用できる、特定の種類の破損した（およびオフライン/分離された）ZFSボリュームのラベルを回復するために、管理されていない非公式にサポートされているユーティリティがあります。- すべての作業を実行する前に、古いスタンバイ・データベースを複製し、複製のみを複製してください。
- 質問に記載されている状況（バグやその他のエラーのため）に同じ名前の2つのプールがある場合は、復元したい特定のプールのデバイスのみが接続されていることを確認
createしてください。 - また、復元しているが失敗したプールに関連付けられている可能性があるすべてのデバイスを削除してください。 （これは、他のプールを完全に破壊し、そのデバイスを切断したと思われる場合にも適用されます。回復ツールは、古いプールの断片を1つに集め、機器とデータを結合しないように古いタグ/スーパーブロックを読み取ることができます。予測方式）。
詳細は：
Linuxのzpoolからオフラインドライブと取り外したドライブを回復する方法があるようです。ユーザーjjwhitneyによって作成されましたlabelfixユーティリティ用のポート私はもともとJeff Bonwick（ZFS発明者）が書いた質問に言及しました。ほぼ12年前。私が理解できない理由から、このユーティリティはまだZFSバージョンに統合されていません。ただし、無効なタグが原因でさまざまな理由でインポートが失敗した場合は、プール全体のデータを回復できます。 (この問題に関するいくつかの議論ここ.)
（注：このプロセスで私が気づいたことの1つは、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。