web-dev-qa-db-ja.com

Robocopy-変更済みとしてマークされたすべてのデータ

次のスクリプトを使用して、フォルダ(かなり大きい-約400GB)をNAS EXT4ファイルシステムで)にバックアップします。

robocopy "Source_Directory" "\\NAS\Destination\Directory" /MIR /FFT /COPYALL /W:5 /r:10 /log:"C:\RoboTest\robotest.log"

調査によると、時差を補うために/ FFTスイッチが必要です。ただし、問題は引き続き発生し、すべてのファイルが変更済みとしてマークされます。

これに関するどんな助けでも大いに感謝されるでしょう。

1
joebegborg07

あなたは付け加えられます /a-:a robocopyコマンドラインに移動して、プロセス中にアーカイブビットを削除します。

1
user534618

たくさんの試行錯誤の末、私は理由を見つけたと思います:アーカイブ属性。

Robocopyは、Archive属性が設定されたファイルを見つけると、そのファイルをログに「変更済み」として体系的に表示し、ファイルサイズを宛先にコピーされたデータの合計量(コピーされた列)にカウントします。ただし、これは誤解を招く可能性があります。ファイルが実際に変更されていない限り(たとえば、タイムスタンプが新しい場合)、Robocopyは実際にはファイルをコピーせず、代わりにスキップします。

大きなファイルで試してみてください。ソースツリーに大きなファイルを追加します。これは、宛先サーバーに転送するのに時間がかかります。初めてRobocopyを実行します。ログでファイルを「新しいファイル」としてマークし、転送が完了するまで少し時間がかかります。次に、attrib +a <filename>コマンドを使用して、そのファイルにアーカイブビットが設定されていることを確認します。もう一度Robocopyを起動します。 「変更済み」と表示されるはずですが、この2回目の実行がはるかに高速であることに注意してください。Robocopyは実際にはネットワーク経由でファイルを再度転送しませんでした。次に、最後に、attrib -a <filename>でアーカイブビットを削除し、最後にもう一度Robocopyを実行します。期待どおりにファイルをスキップします。

残念ながら、Microsoft独自のドキュメントページでも、この動作がドキュメント化されている場所は見つかりませんでした。 (誰かがそうするなら、私たちに知らせてください!)

解決策は、ログで「変更済み」とマークされたファイルを無視するか、Robocopyを実行する前にソースファイルでattrib -a /sを実行することです。

何人かの人々がMicrosoftフォーラムで 報告されたthisproblem を持っています。

0
jcharaoui