CentOS / Debianおよびたくさんの（200k）小さなハードコピーファイルのbackuppcにどのファイルシステムを使用する必要がありますか？
私が尋ねる理由は、/ backupsの個別のraid1ext3バックアップディスクを使用したバックアップにrsnapshotを使用するためです。残念ながら、バックアップの削除（4時間ごとに発生）には最大1時間かかります。 rm -rf /backups/server/hourly.5は非常に時間がかかりますが、ほとんどのデータはハードリンクで埋められているため、ハードリンクを削除するだけです。
ZFSは素晴らしいですが、新しいバックアップサーバー用にBtrFS、XFS、または単にext4を考えています。 ZFSはLinux環境での本番環境にはまったく適していないため、これはオプションではありませんが、はるかに優れたfsのようです。今回は、rsnapshotの代わりにCentOSまたはDebianのBackupPCをソフトウェアとして使用します。 Baculaを検討していましたが、BackupPCに勝るメリットはないようですが、設定が難しく、エージェントをインストールする必要があります。
ハードリンクをすばやく削除するFS）が欲しいのですが、実際にはデータに何も起こらないので、なぜこれに1時間かかるのかわかりません。
バックアップに関する一般的なアドバイスは大歓迎ですが、高速で本番環境の準備が整ったファイルシステムを使用したバックアップにbackuppc、raid1を使用すると、良好なバックアップ環境が得られると思います。
XFSは、少なくともO(1)でファイルを削除しますが、ext（mumble）ファミリはO(log n)（nはファイルのサイズ）にあります。それが大量のリンクの削除にどのように変換されるかはわかりませんが、それは始まりです。
ファイルシステムにext4を使用しています。 relatime（相対時間）を使用して、ファイルを削除するときのディレクトリへのiノードの更新を最小限に抑えてください。
複数のディスクに書き込む必要があるため、レイド書き込みは読み取りよりも遅くなる傾向があります。これは、ジャーナルの書き込みによって悪化します。別のディスクセットで外部ジャーナルを使用してみてください。
ファイル数が多いディレクトリからファイルを削除すると、ファイル数が少ないディレクトリからファイルを削除するよりも大幅に遅くなる傾向があります。これは、より多くのディレクトリブロックを書き込んだためだと思います。ただし、これを修正するには、バックアップするディレクトリの割り当てを修正する必要があります。多数のファイルがあるディレクトリは、多くのアプリケーションで問題を引き起こしました。
しばらく前に、RAID1とLVMを使用してDebian LennyにBackupPCをインストールし、Reiserfs（noatimeオプションでマウント）を使用することを選択しました。私はext4を使用したかったのですが、当時、Lennyのext4サポートはまだ少し...新しいものでした。 BackupPC FAQ ext3ではなくReiserfsを使用することをお勧めします、それでそれでした。
とにかく、これまでのところ問題はありません。 Reiserfsは非常に堅実です。 BackupPCの動作方法では、ファイル/ハードリンクの削除のパフォーマンスについてあまり心配する必要はないでしょう。これは、BackupPCがクリーンアップジョブをバックアップと復元とは別に（ただし、必要に応じて同時に）実行するためです。クリーンアップジョブの実行時間が長すぎたり、通常の操作に干渉したりする問題が発生したことはありません。
私の場合、より重要な考慮事項は、ファイルシステムが多くの小さなファイルをどれだけ効率的に処理するかです。どうやら、Reiserfsは、いわゆる「ブロックサブアロケーション」（または「 テールパッキング 」）によって内部の断片化を最小限に抑えるため、これに非常に適しています。それでも、今日もう一度選択する必要がある場合は、おそらくext4を使用します。ほとんどのLinuxカーネル開発者が実行しているのと同じFSを実行することの利点は、ニッチFS（Reiserfsなど）がもたらす可能性のあるマイナーな技術的利点をおそらく上回ります。