ロボコピーは中止後に再開されますか？
私のusersディレクトリのサイズは58 GBで、Windowsリカバリから Robocopy を使用してポータブルUSBバックアップドライブにコピーしています。
robocopy G:\Users\ E:\Backup\T420\ /MIR /SEC /MT:32 /V /LOG:G:\bak\robocopy.txt
ラップトップはUSB 2で、バックアップドライブはUSB 3です。
現在、18時間以上稼働していますが、私の予想よりも長くなっています。
USB 2の速度が遅い場合でも、約8時間しかかかりません
https://www.wolframalpha.com/input/?i=58+gB+at+2+MB%2Fs
押すと Ctrl-C ログを調べて何が起こっているかを確認し、コマンドを再度実行します。同じ時間がかかるのか、中断したところから再開しますか？
それが再開すると仮定すると、どのファイルをコピーしてどこから再開するかを決定するには、どのような時間のオーバーヘッドがありますか？
[〜＃〜] edit [〜＃〜]：非常に時間がかかった理由は、いくつかの偽造/完全ではないことが原因であることが判明しましたコピーできなかった同期されたOneDriveファイルおよび 100万回の再試行のデフォルト値 。再試行と待機を変更すると、完了が許可されました/r:2 /w:5
フォルダーに非常に多数のファイルが含まれている場合、ソースとターゲットの両方で、ディスクカタログへの頻繁なアクセスに必要な実際に長い時間がかかります。
さらに、USB2ポートのUSB3ディスクはUSB2の速度で動作します。 USB3ディスクは、最初のハンドシェイクを行うときに、ポートとそのプロトコルに適応します。
マルチスレッドに/MT:32を使用しているため、robocopyに32ファイルを一度にコピーするように指示しています。これにより、32スレッドがディスクへのアクセスを争い、さらにディスクのヘッドがディスクを行き来することで時間を浪費して、コピーをさらに遅くします。遅いUSB2コピーの場合、マルチスレッドは推奨されません。
再起動可能モード/Zを使用して、部分的にコピーされたファイルを処理します。このオプションを使用すると、特定のファイルが部分的にコピーされるようにコピーが中断された場合、robocopyの次回の実行で、ファイル全体を再コピーするのではなく、中断したところから再開できます。残念ながら、このスイッチによってコピーの速度が低下する場合があります。
is操作の途中でRobocopyを停止しても問題ありません。
デフォルト すでにコピーされているファイルは再コピーされません。
どこから再開するかを決定する（または基本的にどのファイルが同じかを確認する）ためのオーバーヘッドは非常に低く、わずか数秒です。
ただし、ログに書き込まない場合（または/TEEを使用してコンソールにも書き込む場合）、/Vを使用すると、すべての行をコンソールに書き込むのに時間がかかるため、このオーバーヘッドが増加します。
[〜＃〜] nb [〜＃〜]：（コメントに記載されている）再起動可能モードは、個々のファイルを再起動するためのものです（たとえば、ファイルは途中で停止し、ファイル全体を再度コピーする代わりに途中で再開できます）、質問で尋ねられたようにバッチコピーを再開するためには必要ありません。
私は何年もrobocopyを使用してきましたが、ファイルの途中でコピーを停止でき、再起動すると中断したところにすばやく戻ることがわかります。 /XNオプションを使用しない限り、robocopyは、最後に作業していたファイルをすべて削除し、コピーを再開します。最初にファイルを作成するとき、「変更」時間は1/1/1980に設定されるため、基本的に時計が正しく設定されていれば、その時間が表示され、コピープロセスが再開されます。あなたが述べたように、他のファイルはソースファイルと同じ修正日時を持っているので無視されます。
個人的には、robocopyを使用するときは常に/TEEオプションを/Vおよび/LOG:オプションと一緒に使用して、何が起こっているのかを監視できるようにします（クラッシュした場合）発生した場合は、戻って問題があったかどうかも確認できます）。極端に大量の小さなファイル（数万以上）がある場合は、少し遅くなりますが、問題があるかどうかを判断するのにも役立ちます。高さを小さくするか、コマンドプロンプトウィンドウを最小化すると、小さなファイルがたくさんあるときにコピーを大幅に高速化できます。
コピーしようとしている量に対して18時間は非常に長いので、コピーしようとしている非常に多くの小さなファイルがあるか、ディレクトリ構造に何らかの再帰がある可能性があります。ログがあるので、ログの下部を見て、ディレクトリ構造が繰り返されているかどうかを確認してください。ある場合は、/XJDでジャンクションポイントをスキップして、スタックしているループを停止できるかどうかを確認します。/XDオプションを使用して、特定のディレクトリを完全に無視することもできます。 。
/Zオプションについては、このオプションは「ネットワーク転送」に対してのみ機能します。ローカルコピーは再起動可能なモードを使用しないため、引用符で囲みます。ただし、robocopyがネットワークパスを検出した場合、ソースと宛先がローカルであっても、再起動可能モードを使用します（これは、私のバージョンのrobocopyである可能性があります。 7）。ドライブまたはドライブ上のフォルダー（できれば、自分だけがアクセスできるアカウント）を共有し、Change権限を有効にし、そのパスを宛先として使用する場合は、再起動可能なモードで動作します。確かに、再起動可能モードを使用すると、パフォーマンスが低下する可能性があります。
Robocopyを停止してもよろしいですか？
Robocopyタスクを問題なく終了することがよくあります。プロセスが強制終了された場合、私が覚えている限り、コピーされていたファイルは（a）1980-01-01のタイムスタンプ（b）元のファイルと同じサイズになります。
それが再開すると仮定すると、どのファイルをコピーして、どこから再開するかを決定するには、どのような時間のオーバーヘッドがありますか？
これらのパラメーターを使用してタスクを再度開始すると、（a）すでにコピーしたファイルをスキップします（b）日付の不一致のために中断されたファイルを再コピーします（c）以前に試行しなかったファイルをコピーします（d）/MIRスイッチが原因でソースに存在しなくなったファイルを宛先から削除します。
時間がかかった理由は...
プロセスを強制終了する前に、ログファイルをテキストエディタで開いて、プロセスの動作を確認できます。最後の行には、コピーするファイルとそのサイズが含まれます。エラーが発生した場合は、次のように表示されます。
2019/12/13 06:26:38 ERROR 32（0x00000020）Copying File C：\ Redacted
別のプロセスによって使用されているため、プロセスはファイルにアクセスできません。60秒待機しています...再試行しています...
コピーが成功すると、ログファイルには、転送速度（メガバイト/分）を含む概要が含まれます。これにより、次回の所要時間がおおまかにわかります。
この回答は：
現在、18時間以上稼働していますが、私の予想よりも長くなっています。
USB 2の速度が遅い場合でも、約8時間しかかかりません
robocopyの可能な代替案を提案します
転送速度チェック：
他の人たちは予想よりも遅い速度の考えられる理由に対処しました。
現在の速度：
ターゲットドライブの空き領域の変化率に注目すると、現在のコピー速度がわかります。チェックの間隔を約10秒にしてこれを行うと、1分とすると平均が良くなります。
これは、適切なWindowsツールを使用して、または私の好みのオプションを使用して、今日「DOSウィンドウ」として渡されるものを使用して行うことができます。
dir target:\
適切である必要があります。
現在までの転送速度：
たとえば、これまでにコピーされたファイルの数とデータボリュームを確認できます。
dir target:\destination_folder /s
これにより、dirプロセス中のコピー速度が遅くなります。
結果の大部分がキャッシュされるため、後続のDIRは通常より高速になります。
転送速度の妥当性：
58 GB/18時間は1 MB /秒をやや下回り、USB2からUSB3へのコピープロセスでは低い値です。転送された実際のファイルのサイズは上記のようにアクセスできます-レートが1 MB /秒よりもはるかに遅いかどうかを知ることができます。
私が最近のマシン（OK i7）で経験した最悪のケースの転送速度は、501 MB /秒でした。
可能な（のみ）が役立ちます：
Robocopyについてはよく知りません。
私は非常に古い（2001）バージョンのXXCOPYを同様の目的で使用しています。これはうまく機能し、ライセンス条項が私のニーズに合っているためです。 XXCOPYにはフラグ "/ nX0"があり、場合によっては、短縮名の保存機能が無効になります。状況によっては、これにより転送速度が非常に速くなります。 Robocopyのいくつかの同様の設定が役立つ場合があります。
また、Ye Olde DOS Substコマンドを使用して、ソースと宛先のパスをダミーのドライブ文字に割り当てます
eg subst a: pathname
これにより、非常に長い（愚かな）長いファイル名のファイルを含め、通常はコピーに失敗する一部のファイルのコピーが可能になります。
============================
可能性があります。
Robocopyの使用に関する質問。
次のスクリプトは、XXCOPYを使用して同様のタスクを実行します。
既存のファイルは再コピーされません。
Y：およびZ：は、特定のコピーエラー（ファイル名tooooooooo long）を排除するために、直接のソースおよび宛先パラメーターの代わりに使用されます。
これが機能する理由はわかりませんが、機能します。
subst y: /D ; release mapped drive
subst y: Src_Drive:\source_path
subst z: /D ; release mapped drive
subst z: Dest_Drive:\destination_path
**xxcopy /bb /s /h /nx0 y:\*.* z:\**
rem /bb - if not exist
rem /s - all subdirs
rem /h - incl hidden files
rem nx0 - don't preserve short file name
premise-challenge をここに少し書きます。遅いコピーのフラストレーションを理解していますが、コピーを中断しても、コピーの進行状況を確認できません。
ディスクI/O履歴グラフを確認する
パフォーマンスモニターを起動し、ディスクI/Oアクティビティの履歴を確認します。システム静止状態でこれを行う必要があります。それが他の多くのことをしているなら、あなたはそれのディスク活動を見ている可能性があります。ただし、それはとがります。チャート全体に存在する「ベースライン」アクティビティを探しています。 MacのMineは、それを読み取りと書き込みに分割します。明らかにあなたは書き込みを見ています。 （他のほとんどのアクティビティは読み取りです）。
古いMacバージョン。 Windowsの方が堅牢です。最初の塊はコピーを計画するrsyncで、2番目の塊は3つのファットMP4ビデオファイル、最後の塊は膨大な数の小さなファイルです。
私の経験では、実際には、このバーはかなり上下にジャンプします。大きな単一ファイル（ビデオおよびTIFFファイル）をコピーする場合、ハードウェアの最大スループットが何であってもペグします。*
しかし、膨大な数の小さなファイル、MBpsスループットタンクをコピーする場合は、ドライブが各ファイルのディレクトリエントリを読み取る（および書き込む）必要があるためです。フラッシュメモリキーフォブにヘッドシーク時間とセクター待ちの遅延がないが、物理ハードドライブにある-bigtime。ハードドライブと堅牢なOSには、痛みを和らげるためのいくつかの戦略がありますが、それでも大きな痛みがあります。
- これが、小さなファイルのすべてのコレクションをZipパッケージ、tarball、またはディスクイメージに変換する理由です。
宛先ドライブに到着するファイル自体を見てください
ウィンドウ（またはコマンドプロンプト）を使用して、宛先ディレクトリを参照します。コピーの「最先端」、つまり現在追加されているディレクトリを見つけます。アクティビティを見て、それが正常かどうかを確認します。
ハードドライブを聴く
あなたのドライブが行くなら
ダニ...ダニ...ダニ...
それはうまくいっているコピーです。ドライブは、最大の利点を得るためにフォーマットされたセクター配置を使用して、大きなブロック転送を行っています。
シッキタシッキタシッキタ
それはディスクスラッシュです。バックアップに問題があり、スループットが低下しています。その音は、ドライブがヘッドを探していることを意味しますたくさん-そしてヘッドが動いているとき、それはコピーしていません。さらに悪いことに、それが到着すると、安定してから、希望のセクターが出現するまで平均0.5ディスクのプラッター回転を待つ必要があります。ドライブは5400〜10,000 RPMで回転するため、シークごとに3〜6 msです。
実際、前の図では、太いセクションではマウスのようにドライブが静かで、後のセクションではシックキタでした。
たとえば、大きなバックアップの最中に、550万個の小さな（30〜500バイト）ファイルのネストがあったとします。ドライブが第一次世界大戦の乱闘のように聞こえ始めたとき、私はグラフをチェックし、悪いニュースを見ました。そのレートでは、コピーは数日かかったでしょう。
そこで私はアプリを終了し、十分なRAMディスクを作成し、5.5MファイルをRAMディスクにコピーしました。 HDDからの読み取りでは、これはディスクキャッシュの恩恵を受けました。もちろん執筆は一瞬でした。 これには30分かかりました。次に、ハードドライブにZipファイルとして書き戻しました。Zipファイルは1つの連続したデータストリームとして書き込んだので、「tick ... tick ... tick ...」と書きました。それはさらに速かった。
5.5Mファイルの削除には時間がかかりましたが、Zipファイルのバックアップは1分もかかりませんでした。 1日で大幅な改善！
コピーを中断するタイミングに関しては、上記がコピーが正しく機能していないことを示しており、それを修正するための計画があるか、実験したい場合に行います。
決して、これまでに、これまでにないマルチスレッド
メーターは、ビデオのような単一の大きなファイルをストリーミングするときに最高のスループットが得られることを示しています。ドライブのセクター最適化はピークパフォーマンスで機能しています。次に必要なセクターは、必要に応じてディスクヘッドの下に表示されます。
ただし、2つの大きなビデオを同時にコピーするとします。 ディスクは両方を同時に実行しようとしています：ビデオ1にシークし、ブロックに書き込み、ビデオ2にシークし、ブロックに書き込み、ビデオにシークします1、ブロック、悪心を書きます。突然、私たちは書く代わりに求めているのですが、スループットは明白なことをします。
だからそれをしないでください。そして、ディスクI/O履歴チャートがその理由を教えてくれます。
たとえば、内部HDDから外部2に「rsync」します。外部1から外部2にもrsyncします。これらはすべてスクリプトで設定されます。私は両方を同時に実行することはしません。なぜなら、それらは外部2をめぐって戦い、両方のコピーの速度を低下させるからです。
今あなたがやったこと、/MT:32、それをスレッドに伝える一度に32コピー、これは私がここでやらないように言っていることそのものです。 *おそらく、マルチスレッドがハイブリッド、RAM=ディスク、RAID、または特定のデータセットでニースを再生する優れたエレベーター探索アルゴリズムに役立ちます。それはここにあるように聞こえません。しかし、 、自分の言葉を使わないでください-グラフを使用して実験し、yourのハッピーナンバーを見つけます。ハードウェア（私が完全に期待するのは "1"です）。
* a）コンピュータUSB、b）デバイスUSB、c）読み取りドライブのスループット、およびd）書き込みドライブのスループットの最低値。