ZFSに関する私の経験では、それはただ機能するなので、答えは「問題ない」になると思いますが、データ プールがあり、それが失敗すると 1 月が台無しになってしまうので、もう一度確認したいと思います。
これは、実際には別のデータ プールが関係する 2 つの異なる状況で発生する可能性がある質問です。現在、私は最初の状況に対処していますが、2 番目の状況についても疑問に思っています。
- システム ディスクのストレージ (つまり、 を保持しているストレージ
rpool) に障害が発生しましたが、データ プールのストレージには問題がないため、バックアップからシステム ディスクを復元し、データ プールのライブ ストレージをそのまま使用し続けたいと考えています。 - VMでSolarisを実行していて、ハイパーバイザが取得したスナップショットにロールバックしたい場合（ないの ZFS スナップショットです
rpoolが、データ プールは「独立」モードのディスク、RDM などに保存されているため、ロールバックされません。
どちらの場合も、Solaris が再起動されると、Solaris は認識しているものの、(記憶している限りでは) これまで一度も配置したことのない状態のデータ プールを参照することになります。
私が主に懸念しているのは、システム ディスクが巻き戻される前にシステムが正常にシャットダウンされた場合、および巻き戻されるイメージの前にシステムが正常にシャットダウンされていた場合のみです。実行状態間の切り替えは少し難しいと予想されます。
また、私の特定のケースでは、プールのストレージ ジオメトリとストレージへのパスは変更されていないことにも注意してください。繰り返しますが、変更されていたら、これはもっと複雑になると思います。
WindowsとNTFSでは、比較的単純な分離システムなので、なぜそれが必要なのか理解しにくいので、この質問をすることはないだろう。しないだろう動作します。しかし、Solarisは何らかのプールメタデータを保持しているようです帯域外zpool export、システム間でプールを移動するときにそうする必要があるという事実からも明らかですzpool import(VMware のおかげで、私はそのようにしたことがありません)。このメタデータとその目的に関する私の知識は限られているため、この状況での影響を推論するのは困難です。(これについての説明があると助かります!)
実は、ロールバック前のシステムには今でもアクセスできます。これは、不運な予防保守ディスク交換（SmartArrayはZFSよりも低機能なので、データが失われました）の後に1716 POST警告を出したHP SmartArrayにバックアップされたVMFSデータストアにあります。すべての重要なVMはまだ正常のようで、ファイルシステムのスキャンでもエラーは見つかりませんでしたが、ESXiがゲストにエラーを渡す代わりに、不良セクタを黙ってゼロにするなので、どこかに潜んでいるゼロ化されたセクターが後で私を悩ませる危険を冒したくはありません。
Solaris VM の場合、ゼロ化されたセクターについては ZFS がそれをキャッチするので心配する必要はありませんが、他の VM のほとんどはダム ファイルシステムを使用しています。ただし、バックアップは VMware データストア全体のイメージなので、それらを修正すると Solaris VM もロールバックされます。実際、rpoolこの VM のスクラブを実行しましたが、エラーは見つかりませんでした。したがって、必要な場合は、VMDK を別の場所に隠しておき、ロールバック後にコピーし直すだけで、この質問全体が無意味になります。誰も答えてくれない場合は、そうすると思います (笑)。しかし、これは私がしばらく疑問に思っていたことなので、それでも質問します。
そこで質問なのですが、システム ディスクのストレージをロールバックして完了できますか? それとも、ロールバック前のシステムからプールをエクスポートし、ロールバックして、ストレージを接続する前にプールを削除し、ストレージを接続してプールをインポートする必要があるのでしょうか? 後者の方法は気に入りません。その理由の 1 つは、そのプールから CIFS と iSCSI の両方が提供されており、それらをどのように設定したか、あるいはどのように設定するかさえすぐには思い出せないため、壊れたら怒ります。(フルタイムのシステム管理者がいないことがわかりますか? 笑)
VM は古いバージョンの Solaris 11.0 を実行しています。
(ちなみに、同じ質問のせいで、古いバージョンになっています。アップグレードを試みる前に、VM を壊してしまった場合に備えてスナップショットを作成したいと思っていましたが、ロールバックされたシステムが独立したプールにどう反応するか心配だったので、そのままにしました。また、 のスナップショットも作成できることはわかっていますrpoolが、Solaris を毎日使用していない人にとっては、同じレベルの安心感は得られません。)
答え1
これは「zfs はそのまま動作します」という種類の回答の 1 つです...
プールのメタデータは実際にはプール内に保存されており、ローカル OS 上には保存されていません。そのため、たとえば、システムがクラッシュしてクリーンな状態でシャットダウンされない場合、プール内のメタデータはプールがクリーンな状態で「エクスポート」されなかったことを認識します。このプールを新しいシステムにインポートしようとすると、プールがエクスポートされておらず、別のシステムに属しているというエラーが表示されます。その場合、zpool import -f (強制) を実行するだけでクリーンな状態でインポートされます。
したがって、データ プールに固有のデータは、いつどこでプールを再度インポートしようとしても安全です。「復元された」rpool を起動すると、その rpool 上の OS はインポートするプールを認識し、データ プールをインポートするだけです。プールがエクスポートされたかどうかは追跡されません。ただし、プールがエクスポートされると、OS はそれをまったく追跡しなくなります。
さて、rpool の質問についてですが、VM スナップショット、テープ バックアップなどから復元しても、データ プールが最初に作成またはインポートされる前にバックアップが取られていない限り、データ プールの処理方法は変わりません。その場合は、OS が復元されたら、プールをインポートするだけです。rpool の状態に関係なく、データ プール上のデータは安全です。
それが役に立つことを願います。
余談ですが、データ プールにどう反応するか分からないため、Solaris のアップグレードをためらっているとのことですが、心配はいりません。アップグレードでは既知のプールが保持され、必要に応じてインポートされます。
また、Solaris OS のアップグレードは、個別の「ブート環境 (BE)」に自己完結していることにも注意してください。したがって、OS のアップグレードを行うと、実際には、新しいバージョンを含む完全に独立した OS インストールが作成されます...その間、OS は引き続き稼働しています。その後、再起動すると、新しい OS が起動します。新しい OS に問題がある場合 (つまり、予期していなかったライブラリの変更など)、もう一度再起動して元の 11.0 バージョンを起動すると、アップグレード前とまったく同じ状態になります。これは、OS をアップグレードする素晴らしい方法です。