BackupPC250GBのバックアップに72時間以上かかる
BackupPCを使用して、オフィスのいくつかのワークステーションをバックアップしています。特に1つのワークステーションには、他のワークステーションと比較してかなりの量のデータがありますが、一般的にはそれほど大きくありません（実際のデータは約250 GBです）。
BackupPCは、このシステムをバックアップするのに永遠にかかるようです（数日、つまり72時間以上）。すべてのワークステーションは、ネットワーク上のrsyncローカルマウントを介してautofsを介してバックアップされています。
基本的に、autofsはadministrative C shareをワークステーションにマウントし、次にBackupPCはそれをローカルディレクトリとして扱い、cdはautomount directoryに、そしてrsyncはすべてのデータです。
それは一般的に遅いです、そして私は一般的にそれを遅いハードウェアであるBackupPCボックスに帰しました、しかしこのパフォーマンスはデータ量が多いこれを除いてすべてのワークステーションで多かれ少なかれ許容できます。
rsync flags:
/usr/bin/rsync --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive
これらは、BackupPCが設定されるデフォルトの引数です。
マウントのatimeが速度を低下させている可能性があることを示すものをオンラインで読んだので、autofsフラグを使用してディレクトリをマウントするようにnoatime構成を変更しました...変わりはない。
rsyncがファイルのチェック方法のせいで原因である可能性があることを示したものをいくつか読みました...代わりに、tarに切り替えることを提案しました。だから私はしました...しかし違いはありません。
tar flags:
tarPath="/bin/gtar"
env LC_ALL=C $tarPath -c -v -f - -C $shareName+ --totals
# where $shareName is the autofs mounted directory
これらは、BackupPCがセットアップされるデフォルトの引数です。
変化なし。
BackupPCボックスのネットワークアクティビティをiftopで監視すると、しばらくの間（場合によっては最大90Mbps）使用量が急増するようですが、その後Kbpsまたは時々Bpsの範囲です。低速モードでは、topはバックアップジョブであるコマンドBackupPC_dumpでアクティビティを表示します...そのため、処理が実行され、スタックしません。
現在のバックアップは24時間以上実行されていますが、iftopによると75.9GBしか転送されていません。
サーバー上で直接rsyncを実行する方が速い場合があります。ネットワーク経由でアクセスするファイルは約100万個あります。実行できるrsyncの最小限のインストールがいくつかあります。私はセットアップしました Windows上のBackupPC このように。 Cygwinの完全インストール、またはBackupPCプロジェクトで利用可能な最小限の cygwin-rsycnd インストールを実行できます。
Backuppc構成の両側ですべてを確認する必要があります。まず、サーバーを確認してパフォーマンスを向上させますが、パフォーマンスが向上する他のマシンがある場合は、これをスキップします。
次にネットワークをチェックしてください！デスクトップによって検出されたネットワーク速度、パッケージサイズ、ケーブル品質。いくつかのベンチマークを実行し、大きなファイルのrsync（rsync-rsyncd）テストを実行します。他のデスクトップから他のデスクトップにテストします。そこに問題があるかどうかを確認する必要があります。
最後にデスクトップ。マシン上のCIFSは最適な状態ではない可能性があり、前述のように、ネットワークファイルシステムからのrsyncは、ファイルシステムがローカルであり、ファイルのmd5をチェックするため、ネットワーク経由ですべてのファイルを何度もダウンロードします。 ..しかし、ファイルはネットワーク経由でフェッチする必要があります。そのチェックを行うだけです。したがって、BillThorが指摘しているように、デスクトップ上の1つのrsyncdの方がはるかに効率的です。また、チェックサムキャッシュは、backuppcサーバーがファイルをチェックしないようにするのに役立つため、負荷が軽減されます。デスクトップをデフラグし、不要なファイルを削除（または除外）します（ウィンドウには、いたるところに多くの役に立たないファイルがあります）。
最後に、ファイルの数...多くのファイルはネットワークを介したバックアップに時間がかかるため、1つの大きなバックアップではなく、小さな部分に分割してください。一部のファイルは他のファイルよりも変更が多いため、変更の確率でディレクトリをグループ化します。 x日ごとに1つの大きなバックアップを作成する代わりに、3つのバックアップを作成します。1つはX日、もう1つは2 x日、更新の少ないファイルはたとえば3x日です。これにより、すべてのファイルを常に解析する必要がなくなります。 「アーカイブ」ファイルがある場合は、圧縮を検討してください。圧縮可能でなくても（Zipストアを使用）、バックアップ時間中にわずか1 ...大幅な節約で10.000になります。
それができない場合は、バックアップ方法を変更することを検討してください。多くのファイルがある巨大なマシンで ドライブスナップショット を使用してHDイメージを作成し、定期的に増分スナップショットを作成しました。やり過ぎに見えるかもしれませんが、そのプログラムはブロックレベルでインクリメンタルを高速に実行し、多くのファイルの問題を回避します。私にとっては、48時間のファイルシステムバックアップを3時間のバックアップブロックレベルに削減しました。 backuppcほど柔軟ではありませんが、機能します。デフラグを実行するときは、完全バックアップを再度実行する必要があることを忘れないでください。そうしないと、増分が完全バックアップと同じ大きさになります。 :)
windowsからバックアップする方法については this ブログ投稿を確認してください（シャドウコピーのボーナス付き）。私はそこに多くの重要な情報と更新を追加するので、すべてのコメントを読んでください。