約1,000万のファイル（表紙）が[0-f]の範囲の3つのレベルのサブディレクトリに保存されているWebサイトを実行しています。

0/0/0/
0/0/1/
...
f/f/f/

これにより、ディレクトリごとに約2400個のファイルが作成されます。これは、1つのファイルを取得する必要がある場合に非常に高速です。さらにこれは多くの質問によって提案された習慣です。

ただし、これらのファイルをバックアップする必要がある場合、10mのファイルを保持している4kディレクトリを参照するだけで何日もかかります。

だから、これらのファイルをコンテナ（または4kコンテナ）に保存できるかどうか疑問に思っています。それぞれがファイルシステム（ある種のマウントされたext3 / 4コンテナ？）のように動作します。これは、ファイルシステム内のファイルに直接アクセスするのとほぼ同じくらい効率的であり、別のサーバーに非常に効率的にコピーされるという大きな利点があると思います。

これを最善にする方法に関する提案はありますか？または任意の実行可能な代替（noSQL、...）？

数百万のファイルにすばやくアクセスしてバックアップするためのオプション

同様の問題を持つ人々から借りる

これは、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パーティション）をこの目的専用にすることができます。バックアップする場合は、ファイルシステムを読み取り専用でマウントしてから、パーティションビットのコピーを作成します。

LVM

LVMをパーティションの動的なサイジングを可能にして、大量の空きスペースをバックアップする必要がないようにするのに役立つと上記で言及しました。しかし、もちろん、LVMには他にも非常に適用可能な機能があります。具体的には、ある時点でファイルシステムをフリーズできる「スナップショット」機能。rm -rfスナップショットを邪魔しないような偶発的なものなど。何をしようとしているのかによっては、バックアップのニーズに十分な場合があります。

RAID-1

RAIDについては既にご存知で、おそらく信頼性のために既に使用されていると確信していますが、少なくともソフトウェアRAIDを使用している場合は、RAID-1もバックアップに使用できます（ハードウェアRAIDで使用できますが、実際には読み取りに同じモデル/リビジョンコントローラが必要になる場合があるため、信頼性が低下します）。コンセプトは、通常の信頼性のニーズに接続するために実際に接続する必要のあるディスクよりも1つ多くのディスクでRAID-1グループを作成することです（たとえば、2つのディスク、または大きなディスクとハードウェアでソフトウェアRAID-1ハードウェアRAID-5の上にソフトウェアRAID-1を備えた小さいディスクのRAID5）。バックアップを取るときが来たら、ディスクをインストールし、mdadmにそのディスクをraidグループに追加するように依頼し、完全性を示すまで待機し、オプションで検証スクラブを依頼してから、ディスクを削除します。もちろん、

ループバックマネージャを使用して仮想ファイルシステムをマウントできますが、これによりバックアッププロセスが高速化されますが、通常の操作に影響する可能性があります。

別の方法は、ddを使用してデバイス全体をバックアップすることです。たとえば、dd if=/dev/my_device of=/path/to/backup.dd。

おそらくご存知のように、問題は地域性です。通常のディスクシークには10msほどかかります。したがって、ランダムに配置された1,000万のファイルで「stat」（またはopen（））を呼び出すだけで、1,000万回のシーク、つまり約100,000秒、つまり30時間を必要とします。

したがって、シーク時間ではなく、関連する数値がドライブ帯域幅（通常、単一ディスクで50〜100 MB /秒）になるように、ファイルをより大きなコンテナーに配置する必要があります。また、RAIDを使用して帯域幅を増やすことができます（ただし、シーク時間は短縮されません）。

私はおそらくあなたがまだ知らないことを何も言っていないでしょうが、私のポイントは、あなたの「コンテナ」のアイデアが間違いなく問題を解決し、どんなコンテナでもできることです。ループバックマウントは、あらゆるものと同様に機能する可能性があります。

いくつかのオプションがあります。最も単純で、すべてのLinuxファイルシステムで動作するはずddの、パーティション全体（/dev/sdb3または/dev/mapper/Data-ImageVol）を単一のイメージにコピーし、そのイメージをアーカイブすることです。単一のファイルを復元する場合は、イメージをループバックマウント（mount -o loop /usr/path/to/file /mountpoint）し、必要なファイルをコピーします。完全なパーティションの復元では、最初のddコマンドの方向を逆にすることができますが、実際には同じサイズのパーティションが必要です。

あなたのユースケースから判断すると、個々のファイルの復元は非常にまれなイベントであると推測しています。これが、ここでイメージベースのバックアップが本当に理にかなっている理由です。個々の復元をより頻繁に行う必要がある場合は、ステージングされたLVMスナップショットを使用する方がはるかに便利です。しかし、これらの重大な「すべてを失った」災害に対しては、イメージベースのバックアップを行う必要があります。イメージベースの復元は、単にブロックを復元するだけで、すべてのfopen / fcloseでかなりのメタデータ操作を必要としないため、tarベースの復元よりもはるかに高速になる傾向があります。さらに速度が上がります。

代わりに、Googleビデオ@caseyが中途半端に言及しているように、XFSは優れたファイルシステムです（複雑な場合）。XFSの優れたユーティリティの1つは、xfsdumpファイルシステム全体を1つのファイルにダンプするユーティリティtarです。通常は、できる限り速く実行します。これはファイルシステム固有のユーティリティなので、tarではできない方法でfs内部を利用できます。

