解決策 1:
何百万ものファイルにすばやくアクセスしてバックアップするためのオプション
同じような問題を抱えている人から借りる
これは、USENET ニュース サーバーとキャッシング Web プロキシが直面する、より簡単な問題のように思えます。無作為にアクセスされる何億もの小さなファイルです。彼らからヒントを得たいと思うかもしれません (ただし、彼らは通常、バックアップを取る必要はありません)。
http://devel.squid-cache.org/coss/coss-notes.txt
http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf
サイクリック ニュース ファイルシステムのサイクリックな性質は明らかにあなたには関係ありませんが、複数のディスク ファイル/デバイスにパックされたイメージと、ユーザーが提供する情報からの高速インデックスを使用して位置情報を検索するという低レベルの概念は非常に適切です。
専用ファイルシステム
もちろん、これらは、独自のファイルシステム コードを記述できることを除けば、ファイル内にファイル システムを作成し、それをループバックにマウントすることについて人々が話していたことと似た概念です。もちろん、システムはほとんどが読み取り専用であると言ったので、実際にはディスク パーティション (またはサイジングの柔軟性のために lvm パーティション) をこの 1 つの目的専用にすることができます。バックアップする場合は、ファイルシステムを読み取り専用でマウントしてから、パーティション ビットのコピーを作成してください。
LVM
上で LVM はパーティションの動的なサイズ変更を可能にするのに役立つと述べたので、多くの空のスペースをバックアップする必要はありません。しかし、もちろん、LVM には非常に適用可能な他の機能があります。具体的には、ファイルシステムをある時点でフリーズできる「スナップショット」機能です。臨時記号 rm -rf またはスナップショットを妨げないもの。何をしようとしているのかにもよりますが、バックアップのニーズにはそれで十分かもしれません。
RAID-1
あなたはすでに RAID に精通しており、おそらくすでに信頼性のために使用していると思いますが、少なくともソフトウェア RAID を使用している場合は、RAID-1 をバックアップにも使用できます (ハードウェア RAID で使用できますが、実際には読み取るには同じモデル/リビジョン コントローラーが必要な場合があるため、信頼性が低くなります)。概念は、通常の信頼性のニーズのために実際に接続する必要があるよりも 1 つ多くのディスクを使用して RAID-1 グループを作成することです (たとえば、2 つのディスクでソフトウェア RAID-1 を使用する場合は 3 つ目のディスク、またはおそらく大きなディスクとハードウェア-ハードウェア RAID-5 の上にソフトウェア RAID-1 を備えた小さいディスクを使用した RAID5)。バックアップを作成するときが来たら、ディスクをインストールし、mdadm にそのディスクを RAID グループに追加するように依頼し、完全であることを示すまで待ち、オプションで検証スクラブを依頼してから、ディスクを取り外します。もちろん、パフォーマンス特性に応じて、ほとんどの場合ディスクを取り付けておいて、代替ディスクと交換するためにのみ取り外したり、バックアップ中にのみディスクを取り付けたりすることができます)。
解決策 2:
ループバック マネージャーを使用して仮想ファイル システムをマウントすることもできますが、これによりバックアップ プロセスが高速化されますが、通常の操作に影響を与える可能性があります。
もう 1 つの方法は、dd を使用してデバイス全体をバックアップすることです。例:dd if=/dev/my_device of=/path/to/backup.dd .
解決策 3:
おそらくご存知のように、問題は地域性です。通常のディスク シークには 10 ミリ秒程度かかります。したがって、ランダムに配置された 1,000 万個のファイルに対して "stat" (または open()) を呼び出すだけで、1,000 万回のシーク、または約 100,000 秒、または 30 時間が必要です。
そのため、関連する数値がシーク時間ではなく、ドライブの帯域幅 (通常は 1 つのディスクで 50 ～ 100 MB/秒) になるように、ファイルをより大きなコンテナーに配置する必要があります。また、RAID を投げることができるので、帯域幅を増やすことができます (ただし、シーク時間は短縮されません)。
私はおそらく、あなたがまだ知らないことを言っているわけではありませんが、私が言いたいのは、あなたの「コンテナ」のアイデアは間違いなく問題を解決し、ほぼすべてのコンテナで解決できるということです。ループバック マウントは、他のものと同様に機能する可能性があります。
解決策 4:
いくつかのオプションがあります。最も単純で、すべての Linux ファイルシステムで動作するはずの dd です。 パーティション全体をコピーします (/dev/sdb3 または /dev/mapper/Data-ImageVol ) を単一の画像に変換し、その画像をアーカイブします。単一のファイルを復元する場合は、イメージをループバック マウントします (mount -o loop /usr/path/to/file /mountpoint ) 必要なファイルをコピーします。完全なパーティションの復元の場合、最初の dd の方向を逆にすることができます コマンドですが、実際には同じサイズのパーティションが必要です。
あなたのユースケースから判断すると、個々のファイルの復元は、発生したとしても非常にまれなイベントだと思います。これが、ここでイメージベースのバックアップが本当に理にかなっている理由です。個々の復元をより頻繁に行う必要がある場合は、ステージングされた LVM スナップショットを使用する方がはるかに便利です。しかし、「すべてを失った」という重大な災害のために、イメージベースのバックアップを実行する必要があります。イメージベースのリストアは多く行われる傾向があります 単にブロックを復元するだけなので、tar ベースの復元よりも高速です。fopen/fclose ごとに大量のメタデータ操作が発生することはなく、さらに高速化するために非常に順次的なディスク操作になる可能性もあります。
または、@casey が指摘した Google ビデオが途中で言及しているように、XFS は優れたファイルシステムです (複雑な場合)。 xfsdump は、XFS でより優れたユーティリティの 1 つです。 ファイルシステム全体を単一のファイルにダンプするユーティリティであり、通常は tar よりも高速です。 できる。これはファイルシステム固有のユーティリティであるため、tar ではできない方法で fs 内部を利用できます。
解決策 5:
まだ実行していない場合は、まず EXT4 にアップグレードすることをお勧めします。
Google は、EXT4 が優れたアイデアである理由について多くの調査を行ってきました。
その後、分散ファイル システム アーキテクチャの展開を検討する必要があります。例:
- http://www.xtreemfs.org/
- http://code.google.com/p/kosmosfs/
- http://hadoop.apache.org/hdfs/