データに関する問題の例には次のものがあります。
プールまたはファイルシステム領域が見つからない
ディスクまたはコントローラが不良であるために、一時的な入出力エラーが発生する
宇宙線が原因で、ディスク上のデータが破壊される
ドライバのバグが原因で、間違った場所からデータが転送されたり、間違った場所にデータが転送されたりする
ユーザーが誤って物理デバイスの一部を上書きしてしまう
これらのエラーは、ある場合には一時的に発生します。たとえば、コントローラに問題があるときは、入出力が無作為にエラーになります。また、ディスク上の破壊のように、損傷が永続することもあります。ただし、損傷が永続的だからといって、そのエラーが再度発生する可能性が高いことには必ずしもなりません。たとえば、誤ってディスクの一部を上書きしてしまった場合には、ハードウェア障害のようなことは発生していないので、そのデバイスを置き換える必要はありません。デバイスの問題を正確に識別するのは簡単なことではありません。詳細については、あとのセクションで説明します。
ZFS がファイルシステム領域とプール領域の計上をどのように報告するかわからない場合は、次のセクションを確認してください。
利用可能なプールおよびファイルシステムの領域を判別する場合、zpool list および zfs list コマンドは、以前の df および du コマンドより優れています。旧バージョンのコマンドでは、プールおよびファイルシステムの領域を簡単に識別できず、下位のファイルシステムまたはスナップショットによって消費される領域の詳細を表示できません。
たとえば、次のルートプール (rpool) は、5.46GB が割り当て済みで、68.5GB は空き領域です。
# zpool list rpool NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT rpool 74G 5.46G 68.5G 7% 1.00x ONLINE -
個々のファイルシステムの USED 列を確認することでプール領域の数値とファイルシステム領域の数値を比較すれば、ALLOC で報告されるプール領域はファイルシステムの USED の合計であることがわかります。例:
# zfs list -r rpool NAME USED AVAIL REFER MOUNTPOINT rpool 5.41G 67.4G 74.5K /rpool rpool/ROOT 3.37G 67.4G 31K legacy rpool/ROOT/solaris 3.37G 67.4G 3.07G / rpool/ROOT/solaris/var 302M 67.4G 214M /var rpool/dump 1.01G 67.5G 1000M - rpool/export 97.5K 67.4G 32K /rpool/export rpool/export/home 65.5K 67.4G 32K /rpool/export/home rpool/export/home/admin 33.5K 67.4G 33.5K /rpool/export/home/admin rpool/swap 1.03G 67.5G 1.00G -
zpool list コマンドによって報告される SIZE 値は、通常、プール内の物理ディスク領域の大きさですが、プールの冗長性レベルに応じて異なります。次の例を参照してください。zfs list コマンドは、使用可能な領域のうち、ファイルシステムで利用できる領域を示します。これは、ディスク領域から ZFS プール冗長性メタデータオーバーヘッド (ある場合) を差し引いたものです。
次の ZFS データセット構成は、zfs list コマンドでは割り当てられた領域として追跡されますが、zpool list の出力では割り当てられた領域として追跡されません。
ZFS ファイルシステム割り当て制限
ZFS ファイルシステム予約
ZFS 論理ボリュームサイズ
次の各項目では、さまざまなプール構成、ZFS ボリューム、および ZFS 予約の使用が、消費されたディスク容量や使用可能なディスク容量にどのように影響する場合があるかについて説明します。構成に応じて、下に示されている手順を使用してプール領域のモニタリングを追跡するようにしてください。
非冗長性ストレージプール – 136G バイトのディスク 1 つでプールを作成すると、zpool list コマンドによって SIZE および初期 FREE 値が 136G バイトとして報告されます。zfs list コマンドによって報告された初期 AVAIL 領域は、プールメタデータオーバーヘッドが少量あるため 134G バイトです。例:
# zpool create system1 c0t6d0 # zpool list system1 NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT system1 136G 95.5K 136G 0% 1.00x ONLINE - # zfs list system1 NAME USED AVAIL REFER MOUNTPOINT system1 72K 134G 21K /system1
ミラー化ストレージプール – 136G バイトのディスク 2 つでプールを作成すると、zpool list コマンドによって SIZE が 136G バイト、初期 FREE 値が 136G バイトとして報告されます。この報告は、デフレートされた領域値と呼ばれます。zfs list コマンドによって報告された初期 AVAIL 領域は、プールメタデータオーバーヘッドが少量あるため 134G バイトです。例:
# zpool create system1 mirror c0t6d0 c0t7d0 # zpool list system1 NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT system1 136G 95.5K 136G 0% 1.00x ONLINE - # zfs list system1 NAME USED AVAIL REFER MOUNTPOINT system1 72K 134G 21K /system1
RAID-Z ストレージプール – 136G バイトのディスク 3 つで raidz2 プールを作成すると、zpool list コマンドによって SIZE および初期 FREE 値が 408G バイトとして報告されます。この報告は、インフレートされたディスク領域値と呼ばれます。パリティー情報などの冗長性オーバーヘッドが含まれています。zfs list コマンドによって報告される初期 AVAIL 領域は、プール冗長性オーバーヘッドのため 133G バイトです。RAID-Z プールに関する zpool list および zfs list の出力間で領域に違いがあるのは、zpool list によってインフレートされたプール領域が報告されたためです。
# zpool create system1 raidz2 c0t6d0 c0t7d0 c0t8d0 # zpool list system1 NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT system1 408G 286K 408G 0% 1.00x ONLINE - # zfs list system1 NAME USED AVAIL REFER MOUNTPOINT system1 73.2K 133G 20.9K /system1
NFS マウントされたファイルシステム領域 – zpool list も zfs list も、NFS マウントされたファイルシステム領域を考慮しません。ただし、ローカルデータファイルは、マウントされた NFS ファイルシステムの下で非表示になっている可能性があります。ファイルシステム領域が見つからない場合は、NFS ファイルシステムの下でデータファイルが非表示になっていないか確認してください。
ZFS ボリュームの使用 – ZFS ファイルシステムが作成され、プール領域が消費された場合は、zpool list コマンドを使用してファイルシステムの容量消費を表示できます。例:
# zpool create nova mirror c1t1d0 c2t1d0 # zfs create nova/fs1 # mkfile 10g /nova/fs1/file1_10g # zpool list nova NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT nova 68G 10.0G 58.0G 14% 1.00x ONLINE - # zfs list -r nova NAME USED AVAIL REFER MOUNTPOINT nova 10.0G 56.9G 32K /nova nova/fs1 10.0G 56.9G 10.0G /nova/fs1
10G バイトの ZFS ボリュームを作成した場合、この容量は zpool list コマンドの出力に含まれません。この容量は、zfs list コマンドの出力に含まれます。ストレージプール内の ZFS ボリュームを使用している場合は、zfs list コマンドを使用して ZFS ボリュームの容量消費をモニターします。例:
# zfs create -V 10g nova/vol1 # zpool list nova NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT nova 68G 10.0G 58.0G 14% 1.00x ONLINE - # zfs list -r nova NAME USED AVAIL REFER MOUNTPOINT nova 20.3G 46.6G 32K /nova nova/fs1 10.0G 46.6G 10.0G /nova/fs1 nova/vol1 10.3G 56.9G 16K -
上の出力で、ZFS ボリュームの容量は zpool list の出力では追跡されません。そのため、ZFS ボリュームによって消費された容量を識別するには zfs list または zfs list -o space コマンドを使用します。
さらに、ZFS ボリュームは raw デバイスのように機能するため、メタデータのための一定の容量が refreservation プロパティーによって自動的に予約されます。これにより、ボリュームでは、そのボリュームが作成されたときに指定された量より少し多い容量が消費されます。ZFS ボリューム上の refreservation を削除しないでください。削除すると、ボリューム容量が不足するおそれがあります。
ZFS 予約の使用 – 予約を使用してファイルシステムを作成するか、または既存のファイルシステムに予約を追加した場合、予約または refreservation は zpool list コマンドによって追跡されません。
zfs list -r コマンドを使用して、増加した USED 容量を識別することにより、ファイルシステムの予約によって消費された容量を識別します。例:
# zfs create -o reservation=10g nova/fs2 # zpool list nova NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT nova 68G 10.0G 58.0G 14% 1.00x ONLINE - # zfs list -r nova NAME USED AVAIL REFER MOUNTPOINT nova 30.3G 36.6G 33K /nova nova/fs1 10.0G 36.6G 10.0G /nova/fs1 nova/fs2 31K 46.6G 31K /nova/fs2 nova/vol1 10.3G 46.9G 16K -
refreservation を使用してファイルシステムを作成した場合、その refreservation は zfs list -r コマンドを使用して識別できます。例:
# zfs create -o refreservation=10g nova/fs3 # zfs list -r nova NAME USED AVAIL REFER MOUNTPOINT nova 40.3G 26.6G 35K /nova nova/fs1 10.0G 26.6G 10.0G /nova/fs1 nova/fs2 31K 36.6G 31K /nova/fs2 nova/fs3 10G 36.6G 31K /nova/fs3 nova/vol1 10.3G 36.9G 16K -
USED 容量の合計に含まれる既存のすべての予約を識別するには、次のコマンドを使用します。
# zfs get -r reserv,refreserv nova NAME PROPERTY VALUE SOURCE nova reservation none default nova refreservation none default nova/fs1 reservation none default nova/fs1 refreservation none default nova/fs2 reservation 10G local nova/fs2 refreservation none default nova/fs3 reservation none default nova/fs3 refreservation 10G local nova/vol1 reservation none default nova/vol1 refreservation 10.3G local
fsck に相当するユーティリティーは、ZFS には存在しません。このユーティリティーは従来から、ファイルシステムの修復と検証という 2 つの目的に利用されてきました。
従来のファイルシステムのデータ書き込み方法は、本質的に予期しない障害によってファイルシステムの不一致が発生しやすい性質を持っています。従来のファイルシステムはトランザクション方式ではないので、参照されないブロックや不正なリンクカウントなど、ファイルシステム構造の矛盾が発生する可能性があります。ジャーナリングを導入することでこれらの問題のいくつかは解決されますが、ログをロールバックできないときには別の問題が発生する可能性があります。整合性のないデータが ZFS 構成内のディスク上に存在するようになるのは、ハードウェアに障害がある場合 (この場合、プールは冗長であったはずです) または ZFS ソフトウェアにバグが存在する場合のみです。
fsck ユーティリティーは、UFS ファイルシステムに固有の既知の問題を修復します。ZFS ストレージプールの問題の大半は一般に、ハードウェアまたは電源の障害に関連しています。冗長プールを利用することで、多くの問題を回避できます。ハードウェアの障害または電源の停止が原因でプールが損傷している場合は、ZFS ストレージプール全体の損傷を修復するを参照してください。
プールに冗長性がない場合は、ファイルシステムの破壊によってデータの一部またはすべてにアクセスできなくなるリスクが常に存在します。
fsck ユーティリティーには、ファイルシステムの修復を実行する以外に、ディスク上のデータに問題がないことを検証する機能があります。このタスクでは従来から、ファイルシステムをアンマウントし、fsck ユーティリティーを実行する必要があります。処理中は、多くのシステムでシングルユーザーモードになります。このシナリオで発生するダウンタイムの長さは、チェックするファイルシステムのサイズに比例します。ZFS では、必要なチェックを実行するためのユーティリティーを明示的に使用する代わりに、すべての不一致を定期的にチェックするメカニズムが用意されています。スクラブとして知られているこの機能は、ハードウェアまたはソフトウェアの障害に進む前にエラーを検出および防止する方法として、一般にメモリーおよびほかのシステム内で使用されます。
スクラブを行なっているときまたは必要なファイルにアクセスしているときにエラーが発生した場合には、そのエラーが内部でログに記録されるので、そのプールで認識されているすべてのエラーの概要をすぐに確認できます。
データの完全性をもっとも簡単にチェックする方法は、プールに含まれるすべてのデータのスクラブを明示的に開始することです。この処理では、プールに含まれるすべてのデータを 1 回たどってみて、すべてのブロックが読み取り可能であることを確認します。スクラブは、デバイスが実現できる最大速度で進行します。ただし、入出力が発生する場合には、その優先順位は通常の操作よりも低くなります。この操作によって、パフォーマンスが低下することがあります。ただし、スクラブの実行中でも、プールのデータはそのまま使用することができ、応答時間もほとんど変わらないはずです。明示的なスクラブを開始するには、zpool scrub コマンドを使用します。例:
# zpool scrub system1
現在のスクラブ操作のステータスは、zpool status コマンドを使用して表示できます。例:
# zpool status -v system1
pool: system1
state: ONLINE
scan: scrub in progress since Mon Jun 7 12:07:52 2010
201M scanned out of 222M at 9.55M/s, 0h0m to go
0 repaired, 90.44% done
config:
NAME STATE READ WRITE CKSUM
system1 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 system1
ほとんどの場合、データの完全性を保証するスクラブ操作は、完了するまで続けるようにしてください。操作によってシステム性能に影響が出る場合は、ユーザー自身の判断でスクラブ操作を中止してください。
定期的にスクラブを実行すると、システム上のすべてのディスクへの継続的な入出力が保証されます。定期的なスクラブには、電源管理がアイドル状態のディスクを低電力モードにすることができなくなるという副作用があります。システムによる入出力がほとんど常に実行されている場合や、電力消費を気にする必要がない場合には、この問題は無視しても問題ありません。システムの大部分がアイドル状態で、ディスクへの電力を節約する場合は、バックグラウンドスクラブではなく、cron スケジュールされた明示的なスクラブを使用することを検討する必要があります。この場合もデータの完全なスクラブが実行されます。ただし、大量の I/O が生成されるのはスクラブが終了するまでで、終了時点でディスクを通常どおり電源管理できるようになります。(I/O の増加以外の) 欠点は、スクラブがまったく行われていない時間が大きくなり、その時間内に破損のリスクが増える可能性があることです。
zpool status の出力の解釈の詳細については、ZFS ストレージプールのステータスのクエリー検索を行うを参照してください。
デバイスを置き換えると、再同期化処理が開始されて、正常なコピーのデータが新しいデバイスに移動します。この処理は、ディスクのスクラブの一種です。このため、このような処理をプールで実行できるのは、その時点で 1 つだけです。スクラブ操作の実行中に再同期化を実行すると、現在のスクラブは中断され、再同期化の完了後に再開されます。
再同期化の詳細については、再同期化のステータスを表示するを参照してください。
データの破壊が発生するのは、1 つ以上のデバイスエラー (1 つ以上のデバイスが見つからないか、損傷している) が最上位レベルの仮想デバイスに影響するときです。たとえば、データは破壊されていないけれども、一方のミラーに大量のデバイスエラーが発生する場合があります。もう一方のミラーの正確に同じ場所にエラーが発生した場合は、データが破壊されたことになります。
データの破壊は常に永続的であり、修復時は特に注意する必要があります。配下のデバイスを修復または置き換えても、元のデータは永久に失われています。このような状況では、ほとんどの場合、バックアップからデータを復元する必要があります。データエラーは発生するたびに記録されます。次のセクションで説明するように、定期的にプールをスクラブすることでデータエラーを制御できます。破壊されたブロックを削除すると、次のスクラブ処理で破壊が存在しないことが認識され、すべてのエラー追跡がシステムから削除されます。
次のセクションでは、データ破壊の種類を確認する方法と、破壊したデータを修復する (可能な場合) 方法について説明します。
ZFS では、データ破壊のリスクを最小限に抑えるために、チェックサム、冗長性、および自己修復データが使用されます。それでも、プールが冗長でない場合、プールの機能が低下しているときに破壊が発生した場合、または予期しないことが一度に起こってデータの複数のコピーが破壊された場合は、データの破壊が発生することがあります。どのような原因であったとしても、結果は同じです。 データが破壊され、その結果アクセスできなくなっています。対処方法は、破壊されたデータの種類とその相対的な価値により異なります。破壊されるデータは、大きく 2 つの種類に分けられます。
プールメタデータ – ZFS では、プールを開いてデータセットにアクセスするために、一定量のデータを解析する必要があります。これらのデータが破壊された場合には、プール全体またはデータセット階層の一部が使用できなくなります。
オブジェクトデータ – この場合、破壊は特定のファイルまたはディレクトリに限定されます。この問題が発生すると、そのファイルまたはディレクトリの一部がアクセスできなくなる可能性があります。この問題が原因で、オブジェクトも一緒に破壊されることがあります。
データの検証は、通常の操作中およびスクラブ時に行われます。プールデータの完全性を検証する方法については、ZFS ファイルシステムの整合性をチェックするを参照してください。
デフォルトでは、zpool status コマンドでは、破壊が発生したことだけが報告され、破壊が発生した場所は報告されません。例:
# zpool status system1
pool: system1
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://support.oracle.com/msg/ZFS-8000-8A
config:
NAME STATE READ WRITE CKSUM
system1 ONLINE 4 0 0
c0t5000C500335E106Bd0 ONLINE 0 0 0
c0t5000C500335FC3E7d0 ONLINE 4 0 0
errors: 2 data errors, use '-v' for a list
特定の時間にエラーが発生したことだけが、エラーごとに報告されます。各エラーが現在もシステムに存在するとは限りません。通常の状況下では、これが当てはまります。なんらかの一時的な機能停止によって、データが破壊されることがあります。それらは、機能停止が終了したあとで自動的に修復されます。プール内のすべてのアクティブなブロックを検査するために、プールのスクラブは完全に実行されることが保証されています。このため、スクラブが完了するたびに、エラーログがリセットされます。エラーが存在しないことを確認したので、スクラブが完了するのを待っている必要がない場合には、zpool online コマンドを使ってプール内のすべてのエラーをリセットします。
データ破壊がプール全体のメタデータで発生している場合は、出力が少し異なります。例:
# zpool status -v morpheus pool: morpheus id: 13289416187275223932 state: UNAVAIL status: The pool metadata is corrupted. action: The pool cannot be imported due to damaged devices or data. see: http://support.oracle.com/msg/ZFS-8000-72 config: morpheus FAULTED corrupted data c1t10d0 ONLINE
プール全体が破壊された場合、プールは必要な冗長レベルを提供できないため、FAULTED 状態になります。
ファイルまたはディレクトリが破壊されても、破壊の種類によってはシステムがそのまま動作する場合があります。データの正常なコピーがシステムに存在しなければ、どの損傷も事実上修復できません。貴重なデータの場合は、影響を受けたデータをバックアップから復元する必要があります。このような場合でも、プール全体を復元しなくても破壊から回復できる場合があります。
ファイルデータブロックの中で損傷が発生した場合は、ファイルを安全に削除することができるため、システムのエラーを解消できます。永続的なエラーが発生しているファイル名のリストを表示するには、zpool status –v コマンドを使用します。例:
# zpool status system1 -v
pool: system1
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://support.oracle.com/msg/ZFS-8000-8A
config:
NAME STATE READ WRITE CKSUM
system1 ONLINE 4 0 0
c0t5000C500335E106Bd0 ONLINE 0 0 0
c0t5000C500335FC3E7d0 ONLINE 4 0 0
errors: Permanent errors have been detected in the following files:
/system1/file.1
/system1/file.2
永続的なエラーが発生しているファイル名のリストは、次のようになります。
ファイルへの完全なパスが見つかり、データセットがマウントされている場合は、ファイルへの完全なパスが表示されます。例:
/path1/a.txt
ファイルへの完全なパスは見つかったが、データセットがマウントされていない場合は、前にスラッシュ (/) が付かず、後ろにファイルへのデータセット内のパスが付いたデータセット名が表示されます。例:
path1/documents/e.txt
エラーにより、または dnode_t の場合のようにオブジェクトに実際のファイルパスが関連付けられていないことにより、ファイルパスに対するオブジェクト番号を正常に変換できない場合は、後ろにオブジェクト番号の付いたデータセット名が表示されます。例:
path1/dnode:<0x0>
メタオブジェクトセット (MOS) のオブジェクトが破壊された場合は、後ろにオブジェクト番号の付いた <metadata> という特別なタグが表示されます。
プールをスクラブし、複数回繰り返すプールエラーをクリアすることによって、よりマイナーなデータ破損を解決しようとすることができます。最初にスクラブし、繰り返しをクリアしても破損ファイルが解決されない場合は、再度実行してください。例:
# zpool scrub system1 # zpool clear system1
ディレクトリまたはファイルのメタデータの中で破壊は発生している場合には、そのファイルを別の場所に移動するしかありません。任意のファイルまたはディレクトリを不便な場所に安全に移動することができ、そこで元のオブジェクトを復元することができます。
損傷を受けたファイルシステムにある破壊されたデータが、スナップショットなどの複数のブロック参照を持つ場合は、zpool status –v コマンドを使用しても、破壊されたすべてのデータパスが表示されるわけではありません。現在の zpool status による破壊されたデータの報告は、破壊されたメタデータの量や、zpool status コマンドの実行後にブロックが再利用されたかどうかによって制限されます。複製解除されたブロックがあると、破壊されたすべてのデータの報告がさらに複雑になります。
破壊されたデータがあり、スナップショットデータが影響を受けることが zpool status –v コマンドによって示された場合は、破壊されたほかのパスを特定するために次のコマンドを実行することを検討してください。
# find mount-point -inum $inode -print # find mount-point/.zfs/snapshot -inum $inode -print
最初のコマンドは、指定されたファイルシステムとそのすべてのスナップショット内で、破壊が報告されたデータの inode 番号を検索します。2 番目のコマンドは、同じ inode 番号を持つスナップショットを検索します。
プールのメタデータが損傷していて、その損傷によりプールを開けないかインポートできない場合の選択肢には、次のものがあります。
zpool clear –F コマンドまたは zpool import – F コマンドを使用して、プールの回復を試みることができます。これらのコマンドは、プールに対する直近数回のトランザクションをロールバックして、プールを正常な状態に戻すことを試みます。zpool status コマンドを使用すると、損傷したプールと推奨される回復手順を確認できます。例:
# zpool status pool: storpool state: UNAVAIL 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 Fri Jun 29 17:22:49 2012 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://support.oracle.com/msg/ZFS-8000-72 scrub: none requested config: NAME STATE READ WRITE CKSUM storpool UNAVAIL 0 0 1 corrupted data c1t1d0 ONLINE 0 0 2 c1t3d0 ONLINE 0 0 4
前の出力で説明した回復プロセスでは次のコマンドを使用します。
# zpool clear -F storpool
損傷したストレージプールをインポートしようとすると、次のようなメッセージが表示されます。
# zpool import storpool cannot import 'storpool': I/O error Recovery is possible, but will result in some data loss. Returning the pool to its state as of Fri Jun 29 17:22:49 2012 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool import -F storpool'. A scrub of the pool is strongly recommended after recovery.
前の出力で説明した回復プロセスでは次のコマンドを使用します。
# zpool import -F storpool Pool storpool returned to its state as of Fri Jun 29 17:22:49 2012. Discarded approximately 5 seconds of transactions
損傷したプールが zpool.cache ファイルに存在する場合、システムのブート時に問題が検出され、損傷したプールが zpool status コマンドで報告されます。プールが zpool.cache ファイルに存在しない場合、プールをインポートすることも開くこともできず、プールをインポートしようとするとプールの損傷を知らせるメッセージが表示されます。
損傷したプールを読み取り専用モードでインポートできます。この方法によってプールをインポートでき、データにアクセスできます。例:
# zpool import -o readonly=on storpool
プールを読み取り専用でインポートすることの詳細については、読み取り専用モードでプールをインポートするを参照してください。
zpool import –m コマンドを使用して、ログデバイスのないプールをインポートできます。詳細は、ログデバイスがないプールをインポートするを参照してください。
いずれのプール回復方法によってもプールを回復できない場合は、プールとそのすべてのデータをバックアップコピーから復元する必要があります。そのために使用する方法は、プールの構成とバックアップ方法によって大きく異なります。最初に、zpool status コマンドによって表示された構成を保存しておき、プールを破棄したあとで構成を再作成できるようにします。次に、zpool destroy –f コマンドを使用してプールを破棄します。
また、プールにアクセスできなくなると、この情報にもアクセスできなくなるため、データセットのレイアウトやローカルに設定されたさまざまなプロパティーを記述するファイルをどこか安全な場所に保存します。プールを破棄したあとに、プールの構成とデータセットのレイアウトを使用して、完全な構成を再構築できます。その後、好きなバックアップまたは復元方法を使用してデータを投入できます。