EXT4をまだ実行していない場合は、まずEXT4にアップグレードすることをお勧めします。

GoogleはEXT4が良いアイデアである理由について多くの研究を行ってきました。

その後、分散ファイルシステムアーキテクチャの展開を検討する必要があります。例えば：

• http://www.xtreemfs.org/
• http://code.google.com/p/kosmosfs/
• http://hadoop.apache.org/hdfs/

おそらく単純な答えかもしれませんが、私が最初に考えたのは、MongoDB上に構築されたGridFSのようなものを使用することでした。主要な言語ドライバーの多くはそのまま使用できるので、コードのファイル読み取りセクションと交換するだけで済みます。また、既存のディレクトリパスをこれらのファイルのキーにするだけでもかまいません。

あなたが持っているかもしれない1つの問題は、Mongoが常にディスクからシークしている場合、かなり速くスローダウンする傾向があるということです。1,000万個のファイルがある場合、データのほとんどはディスク上にあると思われます。私が思い出すように、GridFSのファイルのチャンクは4MBであるため、ファイルがそれよりも大きい場合は、1つのファイルを取得するためにいくつかのコストのかかる操作を行うことになります。重要なのは、すでに整理されたディレクトリ構造に基づいてファイルを分割し、複数のボックスでMongoの複数のインスタンスを実行して負荷を軽減できるようにすることです。ただし、パフォーマンス要件が何であるかはわかりませんので、考え直している可能性があります。

これらすべての利点は何ですか？正しく行われた場合、ディスク読み取りとほぼ一致するパフォーマンス。また、Mongoには、DBインスタンス内の一連のデータ全体を迅速にバックアップするための優れた方法がいくつか組み込まれています。データベースを実行したままでもできます。

データストレージのアプライアンスモデルに満足している場合は、NexentaStorを検討することをお勧めします。OpenSolaris上で内部的にZFSを実行しますが、すべての管理はWeb GUIを介して行われます。

問題の解決に役立つ機能がいくつかあります。

• エンタープライズ版は、ファイルシステム全体をスキャンする必要のないスナップショットに基づくリモート複製の形式をサポートしています。

• 手を汚したくない場合、ZFSには非常に便利なZFS diffコマンドがあり、ファイルシステム全体をスキャンすることなく、最後のスナップショット以降に追加、変更、または削除されたファイルを効率的に通知します。これをバックアップシステムに組み込んで、増分バックアップの実行に必要な時間を大幅に短縮できます。

dump多数のファイルを含むEXT4ファイルシステムをバックアップするための標準ユーティリティを使用できます。このユーティリティは、最初にファイルシステムで使用されているブロックをチェックし、次にディスク順にバックアップして、ほとんどのシークを排除します。

restoreによって作成されdumpたバックアップを復元するための対応するユーティリティがあります。

レベル-最後のレベル0（フル）バックアップから変更されたレベル1バックアップファイル、レベル2-レベル1バックアップから変更されたなどのレベルを使用した増分バックアップをサポートします。

増分バックアップの場合、1つのオプションは、新しいカバー用の2番目のシャドウツリーを持つことです。つまり、すべての読み取り操作に使用されるメインツリーがあります。また、newfiles/012345.....jpgディレクトリがあります。新しく追加されたカバーは、こことメインツリーにハードリンクを作成します。バックアップを実行するとき、メインツリーを時々バックアップできますが、（はるかに小さい）newfilesツリーをより定期的にバックアップできます。

newfilesメインツリーの新しいバックアップを実行する前に、ツリーを小さく保つために、newfilesツリーを空にすることができます。

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

もちろん、これを行うと、メインツリーの新しいバックアップを作成することになります。

通常、少しの並行性を追加すると役立ちます。

あなたと同じような問題があります。私の場合、約3,000万個のファイルをバックアップする必要がありますが、そのほとんどはHTML、PHP、またはJPEGファイルです。私にとっては、BackupPC + sshを介したrsyncは正常に機能します。完全バックアップには約1日かかりますが、通常、増分バックアップは数時間で終了します。

トリックは、各メインレベルディレクトリ（0、1、2 ... a、b、c ...）をBackupPCにコピーする新しいターゲットとして追加し、同時にバックアップを実行できるようにして、同時にディレクトリをバックアップすることです。 a / 、b /、c / *など。ディスクサブシステムに応じて、2〜3個のプロセスから10個程度のプロセスまでが、おそらく最も高速なバックアップ方法です。

LVMスナップショットとブロックレベルのバックアップもオプションですが、BackuPCとファイルレベルのバックアップを使用すると、必要に応じて個々のファイルまたはディレクトリを復元できます。

ベンジャミン、

あなたの問題は、ディレクトリレベルごとのファイル数で対処できると思います！

ディレクトリに20 000個のファイルを保存すると、アクセス時間は大幅に変化しますか？

ファイルシステムのメタデータを別の高速アクセスドライブ（SSDなど）に保存することについても考えましたか？

代わりに、古き良きリレーショナルデータベースをお勧めします。

たとえば、256個のパーティションテーブル（cover_00、cover_01、...、cover_ff）でbytea、外部ストレージを備えた（バイナリ）列として画像データを使用し、ファイル識別子を主キーとして使用するPostgreSQLを使用します。イメージの取得は高速で（主キーのインデックスのおかげ）、データの整合性が保証され（ACID準拠のデータベース）、バックアップはディスクの順序で行われるため、シークはそれほど多くありません。