web-dev-qa-db-ja.com

ZFS永続エラー。回復のためのオプション

背景:家族や友人のための小さなパーソナルサーバー、電子メール、Web、シェルなど。 SunOS 5.11、2008年11月のsnv_113。サーバーは2009年に構築されました。これはopensolarisまたはSolarisの早期アクセスリリースのいずれかであったと思います。 AMD 64ビットプロセッサ、4GBRAM。

ルートzpoolスリーウェイミラー。元々はラップトップサイズの320GBの回転ディスク3枚で構成されていました。 3年後、回転するディスクのそれぞれが1つずつ消えていきました。それぞれがメーカーからの保証の下で交換されました。過去数か月で、別のディスクが再びバカになりました。とりあえず、2面ミラーを走らせることにしました。先週、永続的なエラーが発生し、3つのファイルがリストされました。スクラブ後、これらのエラーは1つのメタデータエラーを除いてなくなりました。 2番目のディスクにも障害が発生し始めたので、予備のデスクトップドライブを投入し、それに再シルバーリングしました。同じチェックサムとメタデータエラーが持続しました。必死になって、SSDをいくつか購入しました(回転するディスクが本当に嫌いになりました)。 3分の1としてプールに1つ追加しました。もちろん、resilverの間、次の状態のままです。

root-klaatu /root% zpool status -v
  pool: rpool
 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: resilver in progress for 1h47m, 84.53% done, 0h19m to go

構成:

    NAME        STATE     READ WRITE CKSUM
    rpool       ONLINE       0     0     1
      mirror    ONLINE       0     0     6
        c1d0s0  ONLINE       0     0     6
        c1d1s0  ONLINE       0     0     6  55.0G resilvered
        c0d1s0  ONLINE       0     0     6  55.3G resilvered

エラー:

Permanent errors have been detected in the following files:
    <metadata>:<0x172>

終了するまでに、ディスクごとに10個のチェックサムエラーが報告され、rpool自体に2個のチェックサムエラーが報告されます。 「zpoolclear」はチェックサムエラーカウントをクリアするために「素晴らしい」働きをしますが、エラーのあるメタデータファイルは存続し、各resilver/scrubは同じチェックサムエラーを返します。エラーが発生したデータが存在する場所であることがあることを読んだので、すべてのスナップショットを削除したことに注意してください。しかし、喜びはありません。

私はバックアップを持っていますが、それらはCrashPlan経由であり、クラウドにあります。そのため、サーバー用に維持している限られた接続を介して全体を復元するには数日かかります。

すっごく-そうは言っても。バックアップからの復元以外の回復のための私のオプションは何ですか(メタデータ「ファイル」は明らかに削除できないものであるため)。

新しいディスクに新しいzfsプールを作成する場合、zfs send/receiveを実行すると、エラーが「クリア」されますか?または、新しいプールを設定してから、古いプールデータをそのプールにrsyncしてから、新しいプールの名前を元に戻し、ミラーディスクにブートブロックをインストールして、そこから起動してみることをお勧めしますか?実際の起動を妨げる可能性のある実際のプール名に関連するデータのキャッシュビットがあることを読みました。

「論理的」なことは、OmniOSやOpenIndianaなどの最近のOSで新しい新しいサーバーを構築することですが、このサーバー(元々はSparc 20でした)にすべてのカスタムコンパイル済みコードを使用することです。 2000年代初頭)、すべてを同期することはうまく機能しないと思います。

助けてくれてありがとう。

ああ-追加する必要があります-サーバーは正常に実行されています。クラッシュもロックアップも何もありません。

4
anastrophe

破損したプールを新しいプールに送信および受信することにより、このインシデントから「回復」することができました。

#新しい単一ディスクプール(または必要に応じて事前にミラー)を作成します
_zpool create -f tpool c0d0s0_

#古いプールのベースラインスナップショットを作成する
_zfs snapshot -r rpool@now_

#zfsはそれを新しいtpoolに送信します
_zfs send -vR rpool@now | zfs receive -Fduv tpool_

#これにより、tpoolのマウントポイントがrpoolにリセットされることに注意してください-必ず更新してください
_zfs set mountpoint=/tpool tpool_

#シングルユーザーに移動します。システムにどのように依存するか
#編集:
_/rpool/boot/grub/menu.lst_

#(このファイルはbootadmによって維持されることになっていることに注意してください。状況によっては、直接アクセスすることを選択しました)

#最初のブートセットを複製し、コピーを編集し、findrootをから変更します
findroot (pool_rpool,0,a)
#から
findroot (pool_tpool,0,a)

#シングルユーザーで2番目のスナップショットを作成する
_zfs snapshot -r rpool@now2_

#インクリメンタルスナップを新しいtpoolに送信します
_zfs send -vR -i rpool@now rpool@now2 | zfs receive -Fduv tpool_

#mount tpool-もう一度覚えておいてください、マウントポイントを更新する必要があります
_zfs mount=/tpool tpool_

# 'bootsign'ファイルをrmし、newに置き換えます。
_rm /tpool/boot/grub/bootsign/pool_rpool_
_touch /tpool/boot/grub/bootsign/pool_tpool_

#どこから起動するかを形式化する
_zpool set bootfs=tpool/ROOT/snv_113 tpool_

#ブートブロックを追加します
_installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c0d0s0_

#電源を切り、rpoolディスクを切り離します-または、さらに調査するためにそれらを残します
#ミラーリングする場合は、2番目のディスクを物理的に接続します
# 起動する
#tpoolを鏡に変える
_zpool attach tpool c0d0s0 c1d0s0_

#完了

すべてが満足のいくものである場合は、grubメニューを編集して、新しいtpoolブートエントリを最初に移動するか、「default」宣言を変更して、リストにあるものを指すようにすることができます(または、ない場合は他のブート宣言の場合は、rpoolの宣言を削除してください)。

また、これを解決しようとしているときにおそらく100以上の異なるサイトやウェブページを参照しましたが、上記の「レシピ」は主に ミラーリングされたZFS rpoolを縮小する方法、Joe Mockerによる から派生しています。

1
anastrophe