複数の物理ハードディスクを1つのボリュームに結合したいので、メディア/ファイルサーバーにLVMを使用することについて議論しています。 LVMでRAIDを使用したくないので、私の質問は次のとおりです。
ボリューム内の複数のハードディスクの1つがダウンした場合、すべてのデータが失われますか、それともその個々のディスクに格納されていたデータが失われますか?
また、個々のディスクのデータを失うだけの場合は、そのディスクを交換し、バックアップから復元してディスク上の内容を復元するだけで済みますか?
ボリューム内の複数のハードディスクの1つがダウンした場合、すべてのデータが失われますか、それともその個々のディスクに格納されていたデータが失われますか?
LVM全体に保存されているデータは失われません
また、個々のディスクのデータを失うだけの場合は、そのディスクを交換し、バックアップから復元してディスク上の内容を復元するだけで済みますか?
いいえ、それはそれほど単純ではありません
あなたはここで同様の質問を読むことができます LVMと災害復旧
シンプル: mhddfs 。を探しています
これは、1つの大きなファイルシステムであるかのように振舞い、言及された順序でディスクに書き込み、最初のファイルがいっぱいになっている場合は、最終的に大きなファイルを別のデバイスに移動します。実際にディスク上のサブフォルダーを使用して、同じ機能を実現することもできます。
個々のディスクを最初にマウントし、アクセス可能なままにする必要があります。それはファイルシステムをまったく変更せず、どのファイルシステムが配置されているかを気にしません(空き領域がファイルシステムによって正しく報告されている限り)。ディスクが失われた場合、mhddfsを(その場で)再度マウントする必要があり、そのディスク上のデータは失われます。
使用法:
mhddfs /dir1,/dir2[,/path/to/dir3] /path/to/mount [-o options]
または/etc/fstab
mhddfs#/path/to/dir1,/path/to/dir2 /mnt/point Fuse defaults 0 0
複雑でパワフル:欲しい nionfs 。
mhddfsは非常にシンプルで非常にシンプルですが、SSHを介して他のユーザーにアクセスを許可するときに、ファイルの権限に問題がありました。解決策は見つかりませんでしたが、ユニオンを見つけました。
Unionfsを使用すると、さまざまなファイルシステムにまたがる複数のフォルダを1つにマウントすることもできますが、それは権限の魔法です。複数の読み取り専用フォルダと1つの書き込み可能なフォルダをマージして、1つのフォルダとして表示することができます。マージされたフォルダーを共有したユーザーは、読み取り専用フォルダーに書き込むことができます-表示されますが、ファイルは単一の書き込み可能なフォルダーになります。 LinuxブートCDはこのように機能し、書き込み可能なディスクはRAMディスクです。読み取り専用フォルダ内のファイルを削除することもできますが、実際にはファイルは削除されませんが、書き込みディレクトリに非表示のホワイトリストファイルが作成されます。すべてのオプションをキャッチした場合、基本的に ファイルシステムを貧弱な人のSVNとして使用する を使用できます。
SVNのようなオプションを使いすぎると、2回存在するデータが失われる可能性があります(シナリオではありそうもないが、可能性があります)。一方、書き込み可能なフォルダーは、小さな非表示のホワイトリストファイルでいっぱいになります。それ以外は、ディスクをクリーンに保ち、個別に使用できるようにします。ファイルがディスクに対して大きすぎるとどうなりますか、まだわかりません。
使用法:
unionfs-Fuse -o cow,max_files=32768 \
-o allow_other,use_ino,suid,dev,nonempty \
/path/to/dir1=rw:/path/to/dir2=ro:/dir3
/u/union/etc
どこ =rw
は、フォルダーを読み取りおよび書き込み可能にし、=ro
を指定すると、権限が別の方法で指定されていても、読み取り専用になります。 etc/fstab
これは
unionfs-Fuse#/path/to/dir1=rw:/path/to/dir2=ro:dir3 /path/to/mount Fuse cow,allow_other 0 0
複数のデバイスを一緒に接続しているだけでは冗長性がないため、データが失われる可能性があります。しかし、ビジネスでメディア/ファイルサーバーを使用している場合、すべてをバックアップサーバー/テープドライブにバックアップしているため、何も失うことはありません。
なぜRAIDを避けているのですか? RAIDのポイントは可用性です。ディスク障害が原因で時間を無駄にしたくない場合は、RAID 1構成を使用できます。これにより、読み取りも高速化できます。それらは高すぎるわけではなく、ディスク障害が発生したときに初めて自己負担となります。カードの代金を支払う必要が本当にない場合は、セットアップで少し注意が必要ですが、ソフトウェアRAIDを使用するようにLinuxをセットアップできます。正しいドライブを確実に交換するためのトラブルシューティング。
それ以外の場合は、残りのディスクからどのデータを回復できるかを試すために、いくつかのフープをジャンプする必要があります。それは可能ですが、あなたはあるべきよりもはるかに多くのトラブルを求めています。適切なバックアップを取得し、RAIDを再検討します。
すべてのLVMボリュームにまたがる1つのファイルシステムを使用している場合、FSは基礎となる物理ボリュームを認識せず、それに整合した構造を作成しないため、ファイルシステム全体が損傷します。正常に機能しているディスク上の一部のパーツをレスキューすることは可能ですが、その保証はありません。
また、同じ理由で、損傷したディスクのファイルを復元するだけでも機能しません。
メディアパーティションにmdadmを設定する方がはるかに簡単な方法だと思います。 「実際のRAID」用のハードウェアがない場合、mdadmルートを使用することはかなり簡単であり、冗長性と単純なディスク交換の要件を満たしているように見えます。
# Format your drives first
# Create your MD
mdadm --create /dev/md1 --level=5 --raid-devices=3 /dev/sda2 /dev/sdb2 /dev/sdc2
# In the event that a drive fails do the following
mdadm /dev/md1 --fail /dev/sda1
# Format the new drive
mdadm --add /dev/md1 /dev/sda1
詳細: http://en.wikipedia.org/wiki/Mdadm
ボリューム内の複数のハードディスクの1つがダウンした場合、すべてのデータが失われるか、またはその個々のディスクに格納されていたデータが失われるだけですか?
MdadmとRAID 5を使用すると、1台のドライブを失う可能性があり、アレイが機能する可能性がありますが、パフォーマンスが低下する可能性があります。
言及されていないことを理解するために重要なことは、ファイルシステム内のファイルが必ずしもディスク上の1つの場所にあるとは限らないことです。ファイルシステム内のどこにでも存在する可能性のあるブロックに分割されます。ファイルがdisk1にある場合の最初の4K、次のdisk2など。ファイルシステムのチャンクを失った場合、何かを回復しようとする混乱を想像できます。
ここではBtrfsが良い選択です。 1つのディスクの損失に耐性のあるメタデータ(「raid1」チャンクプロファイル)を使用できます。他のディスク上のデータには引き続きアクセスできます(明確にするために、欠落しているディスクが参照されている場所に穴があふれたファイルに変換されます)。これは、 btrfs balance with a filter を実行して行います。
Sudo btrfs balance start -m convert=raid1 /mnt/point