robocopy / MIRの代替
小さなxmlファイルに多くのローカルデータを保存する多くのWebアプリを実行しています。バックアップ/リカバリ戦略の一部は、VPNを介してホスティングセンターへのファイルシステムのローカルミラーを作成することです。
VPN接続は12MbpsADSL経由でのみ行われ、ファイルやディレクトリはたくさんありますが、実際に変更されるファイルの数はごくわずかです。
帯域幅が問題になる可能性がありますが、次のような結果が表示されます。 robocopy/MIRの実行には5時間かかりましたが、実際にコピーを実行するのに30分しかかかりませんでした。
これを改善する方法について誰かが何か提案がありますか？現在、5時間は遅すぎます。これを高速化する方法が見つからない場合は、まったく異なる解決策を考え出す必要があります。
Total Copied Skipped Mismatch FAILED Extras
Dirs : 17625 6618 11007 0 0 0
Files : 1112430 1223 1111207 0 0 0
Bytes : 57.451 g 192.25 m 57.263 g 0 0 0
Times : 5:01:23 0:35:55 0:00:00 4:25:27
Speed : 93509 Bytes/sec.
Speed : 5.350 MegaBytes/min.
Ended : Fri Apr 16 05:54:23 2010
Robocopyは、最初にすべてのローカルファイルとリモートファイルを列挙して、転送する必要のあるファイルを決定する必要があります。これはおそらく時間がかかっているものです。
バックアップが成功した後にアーカイブファイル属性をリセットした場合はどうなりますか？
attrib -a /s *
その後、ファイルが書き込まれるたびに、アーカイブビットが自動的に設定されます。次回は、Aフラグが設定されたファイルのみをアーカイブするようにRobocopyに指示できます。
robocopy source destination /mir /a
私はこれをテストしていませんが、Robocopyで処理するファイルがはるかに少なくなるため、より高速になるはずです。
もう1つのアイデアは、リモートサーバーでスケジュールされたジョブを実行して（可能な場合）、ディレクトリ構造全体を圧縮し、結果のZipファイルをVPN経由でコピーすることです。 XMLは適切に圧縮され、単一のファイルをコピーすると、待ち時間の長いリンクを介してはるかに効率的になります。
ブロードバンド接続を介してコピーするためにWindows用のrsyncを使用しています。これはおそらく、各ファイルの変更のみをコピーするデルタコピーシステムですが、robocopyは1ビット変更された場合はファイル全体をコピーします。 （tbhそれが実際にこれを行うかどうか時々疑問に思います）
Robocopy/mon：xスイッチを使用して、永続的に実行することもできます。これは、robocopyがファイルシステムでx個の変更を検出したときに実行されます。非常に頻繁に実行される場合、変更はごくわずかです。
Windows Serverのファイル複製機能を使用し、各フォルダーへのDFSパスを使用して、ローカルフォルダーとリモートフォルダーをターゲットとして設定できます。
2番目にCharlesGargentがrsyncを推奨しました。 CygwinでSSH経由のrsyncを使用しています。正しく思い出せば、cygwinに依存しない実行可能ファイルが利用可能です。
Rsyncがrobocopyに勝る大きな利点の1つは、rsyncエージェントがリモート側で生成され、その側で処理を実行することです。リモートエージェントは、すべてのファイルの詳細をローカルマシンに戻して処理することなく、リモートファイルシステムを検査できます。これはrobocopyよりもはるかに高速であり、おそらく5時間の遅延の背後にあるものです。
Rsync over sshで圧縮を使用することもできます。これにより、処理をさらに高速化できます。
ただし、CygwinファイルシステムACLとWindowsACLはうまく連携しないことに注意してください。 ACLの完全なコピーが必要な場合は、rsyncが適切でない可能性があります。ファイルをコピーした後、ファイルのアクセス許可を「クリーンアップ」するためにxcaclsを実行するスクリプトを作成する必要がありました。
ATTRIBを使用することの欠点に関するXYZのコメントは役に立ちますが、アーカイブビットを選択的にリセットするには、robocopy/MIRコマンドの後にrobocopy/COPY/Mコマンドを実行するだけでは不十分です。 Robocopyは、実際にファイルをコピーしない限りビットをリセットせず、（デフォルトでは）「同じ」ファイルをコピーしません。したがって、
ROBOCOPYソース宛先/ MIR
ROBOCOPYソース宛先/ COPY/M
ソース上の多くのファイルのアーカイブビットは変更されません。 （私はそれが真実でなかったらいいのにと思います。）
Robocopyのソースコードがさらに微調整される可能性は低いですが、作成者が/ MIRに「this」を提供してアーカイブビットを一度にリセットできるようにしたいと思います（例：/ MIR：A）。これは、新しいシステムでバックアップを開始するために最も重要ですが、いずれにしても、robocopy/MIRが「完全な」バックアップソリューションではないことを示しています。
Attrib -a/sを使用してrobocopyの不足を回避することに関する注意事項。このソリューションを使用する場合は、フルバックアップを実行する前に実行してください。すなわち。通常、完全バックアップには多くの時間がかかり、一部のファイルは、バックアップされてからattribを実行するまでの間に変更されている可能性があります。これは、後のコピーでそれらの変更が失われることを意味します。
このソリューションに関する2番目の注意点は、コピーがフィルタリングされていない場合にのみ適切に機能することです。一時ファイルや同様のゴミを避けるためにバックアップまたはrobocopyプロセスをフィルタリングする場合、attribがコピープロセスが参照するファイルのみを参照するようにする簡単な方法はありません。あれは;実際にコピーしていないファイルの属性を変更しているのですが、それはあまり良い考えではありません。
そのrobocopyが従来の完全バックアップを作成できないように見えるのは魅力的です...または1回の実行ではできません。あなたはそれを2回実行することによってそれを行うことができます。一度すべてをコピーし、次に/ Mを使用してコピーします。今回は、実際にアーカイブビットをリセットします。なんてピタ。