web-dev-qa-db-ja.com

ディスク障害時のLVM2の動作を理解していますか？

5x4TBのセットアップに次のコマンドを使用するLVM2グループがあります。

pvcreate /dev/sd{b,c,d,e,f}
vgcreate vg0 /dev/sd{b,c,d,e,f}
lvcreate -l 100%FREE -n lvol1 vg0

このモンスターを作成したので、それについていくつか質問があります。たまたま線形であるデフォルトの構成で、/dev/sdb失敗？

  • さようなら全体にさようなら/dev/sdbデータまたはLVMは、最初のバイトを埋めるのではなく、デバイス全体にファイルを配置していますか？

  • どのファイルがどのデバイスにあるかをどのように確認できますか？ディスクを紛失した場合、可能であればそれを復元できるように、データが失われた場所を知りたいのですが。

注：

  • 私は LVM作成のためのGentooハンドブック に従いました。
  • RAIDx（および私の理解ではLVM）はバックアップを提供しないことを完全に理解しています。彼らはせいぜいディスク障害に対する回復力を追加することができるだけです。私は（ソフトウェアの）RAID5とディスク障害の経験があります。幸いなことに、一度に1つだけ障害が発生しました。しかし、私はLVMの経験がないため、これらの質問をしています。
filesystemslvmraid
4
NoDataFound

LVMはファイルを配置しません。 LVMは、データが複数の物理デバイスに分散される大きな論理デバイスを作成します。

これは、1GiBパーティションを作成してフォーマットし、ファイルシステムにデータを作成して、250MiBから500MiBの範囲をゼロで上書きするようなものです。

ファイルシステム内のデータが250MiB未満の場合、fsckがそのほとんどまたはすべてを復元する可能性があります。簡単に試してみることができます。

1
Hauke Laging

lvdisplay --mapsは、特定のLVまたはその特定の範囲に対応する物理範囲がどこにあるかを示します。 pvdisplay --mapsは、PV中心の視点から同じ情報を示します。

たとえば、pvdisplay --mapsが、失敗したPVが特定のLVの論理エクステント1000 ... 4000をカバーしていることを示し、そのVGのエクステントサイズが4 MiBである場合、PVが完全に失敗すると、LVには大きなアクセス不能な「穴」ができ、LVの開始から4000 MiBのポイントから始まり、そのLVの開始から16000 MiBのポイントまで続きます。

通常、このような状況では、LV全体を復元するのが最も簡単です。これにより、すべてのファイルが一貫した状態にあることを確認できます。たとえば、ファイルAにファイルBの内容への参照が含まれている場合、破損した領域に1つしかなかった場合でも、バックアップから両方を復元することができます。

しかし、必要な場合（つまり、使用可能なバックアップがないために深刻な問題が発生していることが判明した場合）、lvchangeまたはvgchangeを--activationmode partialとともに使用して、LVをアクティブ化できます。パーツが欠落している場合でも、マウントして残りを回復できます。これは、データ回復の目的でonlyを実行する必要があります。

あなたのケースでは/dev/sdbがボリュームグループの最初のPVになるため、LVの最初の部分も保持されます。これは、そのLVの多くの重要なファイルシステムメタデータがおそらく最終的に存在する場所なので、fsckはたくさんのエラーを引き起こします。 frostschutzが言ったように、photorecは、LVの残りの部分から断片化されていないファイルを非常によく見つけることができました。しかし、これに頼ることは悪い戦略です。

バックアップと、完全な復元にかか​​る時間について考える必要があります。ディスク障害後にLV全体を復元するのに時間がかかりすぎる場合は、システムに冗長性を追加してそれを回避する必要があります。通常、これはより多くのディスクを取得し、データを何らかのRAIDアレイに配置することを意味します。

ただし、RAIDアレイをセットアップした場合でも、バックアップを忘れないでください。 RAIDはディスク障害に対処しやすくするかもしれませんが、ユーザー/システム管理者が "おっと"した場合にはまったく役に立ちません。 RAIDはバックアップではありません。

1
telcoM

/ dev/sdbが失敗するとどうなりますか？

Lvol1は機能しなくなります。ドライブを1つ失うと、5ドライブ分のデータが失われます。ボリュームには膨大な量のデータが失われ（ディスク全体が失われ）、ほとんどの場合、その上で使用しているファイルシステムが1つでも気に入らなくなります。

fsckが何かを回復することを期待すべきではありません。発生する可能性はありますが、fsckはデータ復旧ツールではありません。ほとんどの場合、軽微な不整合を修正するためだけに使用され、数百ギガバイトに相当するデータが失われた場合に魔法のように動作しません。場合によっては、fsckが一貫性のある（まだ奇妙に空の）ファイルシステムを提供することを完全に喜んでいます。

fsckなどを使用する場合は、スナップショットまたはオーバーレイを使用して、行った変更を元に戻すことができます。 （データ回復では、読み取り専用またはコピーオンライトモードでの作業が義務付けられています。）

LVMは線形（デフォルトではとにかく）であるため、photorecおよび他のツールは、他のドライブ上の（フラグメント化されていない、暗号化されていない）データを見つけることができます。

LVMは幸いにも多くのドライブにまたがっていますが、いくつかの小さなボリュームを作成することをお勧めします。見つからないドライブに配置されなかったボリュームは存続します。ファイルシステムが小さいと、fsckの問題も回避されます。これは、ファイルシステムのサイズによっては、リソースを大量に消費し、時間がかかる傾向があります。

パーティション化されていないドライブを使用すると、とにかく誤ってパーティションテーブルを作成して、プロセス中に他のメタデータを上書きするリスクが伴います。常にパーティションテーブルを使用する必要があります。

いずれにせよ、データを失いたくない場合は、バックアップを作成してください。

ドライブが1つ故障するたびにバックアップを復元したくない場合は、RAIDも使用してください。

0
frostschutz