この章では、ZFS の障害をどのように識別し、そこから回復するかについて説明します。また、障害の発生を防ぐ方法についても説明します。
この章は、次の節で構成されます。
ZFS では、ファイルシステムとボリュームマネージャーが統合されているために、多くの異なる障害が存在します。この章では、さまざまな障害の概要を説明してから、実行しているシステムでそれらをどのように識別するかについて説明します。この章の最後では、問題を修復する方法について説明します。ZFS で発生する可能性がある基本的なエラーには、次の 3 種類があります。
1 つのプールで 3 つのすべてのエラーが発生することもあります。このため、完全な修復作業を行うには、1 つのエラーを検出して訂正したら、次のエラーの対処に進む必要があります。
デバイスがシステムから完全に削除されると、ZFS はそのデバイスを開けないことを検出し、REMOVED 状態にします。この削除が原因でプール全体が使用できない状態になるかどうかは、そのプールのデータ複製レベルによって決まります。ミラー化されたデバイスまたは RAID-Z デバイスにあるディスクが取り外されても、そのプールには引き続きアクセスできます。プールは FAULTED 状態になる可能性があります。この場合、次の条件のもとでは、デバイスが再接続されるまでどのデータにもアクセスできません。
ミラーのすべてのコンポーネントが削除される場合
RAID-Z (raidz1) デバイス内の複数のデバイスが削除される場合
単一ディスク構成で最上位レベルのデバイスが削除される場合
「損傷している」という用語には、発生する可能性のあるさまざまなエラーが含まれます。たとえば、次のようなものがあります。
ディスクまたはコントローラが不良であるために、一時的な入出力エラーが発生する
宇宙線が原因で、ディスク上のデータが破壊される
ドライバのバグが原因で、間違った場所からデータが転送されたり、間違った場所にデータが転送されたりする
ユーザーが誤って物理デバイスの一部を上書きしてしまう
これらのエラーは、ある場合には一時的に発生します。たとえば、コントローラに問題があるときは、入出力が無作為にエラーになります。また、ディスク上の破壊のように、損傷が永続することもあります。ただし、損傷が永続的だからといって、そのエラーが再度発生する可能性が高いことには必ずしもなりません。たとえば、管理者が誤ってディスクの一部を上書きしてしまった場合には、ハードウェア障害のようなことは発生していないので、そのデバイスを置き換える必要はありません。デバイスの問題を正確に識別するのは簡単なことではありません。詳細については、あとで説明します。
データの破壊が発生するのは、1 つ以上のデバイスエラー (1 つ以上のデバイスが見つからないか、損傷している) が最上位レベルの仮想デバイスに影響するときです。たとえば、データは破壊されていないけれども、一方のミラーに大量のデバイスエラーが発生する場合があります。もう一方のミラーの正確に同じ場所にエラーが発生した場合は、データが破壊されたことになります。
データの破壊は常に永続的であり、修復時は特に注意する必要があります。配下のデバイスを修復または置き換えても、元のデータは永久に失われています。このような状況では、ほとんどの場合、バックアップからデータを復元する必要があります。データエラーは発生するたびに記録されます。次の節で説明するように、定期的にプールをスクラブすることでデータエラーを制御できます。破壊されたブロックを削除すると、次のスクラブ処理で破壊が存在しないことが認識され、すべてのエラー追跡がシステムから削除されます。
fsck に相当するユーティリティーは、ZFS には存在しません。このユーティリティーは従来から、ファイルシステムの修復と検証という 2 つの目的に利用されてきました。
従来のファイルシステムのデータ書き込み方法は、本質的に予期しない障害によってファイルシステムの不一致が発生しやすい性質を持っています。従来のファイルシステムはトランザクション方式ではないので、参照されないブロックや不正なリンクカウントなど、ファイルシステム構造の矛盾が発生する可能性があります。ジャーナリングを導入することでこれらの問題のいくつかは解決されますが、ログをロールバックできないときには別の問題が発生する可能性があります。データの不一致が ZFS 構成内のディスク上で発生するとすれば、それはハードウェア障害が発生した場合か、ZFS ソフトウェアにバグが存在する場合だけです。ただし、ハードウェア障害の場合は、プールに冗長性があるはずです。
fsck ユーティリティーは、UFS ファイルシステムに固有の既知の問題を修復します。ZFS ストレージプールの問題の大半は一般に、ハードウェアまたは電源の障害に関連しています。冗長プールを利用することで、多くの問題を回避できます。ハードウェアの障害または電源の停止が原因でプールが損傷している場合は、「ZFS ストレージプール全体の損傷を修復する」を参照してください。
プールに冗長性がない場合は、ファイルシステムの破壊によってデータの一部またはすべてにアクセスできなくなるリスクが常に存在します。
fsck ユーティリティーには、ファイルシステムの修復を実行する以外に、ディスク上のデータに問題がないことを検証する機能があります。この作業では従来から、ファイルシステムのマウントを解除し、fsck ユーティリティーを実行する必要があります。処理中は、多くのシステムでシングルユーザーモードになります。このシナリオで発生するダウンタイムの長さは、チェックするファイルシステムのサイズに比例します。ZFS では、必要なチェックを実行するためのユーティリティーを明示的に使用する代わりに、すべての不一致を定期的にチェックする機構が用意されています。この機能は「スクラブ」と呼ばれ、メモリーやほかのシステム内で、ハードウェアまたはソフトウェア障害が発生する前にエラーを検出および回避する手段として一般的に使用されます。
スクラブを行なっているときまたは必要なファイルにアクセスしているときにエラーが発生した場合には、そのエラーが内部でログに記録されるので、そのプールで認識されているすべてのエラーの概要をすぐに確認できます。
データの完全性をもっとも簡単にチェックする方法は、プールに含まれるすべてのデータのスクラブを明示的に開始することです。この処理では、プールに含まれるすべてのデータを 1 回たどってみて、すべてのブロックが読み取り可能であることを確認します。スクラブは、デバイスが実現できる最大速度で進行します。ただし、入出力が発生する場合には、その優先順位は通常の操作よりも低くなります。この操作によって、パフォーマンスが低下することがあります。ただし、スクラブの実行中でも、プールのデータはそのまま使用することができ、応答時間もほとんど変わらないはずです。明示的なスクラブを開始するには、zpool scrub コマンドを使用します。次に例を示します。
# zpool scrub tank |
現在のスクラブ操作の状態は、zpool status コマンドを使用して表示できます。次に例を示します。
# zpool status -v tank pool: tank state: ONLINE scrub: scrub completed after 0h7m with 0 errors on Tue Tue Feb 2 12:54:00 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c1t0d0 ONLINE 0 0 0 c1t1d0 ONLINE 0 0 0 errors: No known data errors |
一度に実行できるスクラブ操作は、各プールで 1 つだけです。
-s オプションを使用すれば、進行中のスクラブ操作を中止できます。次に例を示します。
# zpool scrub -s tank |
ほとんどの場合、データの完全性を保証するスクラブ操作は、完了するまで続けるようにしてください。操作によってシステム性能に影響が出る場合は、ユーザー自身の判断でスクラブ操作を中止してください。
定期的にスクラブを実行すると、システム上のすべてのディスクへの継続的な入出力が保証されます。定期的なスクラブには、電源管理がアイドル状態のディスクを低電力モードにすることができなくなるという副作用があります。システムによる入出力がほとんど常に実行されている場合や、電力消費を気にする必要がない場合には、この問題は無視しても問題ありません。
zpool status の出力の解釈の詳細については、「ZFS ストレージプールの状態のクエリー検索を行う」を参照してください。
デバイスを置き換えると、再同期化処理が開始されて、正常なコピーのデータが新しいデバイスに移動します。この処理は、ディスクのスクラブの一種です。このため、このような処理をプールで実行できるのは、その時点で 1 つだけです。スクラブ処理の実行中に再同期化を実行すると、進行中のスクラブは中断されて、再同期化の完了後に再開されます。
再同期化の詳細については、「再同期化の状態を表示する」を参照してください。
ここでは、ZFS ファイルシステムまたはストレージプールで発生する問題を識別して解決する方法について説明します。
次の機能を使用して、ZFS 構成で発生した問題を識別することができます。
zpool status コマンドを使用すると、ZFS ストレージプールについての詳細な情報を表示できます。
プールおよびデバイスの障害が ZFS/FMA の診断メッセージで報告されます。
zpool history コマンドを使用すると、プール状態の情報を変更した以前の ZFS コマンドを表示できます。
ZFS のほとんどのトラブルシューティングで、zpool status コマンドを使用します。このコマンドを実行すると、システム上のさまざまな障害が分析され、もっとも重大な問題が識別されます。さらに、推奨する処置と、詳細情報が掲載されたナレッジ記事へのリンクが提示されます。プールで複数の問題が発生している可能性がある場合でも、このコマンドで識別できる問題は 1 つだけです。たとえば、データ破壊のエラーは一般に、いずれかのデバイスで障害が発生したことを示唆しますが、障害が発生したデバイスを置き換えても、データ破壊の問題がすべて解決するとは限りません。
また、ZFS 診断エンジンはプールの障害とデバイスの障害を診断し、報告します。これらの障害に関連するチェックサム、入出力、デバイス、およびプールのエラーも報告されます。fmd で報告される ZFS 障害は、コンソールとシステムメッセージファイルに表示されます。ほとんどの fmd メッセージで、zpool status コマンドを実行して詳細な回復の手順を確認することを求めています。
基本的な回復方法は次のとおりです。
該当する場合、zpool history コマンドを使って、エラーシナリオに至る前に実行された ZFS コマンドを特定します。次に例を示します。
# zpool history tank History for 'tank': 2010-07-15.12:06:50 zpool create tank mirror c0t1d0 c0t2d0 c0t3d0 2010-07-15.12:06:58 zfs create tank/erick 2010-07-15.12:07:01 zfs set checksum=off tank/erick |
この出力では、tank/erick ファイルシステムのチェックサムが無効になっています。この構成はお勧めできません。
システムコンソールまたは /var/adm/messages ファイルに表示される fmd メッセージからエラーを識別します。
zpool status -x コマンドを使って、詳細な修復手順を確認します。
次の手順を実行して、障害を修復します。
障害の発生したデバイスまたは見つからないデバイスを置き換えて、オンラインにします。
障害の発生した構成または破壊されたデータをバックアップから復元します。
zpool status -x コマンドを使用して回復を確認します。
復元した構成のバックアップを作成します (該当する場合)。
この節では、発生する可能性がある障害の種類を診断するために、zpool status の出力を解釈する方法について説明します。ほとんどの作業はコマンドによって自動的に実行されますが、障害を診断するうえで、どのような問題が識別されるかを正確に理解しておくことは重要です。以降の節では、発生する可能性のあるさまざまな問題を修復する方法について説明します。
システムになんらかの既知の問題が存在するかどうかを確認するもっとも簡単な方法は、zpool status -x コマンドを使用することです。このコマンドでは、問題が発生しているプールの説明だけが出力されます。健全性に問題があるプールがシステムに存在しない場合、コマンドは次の出力を表示します。
# zpool status -x all pools are healthy |
-x フラグを指定しないでこのコマンドを実行した場合は、すべてのプールが健全である場合でも、すべてのプール (コマンド行で特定のプールを指定した場合は、要求したプール) のすべての状態が表示されます。
zpool status コマンドのコマンド行オプションの詳細については、「ZFS ストレージプールの状態のクエリー検索を行う」を参照してください。
zpool status の完全な出力は次のようになります。
# zpool status tank # zpool status tank pool: tank state: DEGRADED status: One or more devices could not be opened. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-2Q scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror-0 DEGRADED 0 0 0 c1t0d0 ONLINE 0 0 0 c1t1d0 UNAVAIL 0 0 0 cannot open errors: No known data errors |
この出力の説明を次に示します。
zpool status 出力のこのセクションは、次のフィールドで構成されます。一部の項目は、プールに問題がある場合にのみ表示されます。
プールの名前を示します。
プールの現在の健全性を示します。この情報は、プールが必要な複製レベルを提供できるかどうかだけを示しています。
プールで発生している問題の説明です。エラーが検出されない場合は、このフィールドは省略されます。
エラーを修復するために推奨される処置。エラーが検出されない場合は、このフィールドは省略されます。
詳細な修復情報が掲載されているナレッジ記事を紹介します。オンラインの記事はこのガイドよりも頻繁に更新されます。そのため、最新の修復手順については常にオンラインの記事を参照してください。エラーが検出されない場合は、このフィールドは省略されます。
スクラブ操作の現在の状態が出力されます。前回のスクラブが完了した日付と時刻、進行中のスクラブ、スクラブが要求されていないかどうかなどが出力されます。
既知のデータエラー、または既知のデータエラーが存在しないことが出力されます。
zpool status 出力の config フィールドには、プール内のデバイスの構成、デバイスの状態、およびデバイスから生成されたエラーが出力されます。次のいずれかの状態になる可能性があります。ONLINE、FAULTED、DEGRADED、UNAVAIL、OFFLINE です。ONLINE 以外のいずれかの状態の場合は、プールの耐障害性が危殆化しています。
構成出力の 2 番目のセクションには、エラー統計が表示されます。これらのエラーは、3 つのカテゴリに分けられます。
READ – 読み取り要求を実行したときに発生した入出力エラー
WRITE – 書き込み要求を実行したときに発生した入出力エラー
CKSUM – チェックサムエラー。読み取り要求の結果として、破壊されたデータがデバイスから返されたことを意味する
これらのエラーを使って、損傷が永続的かどうかを判断できます。入出力エラーが少数の場合は、機能が一時的に停止している可能性があります。入出力エラーが大量の場合は、デバイスに永続的な問題が発生している可能性があります。これらのエラーは、アプリケーションによって解釈されるデータ破壊に対応していないことがあります。デバイスが冗長構成になっている場合は、デバイスの訂正できないエラーが表示されることがあります。ただし、ミラーまたは RAID-Z デバイスレベルではエラーは表示されません。そのような場合、ZFS は正常なデータの取得に成功し、既存の複製から損傷したデータの回復を試みたことになります。
これらのエラーを解釈する方法の詳細については、「デバイス障害の種類を確認する」を参照してください。
さらに、zpool status 出力の最終列には、補足情報が表示されます。この情報は、state フィールドの情報を補足するもので、障害の診断に役立ちます。デバイスが FAULTED の場合は、このフィールドにはデバイスがアクセスできない状態かどうか、またはデバイス上のデータが破壊されているかどうかが表示されます。デバイスで再同期化が実行されている場合、このフィールドには現在の進行状況が表示されます。
再同期化の進行状況を監視する方法の詳細については、「再同期化の状態を表示する」を参照してください。
zpool status 出力のスクラブセクションには、すべての明示的なスクラブ操作の現在の状態が説明されます。この情報は、システム上でなんらかのエラーが検出されているかどうかを示すものではありません。ただし、この情報を使って、データ破壊エラーの報告が正確かどうかを判断できます。前回のスクラブが最近実行されている場合には、既知のデータ破壊が発生していれば、高い確率でそのとき検出されている可能性があります。
スクラブ完了メッセージはシステムの再起動後も残ります。
データスクラブおよびこの情報の解釈方法の詳細については、「ZFS ファイルシステムの整合性をチェックする」を参照してください。
zpool status コマンドでは、既知のエラーが発生している場合に、それらがプールに関連するものであるかどうかも出力されます。これらのエラーは、データのスクラブ中または通常の操作中に検出されている可能性があります。ZFS では、プールに関連するすべてのデータエラーの持続的なログを管理しています。システムの完全なスクラブが終了するたびに、このログのローテーションが行われます。
データ破壊エラーは、常に致命的です。このエラーが発生している場合は、プールのデータが破壊されたために、1 つ以上のアプリケーションで入出力エラーが発生したことになります。冗長なプール内でデバイスエラーが発生してもデータは破壊されないので、このログの一部として記録されません。デフォルトでは、検出されたエラーの数だけが表示されます。エラーおよびその詳細の完全なリストは、zpool status -v オプションを使用すれば表示できます。次に例を示します。
# zpool status -v pool: tank state: UNAVAIL status: One or more devices are faulted in response to IO failures. action: Make sure the affected devices are connected, then run 'zpool clear'. see: http://www.sun.com/msg/ZFS-8000-HC scrub: scrub completed after 0h0m with 0 errors on Tue Feb 2 13:08:42 2010 config: NAME STATE READ WRITE CKSUM tank UNAVAIL 0 0 0 insufficient replicas c1t0d0 ONLINE 0 0 0 c1t1d0 UNAVAIL 4 1 0 cannot open errors: Permanent errors have been detected in the following files: /tank/data/aaa /tank/data/bbb /tank/data/ccc |
同様のメッセージは、システムコンソールで fmd を実行した場合にも、また /var/adm/messages ファイルにも表示されます。fmdump コマンドを使って、これらのメッセージを追跡することもできます。
データ破壊エラーの解釈の詳細については、「データ破壊の種類を確認する」を参照してください。
ZFS では、プール内のエラーを継続的に追跡するだけでなく、そのようなイベントが発生したときに syslog メッセージを表示することもできます。次のような場合に、イベントを生成して管理者に通知します。
デバイス状態の移行 – デバイスが FAULTED になると、プールの耐障害性が危殆化する可能性があることを示すメッセージがログに記録されます。あとでデバイスがオンラインになり、プールの健全性が復元した場合にも、同様のメッセージが送信されます。
データの破壊 – データの破壊が検出された場合には、破壊が検出された日時と場所を示すメッセージがログに記録されます。このメッセージがログに記録されるのは、はじめて検出されたときだけです。それ以降のアクセスについては、メッセージは生成されません。
プールの障害とデバイスの障害 – プールの障害またはデバイスの障害が発生した場合には、障害マネージャーデーモンが syslog メッセージおよび fmdump コマンドを使用してこれらのエラーを報告します。
ZFS がデバイスエラーを検出してそれを自動的に回復した場合には、通知は行われません。このようなエラーでは、プールの冗長性またはデータの完全性の障害は発生しません。また、このようなエラーは通常、ドライバの問題が原因で発生しており、ドライバ自身のエラーメッセージも出力されます。
ZFS では、アクティブなプールとその構成のキャッシュをルートファイルシステム上で管理しています。このキャッシュファイルが破壊された場合、またはこのファイルがなんらかの形でディスクに保管されている構成情報と同期しなくなった場合には、そのプールを開くことができなくなります。ZFS ではこのような状況を回避しようとしますが、配下のストレージの特性から、なんらかの破壊は常に発生する可能性があります。こうした状況になると、ほかの方法で使用できるとしても、通常はプールがシステムに表示されなくなります。また、この状況から構成が不完全であること、つまり、最上位レベルの仮想デバイスが見つからない (その数は不明) ことがわかる場合もあります。どちらの場合でも、なんらかの方法でプールを見ることができる場合には、プールをエクスポートして再度インポートする方法で、構成を回復することができます。
プールのインポートとエクスポートについては、「ZFS ストレージプールを移行する」を参照してください。
デバイスを開けない場合には、zpool status の出力に UNAVAIL 状態が表示されます。この状態は、プールにはじめてアクセスしたときにデバイスを開けなかったか、またはそのデバイスがそれ以降使用できない状態であることを示しています。このデバイスが原因で、最上位レベルの仮想デバイスが使用できない場合、そのプールの内容にはアクセスできません。または、プールの耐障害性が危殆化している可能性があります。どちらの場合でも、通常の動作に戻すために必要な操作は、そのデバイスをシステムに再接続することだけです。
たとえば、デバイス障害が発生したあとに、 fmd から次のようなメッセージが表示される場合があります。
SUNW-MSG-ID: ZFS-8000-FD, TYPE: Fault, VER: 1, SEVERITY: Major EVENT-TIME: Thu Jun 24 10:42:36 PDT 2010 PLATFORM: SUNW,Sun-Fire-T200, CSN: -, HOSTNAME: neo2 SOURCE: zfs-diagnosis, REV: 1.0 EVENT-ID: a1fb66d0-cc51-cd14-a835-961c15696fcb DESC: The number of I/O errors associated with a ZFS device exceeded acceptable levels. Refer to http://sun.com/msg/ZFS-8000-FD for more information. AUTO-RESPONSE: The device has been offlined and marked as faulted. An attempt will be made to activate a hot spare if available. IMPACT: Fault tolerance of the pool may be compromised. REC-ACTION: Run 'zpool status -x' and replace the bad device. |
デバイスの問題と解決策についてより詳細な情報を表示するには、zpool status -x コマンドを使用します。次に例を示します。
# zpool status -x pool: tank state: DEGRADED status: One or more devices could not be opened. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-2Q scrub: scrub completed after 0h0m with 0 errors on Tue Feb 2 13:15:20 2010 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror-0 DEGRADED 0 0 0 c1t0d0 ONLINE 0 0 0 c1t1d0 UNAVAIL 0 0 0 cannot open errors: No known data errors |
この出力から、見つからない c1t1d0 デバイスが機能していないことを確認できます。デバイスで障害が発生していると判断した場合は、デバイスを置き換えます。
次に、zpool online コマンドを使用して、置き換えたデバイスをオンラインにします。次に例を示します。
# zpool online tank c1t1d0 |
最後のステップでは、デバイスを置き換えたプールの健全性を確認します。次に例を示します。
# zpool status -x tank pool 'tank' is healthy |
見つからないデバイスを再接続するための正確な手順は、そのデバイスごとに異なります。デバイスがネットワークに接続されているドライブの場合は、ネットワークへの接続を復元するべきです。デバイスが USB デバイスなどのリムーバブルメディアである場合は、システムに再接続するべきです。デバイスがローカルディスクである場合は、コントローラに障害が発生していたために、デバイスがシステムから見えない状態になっていた可能性があります。この場合は、コントローラを置き換えれば、ディスクが再び使用できる状態になるはずです。ハードウェアの種類と構成によっては、ほかの問題が存在する可能性もあります。ドライブに障害が発生してシステムから認識されなくなった場合には、デバイスが損傷していると見なすべきです。「破損したデバイスを交換または修復する」の手順に従ってください。
デバイスをシステムに再接続したあとも、デバイスが使用できるようになったことが自動的に検出されないこともあります。プールでそれまで障害が発生した場合、または接続手続きの一部としてシステムが再起動された場合には、プールを開こうとするときにすべてのデバイスが自動的に再スキャンされます。システムの稼働中にプールの機能が低下したのでデバイスを置き換えた場合には、デバイスが使用できるようになって再度開ける状態になったことを、zpool online コマンドを使って ZFS に通知する必要があります。次に例を示します。
# zpool online tank c0t1d0 |
デバイスをオンラインする方法の詳細については、「デバイスをオンラインにする」を参照してください。
この節では、デバイスの障害の種類を確認し、一時的なエラーを消去し、デバイスを置き換える方法について説明します。
「損傷したデバイス」という用語は定義があいまいですが、発生する可能性のあるいくつかの状況はこの用語で説明できます。
ビットの腐敗 – 時間の経過とともに、磁力の影響や宇宙線などのさまざまなことが原因で、ディスクに格納されているビットが反転してしまうことがあります。このようなことはあまり発生しませんが、発生した場合には、大規模なまたは長期間稼働するシステムでデータが破壊する可能性は十分にあります。
間違った方向への読み取りまたは書き込み – ファームウェアのバグまたはハードウェア障害のために、ブロック全体の読み取りまたは書き込みで、ディスク上の不正な場所を参照してしまうことがあります。これらのエラーは通常、一時的です。ただし、エラーの数が多い場合には、ドライブの障害が発生している可能性があります。
管理者エラー – 管理者が意図せずにディスクの一部を不正なデータで上書きする (ディスクの一部に /dev/zero をコピーするなど) ことで、ディスクが永続的に破壊されてしまう場合があります。これらのエラーは常に一時的です。
一時的な機能停止– ディスクが一定期間使用できなくなり、入出力に失敗することがあります。この状況は通常、ネットワークに接続されたデバイスに発生しますが、ローカルディスクでも一時的に機能が停止することがあります。これらのエラーは、一時的な場合と、そうでない場合があります。
不良または信頼性の低いハードウェア – この状況は、ハードウェアの障害によって引き起こされるさまざまな問題の総称です。問題の例としては、断続的な入出力エラー、不規則な破壊を引き起こす転送エラー、その他のさまざまな障害があります。これらのエラーは通常永続的です。
オフラインのデバイス – デバイスがオフラインである場合は、そのデバイスに障害が発生していると判断した管理者がデバイスをこの状態にしたと推定されます。管理者は、デバイスをこの状態にしたうえで、この推定が正しいかどうかを判断できます。
デバイスのどこに問題があるかを正確に判断することは、難しい作業です。最初に行うことは、zpool status 出力のエラー数を調べることです。次に例を示します。
# zpool status -v tpool pool: tpool state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h0m with 2 errors on Tue Jul 13 11:08:37 2010 config: NAME STATE READ WRITE CKSUM tpool ONLINE 2 0 0 c1t1d0 ONLINE 2 0 0 c1t3d0 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: /tpool/words |
エラーは、入出力エラーとチェックサムエラーに分かれます。どちらのエラーも、発生している可能性のある障害の種類を示している可能性があります。通常の処理で発生するエラーの数は、少ない (長い時間にほんの数個) と予測されます。大量のエラーが表示される場合、この状況はデバイス障害がすぐに発生する可能性または完全なデバイス障害が発生する可能性を示しています。ただし、管理者のミスが原因で大量のエラーが表示される可能性もあります。別の情報源は、syslog システムログです。このログに大量の SCSI ドライバまたはファイバチャネルドライバのメッセージが記録される場合、この状況は重大なハードウェアの問題が発生している可能性を示しています。syslog メッセージが生成されない場合、損傷は一時的であると思われます。
最後の手順は次の質問に答えることです。
このデバイスでもう一度エラーが発生する可能性がありますか。
一度だけ発生するエラーは「一時的」と考えられ、潜在的な障害を示していません。ハードウェア障害の可能性がある持続的または重大なエラーは、「致命的」と考えられます。エラーの種類を特定する作業は、ZFS で現在利用できる自動化ソフトウェアの範囲を超えているため、管理者自身が手動で行う必要があります。エラーの種類を特定したあとで、それに対応する処置を採ることができます。一時的なエラーを解消したり、致命的なエラーが起こっているデバイスを置き換えたります。これらの修復手順については、次の節で説明します。
一時的であると考えられるデバイスエラーでも、それらがプール内のデータの訂正不可能なエラーを発生させていることがあります。このようなエラーについては、配下のデバイスが健全であると判断されている場合、または別の機会に修復されている場合でも、特別な修復手順が必要になります。データエラーの修復の詳細については、「損傷したデータを修復する」を参照してください。
デバイスエラーが一時的と考えられる場合、つまりデバイスの今後の健全性に影響しないと考えられる場合は、デバイスエラーを安全に解消することで、致命的なエラーが発生していないと示すことができます。RAID-Z デバイスまたはミラーデバイスのエラー数を消去するには、zpool clear コマンドを使用します。次に例を示します。
# zpool clear tank c1t1d0 |
この構文を実行すると、すべてのデバイスエラーと、デバイスに関連付けられたすべてのデータエラー数が消去されます。
プール内の仮想デバイスに関連付けられているすべてのエラーを消去し、プールに関連付けられているすべてのデータエラー数を消去するには、次の構文を使用します。
# zpool clear tank |
プールエラーの消去の詳細については、「ストレージプールデバイスのエラーをクリアーする」を参照してください。
デバイスの損傷が永続的である場合、または永続的な損傷が今後発生する可能性がある場合には、そのデバイスを置き換える必要があります。デバイスを置き換えられるかどうかは、構成によって異なります。
デバイスを置き換えるには、プールが ONLINE 状態である必要があります。デバイスは冗長構成の一部であるか、健全 (ONLINE 状態) である必要があります。デバイスが冗長構成の一部である場合は、正常なデータを取得するための十分な複製が存在している必要があります。4 方向ミラーの 2 台のディスク に障害が発生している場合は、健全な複製を入手できるので、どちらのディスクも置き換えることができます。ただし、4 方向 RAID-Z (raidz1) 仮想デバイス内の 2 つのディスクで障害が発生した場合は、データを入手するために必要な複製がないため、どちらのディスクも置き換えることができません。デバイスが損傷していてもオンラインである場合には、プールの状態が FAULTED でない限り、デバイスを置き換えることができます。ただし、損傷を受けたデバイス上の壊れたデータは、正常なデータが格納されている複製が必要な数だけ存在しない場合には、新しいデバイスにコピーされます。
次の構成で、c1t1d0 ディスクは置き換えることができます。プール内のすべてのデータは正常な複製 c1t0d0 からコピーされます。
mirror DEGRADED c1t0d0 ONLINE c1t1d0 FAULTED |
c1t0d0 ディスクも置き換えることができますが、正常な複製を入手できないため、データの自己修復は行われません。
次の構成では、障害が発生したどのディスクも置き換えることができません。プール自体に障害が発生しているため、ONLINE 状態のディスクも置き換えることができません。
raidz FAULTED c1t0d0 ONLINE c2t0d0 FAULTED c3t0d0 FAULTED c4t0d0 ONLINE |
次の構成の最上位レベルのディスクは、どちらも置き換えることができます。ただし、ディスクに不正なデータが存在する場合は、それらが新しいディスクにコピーされます。
c1t0d0 ONLINE c1t1d0 ONLINE |
どちらかのディスクで障害が発生している場合は、プール自体に障害が発生していることになるため、置き換えを実行できません。
デバイスが失われたためにプールが障害状態になった場合、または非冗長な構成でデバイスに大量のデータエラーが含まれている場合は、そのデバイスを安全に置き換えることはできません。十分な冗長性がない場合、損傷したデバイスの修復に使用する正常なデータは存在しません。この場合は、プールを破棄して構成を再作成したのちに、データをバックアップコピーから復元するのが唯一の選択肢です。
プール全体を復元する方法の詳細については、「ZFS ストレージプール全体の損傷を修復する」を参照してください。
置き換えられるデバイスであることを確認したあとで、zpool replace コマンドを使ってデバイスを置き換えます。損傷したデバイスを別のデバイスに置き換える場合は、次のような構文を使用します。
# zpool replace tank c1t1d0 c2t0d0 |
このコマンドを実行すると、損傷したデバイスまたはプール内のほかのデバイス (冗長な構成の場合) から新しいデバイスにデータが移行されます。コマンドが完了すると、損傷したデバイスが構成から切り離され、そのデバイスをシステムから取り外せる状態になります。1 つの場所ですでにデバイスを取り外して新しいデバイスに置き換えている場合には、1 つのデバイス形式のコマンドを使用します。次に例を示します。
# zpool replace tank c1t1d0 |
このコマンドにフォーマットされていないディスクを指定すると、そのディスクが適切な状態にフォーマットされたのち、残りの構成からデータが再同期化されます。
zpool replace コマンドの詳細については、「ストレージプール内のデバイスを置き換える」を参照してください。
次の例では、Oracle の Sun Fire x4500 システム上のミラー化ストレージプール tank 内のデバイス (c1t3d0) を置き換える方法を示します。ディスク c1t3d0 を同じ位置 (c1t3d0) で新しいディスクに置き換えるには、ディスクを置き換える前に構成解除する必要があります。基本的な手順は次のとおりです。
置き換えるディスク (c1t3d0) をオフラインにします。現在使用中のディスクを構成解除することはできません。
cfgadm コマンドを使用して、構成解除するディスク (c1t3d0) を識別し、このディスクを構成解除します。このミラー化構成にオフラインのディスクが存在するプールの機能は低下しますが、プールは引き続き使用可能です。
ディスク (c1t3d0) を物理的に交換します。障害の発生したドライブを物理的に取り外す前に、青色の Ready to Remove (取り外し準備完了) LED が点灯していることを確認してください。
ディスク (c1t3d0) を再構成します。
新しいディスク (c1t3d0) をオンラインにします。
zpool replace コマンドを実行してディスク (c1t3d0) を置き換えます。
あらかじめプールの autoreplace プロパティーをオンに設定してあった場合、そのプールに以前属していたデバイスと物理的に同じ位置に新しいデバイスが検出されると、そのデバイスは自動的にフォーマットされ、zpool replace コマンドを使用せずに置き換えられます。ハードウェアによっては、この機能はサポートされない場合があります。
障害の発生したディスクがホットスペアに自動的に置き換えられる場合は、障害の発生したディスクが置き換えられたあとでホットスペアの切り離しが必要になることがあります。たとえば、障害の発生したディスクが置き換えられたあとも c2t4d0 がアクティブなホットスペアになっている場合は、切り離してください。
# zpool detach tank c2t4d0 |
次の例では、ZFS ストレージプール内のディスクを置き換える手順を示します。
# zpool offline tank c1t3d0 # cfgadm | grep c1t3d0 sata1/3::dsk/c1t3d0 disk connected configured ok # cfgadm -c unconfigure sata1/3 Unconfigure the device at: /devices/pci@0,0/pci1022,7458@2/pci11ab,11ab@1:3 This operation will suspend activity on the SATA device Continue (yes/no)? yes # cfgadm | grep sata1/3 sata1/3 disk connected unconfigured ok <Physically replace the failed disk c1t3d0> # cfgadm -c configure sata1/3 # cfgadm | grep sata1/3 sata1/3::dsk/c1t3d0 disk connected configured ok # zpool online tank c1t3d0 # zpool replace tank c1t3d0 # zpool status tank pool: tank state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:17:32 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c0t1d0 ONLINE 0 0 0 c1t1d0 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 c0t2d0 ONLINE 0 0 0 c1t2d0 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 c0t3d0 ONLINE 0 0 0 c1t3d0 ONLINE 0 0 0 errors: No known data errors |
上記の zpool の出力で、新しいディスクと古いディスクの両方が replacing 見出しの下に表示される場合があります。次に例を示します。
replacing DEGRADED 0 0 0 c1t3d0s0/o FAULTED 0 0 0 c1t3d0 ONLINE 0 0 0 |
このテキストは、置き換え処理および新しいディスクの再同期化が進行中であることを示しています。
ディスク (c1t3d0) を別のディスク (c4t3d0) で置き換える場合は、zpool replace コマンドの実行だけが必要です。次に例を示します。
# zpool replace tank c1t3d0 c4t3d0 # zpool status pool: tank state: DEGRADED scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:35:41 2010 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror-0 ONLINE 0 0 0 c0t1d0 ONLINE 0 0 0 c1t1d0 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 c0t2d0 ONLINE 0 0 0 c1t2d0 ONLINE 0 0 0 mirror-2 DEGRADED 0 0 0 c0t3d0 ONLINE 0 0 0 replacing DEGRADED 0 0 0 c1t3d0 OFFLINE 0 0 0 c4t3d0 ONLINE 0 0 0 errors: No known data errors |
ディスクの置き換えが完了するまでに zpool status コマンドを数回実行する必要がある場合があります。
# zpool status tank pool: tank state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:35:41 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c0t1d0 ONLINE 0 0 0 c1t1d0 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 c0t2d0 ONLINE 0 0 0 c1t2d0 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 c0t3d0 ONLINE 0 0 0 c4t3d0 ONLINE 0 0 0 |
次の例では、ストレージプール pool で障害が発生したログデバイス c0t5d0 を回復する方法を示します。基本的な手順は次のとおりです。
zpool status -x の出力と FMA 診断メッセージを確認します (次のサイトの説明を参照)。
障害が発生したログデバイスを物理的に交換します。
新しいログデバイスをオンラインにします。
プールのエラー状況がクリアされます。
# zpool status -x pool: pool state: FAULTED status: One or more of the intent logs could not be read. Waiting for adminstrator intervention to fix the faulted pool. action: Either restore the affected device(s) and run 'zpool online', or ignore the intent log records by running 'zpool clear'. scrub: none requested config: NAME STATE READ WRITE CKSUM pool FAULTED 0 0 0 bad intent log mirror ONLINE 0 0 0 c0t1d0 ONLINE 0 0 0 c0t4d0 ONLINE 0 0 0 logs FAULTED 0 0 0 bad intent log c0t5d0 UNAVAIL 0 0 0 cannot open <Physically replace the failed log device> # zpool online pool c0t5d0 # zpool clear pool |
# zpool status -x pool: pool state: FAULTED status: One or more of the intent logs could not be read. Waiting for adminstrator intervention to fix the faulted pool. action: Either restore the affected device(s) and run 'zpool online', or ignore the intent log records by running 'zpool clear'. scrub: none requested config: NAME STATE READ WRITE CKSUM pool FAULTED 0 0 0 bad intent log mirror-0 ONLINE 0 0 0 c0t1d0 ONLINE 0 0 0 c0t4d0 ONLINE 0 0 0 logs FAULTED 0 0 0 bad intent log c0t5d0 UNAVAIL 0 0 0 cannot open <Physically replace the failed log device> # zpool online pool c0t5d0 # zpool clear pool |
デバイスを置き換えるときには、デバイスのサイズとプールに含まれるデータの量によっては、かなり長い時間がかかることがあります。あるデバイスのデータを別のデバイスに移動する処理は「再同期化」と呼ばれ、zpool status コマンドを使って監視できます。
従来のファイルシステムでは、ブロックレベルでデータが再同期化されます。ZFS では、ボリュームマネージャーの論理階層がなくなり、より強力な制御された方法で再同期化できます。この機能の主な利点として、次の 2 点を挙げることができます。
ZFS では、最小限の必要なデータ量だけが再同期化されます。デバイスの完全な置き換えとは異なり、短時間の停止の場合は、わずか数分または数秒でディスク全体を再同期化できます。ディスク全体を置き換えるときは、再同期化処理にかかる時間は、ディスク上で使用されているデータ量に比例します。500G バイトのディスクを置き換えるときでも、プールで使用されているディスク容量が数 G バイトであれば、数秒で完了できます。
再同期化は、割り込み可能で安全です。システムの電源が切れるか、またはシステムが再起動した場合には、再同期化処理は中断した場所から正確に再開されます。手動で介入する必要はありません。
再同期化処理を表示するには、zpool status コマンドを使用します。次に例を示します。
# zpool status tank pool: tank state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 0h0m, 22.60% done, 0h1m to go config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror-0 DEGRADED 0 0 0 replacing-0 DEGRADED 0 0 0 c1t0d0 UNAVAIL 0 0 0 cannot open c2t0d0 ONLINE 0 0 0 85.0M resilvered c1t1d0 ONLINE 0 0 0 errors: No known data errors |
この例では、ディスク c1t0d0 が c2t0d0 に置き換わります。状態が replacing の仮想デバイスが構成に存在しているので、このイベントは状態出力で監視されます。このデバイスは実際のデバイスではなく、このデバイスを使ってプールを作成することもできません。このデバイスは、再同期化処理を表示し、置き換え中のデバイスを識別するためだけに使用されます。
再同期化が現在進行しているプールの状態は、すべて ONLINE または DEGRADED 状態になります。これは、再同期化処理が完了するまで、必要とする冗長レベルをそのプールで提供できないためです。システムへの影響を最小限に抑えるために、再同期化は最大限の速度で処理されます。ただし、その入出力の優先順位は、ユーザーが要求した入出力より常に低く設定されます。再同期化が完了すると、新しい完全な構成に戻ります。次に例を示します。
# zpool status tank pool: tank state: ONLINE scrub: resilver completed after 0h1m with 0 errors on Tue Feb 2 13:54:30 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 377M resilvered c1t1d0 ONLINE 0 0 0 errors: No known data errors |
プールは ONLINE に戻り、元の障害が発生したディスク (c1t0d0) は構成から削除されています。
ここでは、データ破壊の種類を確認する方法と、破壊したデータを修復する (可能な場合) 方法について説明します。
ZFS では、データ破壊のリスクを最小限に抑えるために、チェックサム、冗長性、および自己修復データが使用されます。それでも、プールが冗長でない場合、プールの機能が低下しているときに破壊が発生した場合、または予期しないことが一度に起こってデータの複数のコピーが破壊された場合は、データの破壊が発生することがあります。どのような原因であったとしても、結果は同じです。 データが破壊され、その結果アクセスできなくなっています。対処方法は、破壊されたデータの種類とその相対的な価値により異なります。破壊されるデータは、大きく 2 つの種類に分けられます。
プールメタデータ – ZFS では、プールを開いてデータセットにアクセスするために、一定量のデータを解析する必要があります。これらのデータが破壊された場合には、プール全体またはデータセット階層の一部が使用できなくなります。
オブジェクトデータ – この場合、破壊は特定のファイルまたはディレクトリに限定されます。この問題が発生すると、そのファイルまたはディレクトリの一部がアクセスできなくなる可能性があります。この問題が原因で、オブジェクトも一緒に破壊されることがあります。
データの検証は、通常の操作中およびスクラブ時に行われます。プールデータの完全性を検証する方法については、「ZFS ファイルシステムの整合性をチェックする」を参照してください。
デフォルトでは、zpool status コマンドでは、破壊が発生したことだけが報告され、破壊が発生した場所は報告されません。次に例を示します。
# zpool status monkey pool: monkey state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010 config: NAME STATE READ WRITE CKSUM monkey ONLINE 8 0 0 c1t1d0 ONLINE 2 0 0 c2t5d0 ONLINE 6 0 0 errors: 8 data errors, use '-v' for a list |
特定の時刻にエラーが発生したことだけが、エラーごとに報告されます。各エラーが現在もシステムに存在するとは限りません。通常の状況下では、これが当てはまります。なんらかの一時的な機能停止によって、データが破壊されることがあります。それらは、機能停止が終了したあとで自動的に修復されます。プール内のすべてのアクティブなブロックを検査するために、プールのスクラブは完全に実行されることが保証されています。このため、スクラブが完了するたびに、エラーログがリセットされます。エラーが存在しないことを確認したので、スクラブが完了するのを待っている必要がない場合には、zpool online コマンドを使ってプール内のすべてのエラーをリセットします。
データ破壊がプール全体のメタデータで発生している場合は、出力が少し異なります。次に例を示します。
# zpool status -v morpheus pool: morpheus id: 1422736890544688191 state: FAULTED status: The pool metadata is corrupted. action: The pool cannot be imported due to damaged devices or data. see: http://www.sun.com/msg/ZFS-8000-72 config: morpheus FAULTED corrupted data c1t10d0 ONLINE |
プール全体が破壊された場合、プールは必要な冗長レベルを提供できないため、FAULTED 状態になります。
ファイルまたはディレクトリが破壊されても、破壊の種類によってはシステムがそのまま動作する場合があります。データの正常なコピーがシステムに存在しなければ、どの損傷も事実上修復できません。貴重なデータの場合は、影響を受けたデータをバックアップから復元する必要があります。このような場合でも、プール全体を復元しなくても破壊から回復できる場合があります。
ファイルデータブロックの中で損傷が発生した場合は、ファイルを安全に削除することができるため、システムのエラーを解消できます。永続的なエラーが発生しているファイル名のリストを表示するには、zpool status -v コマンドを使用します。次に例を示します。
# zpool status -v pool: monkey state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010 config: NAME STATE READ WRITE CKSUM monkey ONLINE 8 0 0 c1t1d0 ONLINE 2 0 0 c2t5d0 ONLINE 6 0 0 errors: Permanent errors have been detected in the following files: /monkey/a.txt /monkey/bananas/b.txt /monkey/sub/dir/d.txt monkey/ghost/e.txt /monkey/ghost/boo/f.txt |
永続的なエラーが発生しているファイル名のリストは、次のようになります。
ファイルへの完全なパスが見つかり、データセットがマウントされている場合は、ファイルへの完全なパスが表示されます。次に例を示します。
/monkey/a.txt |
ファイルへの完全なパスは見つかったが、データセットがマウントされていない場合は、前にスラッシュ (/) が付かず、後ろにファイルへのデータセット内のパスが付いたデータセット名が表示されます。次に例を示します。
monkey/ghost/e.txt |
エラーにより、または dnode_t の場合のようにオブジェクトに実際のファイルパスが関連付けられていないことにより、ファイルパスに対するオブジェクト番号を正常に変換できない場合は、後ろにオブジェクト番号の付いたデータセット名が表示されます。次に例を示します。
monkey/dnode:<0x0> |
メタオブジェクトセット (MOS) のオブジェクトが破壊された場合は、後ろにオブジェクト番号の付いた <metadata> という特別なタグが表示されます。
ディレクトリまたはファイルのメタデータの中で破壊は発生している場合には、そのファイルを別の場所に移動するしかありません。任意のファイルまたはディレクトリを不便な場所に安全に移動することができ、そこで元のオブジェクトを復元することができます。
プールのメタデータが損傷していて、その損傷によりプールを開けないかインポートできない場合の選択肢には、次のものがあります。
zpool clear - F コマンドまたは zpool import -F コマンドを使用して、プールの回復を試みます。これらのコマンドは、プールに対する直近数回のトランザクションをロールバックして、プールを正常な状態に戻すことを試みます。zpool status コマンドを使用すると、損傷したプールと推奨される回復手順を確認できます。次に例を示します。
# zpool status pool: tpool state: FAULTED status: The pool metadata is corrupted and the pool cannot be opened. action: Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool clear -F tpool'. A scrub of the pool is strongly recommended after recovery. see: http://www.sun.com/msg/ZFS-8000-72 scrub: none requested config: NAME STATE READ WRITE CKSUM tpool FAULTED 0 0 1 corrupted data c1t1d0 ONLINE 0 0 2 c1t3d0 ONLINE 0 0 4 |
これまでに説明した回復プロセスでは、次のコマンドを使用します。
# zpool clear -F tpool |
損傷したストレージプールをインポートしようとすると、次のようなメッセージが表示されます。
# zpool import tpool cannot import 'tpool': I/O error Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool import -F tpool'. A scrub of the pool is strongly recommended after recovery. |
これまでに説明した回復プロセスでは、次のコマンドを使用します。
# zpool import -F tpool Pool tpool returned to its state as of Wed Jul 14 11:44:10 2010. Discarded approximately 5 seconds of transactions |
損傷したプールが zpool.cache ファイルに存在する場合、システムの起動時に問題が検出され、損傷したプールが zpool status コマンドで報告されます。プールが zpool.cache ファイルに存在しない場合、プールをインポートすることも開くこともできず、プールをインポートしようとするとプールの損傷を知らせるメッセージが表示されます。
これまでに説明した回復方法によってプールを回復できない場合は、プールとそのすべてのデータをバックアップコピーから復元する必要があります。そのために使用する方法は、プールの構成とバックアップ方法によって大きく異なります。最初に、zpool status コマンドを使用して表示された構成を保存しておき、プールを破棄したあとで構成を再作成できるようにします。次に、zpool destroy -f コマンドを使用してプールを破棄します。また、データセットのレイアウトやローカルに設定されたさまざまなプロパティーが記述されているファイルを別の安全な場所に保存します。これは、プールがアクセスできない状態になった場合に、これらの情報にアクセスできなくなるためです。プールを破棄したあとに、プールの構成とデータセットのレイアウトを使用して、完全な構成を再構築できます。次に、なんらかのバックアップまたは採用している復元方法を使って、データを生成することができます。
ZFS は、エラーが発生した場合でも、堅牢で安定した状態であるように設計されています。それでも、ソフトウェアのバグや予期しない異常な操作のために、プールにアクセスするときにシステムでパニックが発生することがあります。各プールは起動処理のときに開く必要があるので、このような障害が発生すると、システムがパニックと再起動のループに入ってしまうことになります。この状況から回復するには、起動時にどのプールも探さないように ZFS を設定する必要があります。
ZFS では、利用できるプールとその構成の内部キャッシュを /etc/zfs/zpool.cache で管理しています。このファイルの場所と内容は非公開で、変更される可能性があります。システムを起動できなくなった場合は、-m milestone=none 起動オプションを使用して、マイルストーン none で起動します。システムが起動したら、ルートファイルシステムを書き込み可能として再マウントしてから、/etc/zfs/zpool.cache ファイルの名前を変更するかこのファイルを別の場所に移動します。これらの操作によって、システムに存在するすべてのプールがキャッシュから消去されるので、問題の原因となっている正常でないプールにアクセスしようとしなくなります。この状態になったら、svcadm milestone all コマンドを実行して、通常のシステムの状態に戻ることができます。代替ルートから起動して修復を行う場合にも、同じような工程を使用できます。
システムが起動したあとで、zpool import コマンドを使ってプールをインポートしてみることができます。ただし、このコマンドを実行すると、起動で発生したエラーと同じエラーが発生する可能性があります。これは、プールにアクセスするときに起動時と同じ方法が使用されているためです。複数のプールがシステムに存在する場合は、次の手順を実行します。
すでに説明したように、zpool.cache ファイルの名前を変更するか、このファイルを別の場所に移動します。
どのプールに問題が発生している可能性があるかを調べるために、致命的エラーが報告されているプールを fmdump -eV コマンドで表示します。
fmdump の出力に示された問題のあるプールを除き、プールを 1 つずつインポートします。