WindowsからUnityへのrobocopyによる移行を検証しています

中の人でなくて恐縮ですが、
実行結果でどのクラスになっていますか?
(Modifiedなのか、NewerやOlderなのか)
コマンドベースで恐縮ですが、当方の環境と少し見比べました。
/Rと/Wは改善しないことが多い(大体がユーザが開きっぱなしとか別のエラー)なのでどちらも0にしちゃって頻発するようならファイルを調査することが多いです
/NFLもログが小さくなるのでおすすめです
あと/ITを使っています。
最後に/MTですがこちらは値の指定が必要でして、設定しないとパフォーマンスがでないことが多いです。
コピー専用で実行している端末であれば実行元の物理コア数前後でまず動かしてみて、CPUに余力や他のサービスに影響が出なければ値を増やすと速度改善することが多いです。
(私は最初6くらいにして全然負荷掛からなかったので最後32くらいまで引き上げました。)

ありがとうございます。

ログファイルの表示は 「更新済み」です。

→実際は何も変更していない。

切り分けのためWindows→Windowsで実行した場合は事象が発生しません。

@piroshiki​ さん
Modifiedですね。
結構厄介なクラスになり、改善は難しいかもしれません。
移行先がLinuxのときに発生する内容らしく私もPowerSacleへのコピーで発生しました。
Trafficなどを確認してもらうと実際にファイルをコピーしていそうなTrafficが流れていますか?
当方で発生したときにはファイルが流れているほどの状況ではなかったです。
MFT更新時刻が一致しないで発生するというのが有志のブログで記事がありますが、解決までには至らなかったです。
コピーが遅くて困ってる状況下と思うのでまずはMTオプション見直すとマシになると思います。

その時のスレッドはこちらです。
VNXeからPowerscaleへのロボコピーについて
解決していないので役立たずかもしれませんが。。

@bf000 さん
ありがとうございます。

いただいたスレッドを確認してみます。

なお、トラフィックを確認したところファイルはコピーしていないようです。

1Gのファイルをfsutilで作成しています。

一回目

      バイト:   1.000 g   1.000 g         0         0         0         0
       時刻:   0:03:59   0:00:59                       0:00:00   0:00:59

二回目

      バイト:   1.000 g   1.000 g         0         0         0         0
       時刻:   0:00:00   0:00:00                       0:00:00   0:00:00

@piroshiki​ さん

テスト状況の共有ありがとうございます。
差分チェックのみを実施していて、実際はコピーしていない状況ですね。
当方の環境で発生したときと同じに感じています。

お客様とどういった方針で進めているか次第ですが、一般的には
NTFSアクセス権
実データ
更新日時
このあたりがコピーされていることが必須条件で、MFT更新日時などのメタデータはある意味オプション(活用されていない)ケースもあるかと思います。
本来はSAMEでコピーが終わるのが一番スッキリしますが、現状改善難しい内容になるので、
テスト移行実施後に運用確認等を実施してMFT更新日時が一致していなくても問題ないようであれば可とする方針で進めても良いかもしれないです。

@bf000 さん

ありがとうございます。
MFT更新日時という観点を持っていなかったので非常に助かりました。