すばやく大容量ファイルシステムのバックアップを作成する[閉じる]

割り当てられた24時間以内に300 GB全体をバックアップできないと判断したので、要件を確認する必要があります。

starファイルレベルでは、、、duplicityまたはrsync/などの増分ツールは、デフォルトのバックアップrsnapshotを作成するためにまだ1日以上かかることがありますが、それ以降ははるかに高速になります。明らかに、これは各24時間のバックアップサイクル中に変更されるファイルの数とサイズによって異なります。

ファイルシステムレベルでは、スナップショットだけで十分です（実際にはバックアップではありません）。これは、バックアップの完了にかかる時間についてあまり考えずに、スナップショットから実際のバックアップを作成できるためです。以前と同様に、デフォルトのバックアップが設定されると、増分バックアップを作成するのにはるかに少ない時間がかかることがあります。

バックアップの保存方法を指定していませんが、多くの小さなファイルの場合は、この方法がrsnapshot適切な場合があります。 （回復のために個々のファイルに簡単にアクセスできるため、多くの内部ファイルサーバーのファイルベースのバックアップに使用します。）

ただし、同じホスト上の他のディスクへのバックアップは、実際に安全なバックアップと見なすべきではありません。他のホストへのフルバックアップがはるかに優れています。 （/home/fs_backup他のサーバーからリモートでマウントする場合は、リモートでマウントされたファイルシステムを介してではなく、リモートホストと直接通信またはduplicity使用rsyncすることを深刻に検討してください。）rsnapshot

私が知っている最速のバックアップ方法は使用することですstar（このプログラムの最新バージョンは参考資料を参照schilytools）。これは、プログラムがファイルシステムプロセス間に配置され、異なるプロセス間でアーカイブI / Oを実行するランダムサイズのリングバッファを実装するためです。 。 FIFOサイズを正しい方法で選択すると、read()単一のシステムコールを使用してほぼすべてのファイルを読み取ることができるため、（最適化されたコードで）速度が非常に高速になります。

このリングバッファはFIFOデフォルトで呼び出されて使用されますが、8MB任意のサイズを使用するように指示できます。最大有効値はRAM機械内使用量の半分です。

starジョブ増分ダンプもサポートされます。まず、完全なダンプを実行してから、最後のステップでほとんど時間がかからない方法でファイルシステムの内容を保存するために増分ダンプを実行することをお勧めします。

マニュアルページを確認したい場合があります。http://schilytools.sourceforge.net/man/man1/star.1.html

このマニュアルページでは、ライブファイルシステムではなくsnapshotファイルシステムレベルでバックアップすることをお勧めします。