johnhoh said:
You know earlier I had seen that the robocopy default is 8 threads so I assumed increasing it would not matter much.

But then I saw your post and figured why not give it a try. Here are the results:

- use default (no "MT" switch), backup runs in about a minute
- use /MT:8 (which is SUPPOSED to be the default!), backup runs in about 5 seconds
- use /MT:32, backup runs in maybe 2 seconds.

So we're good to go! Thanks
The default is a bit confusing.

If you do not use /MT switch, there is no multithreading (single thread only).

If you specify /MT but no number, the default is 8 threads.

So to use multithreading, you have to use /MT switch.

Robocopy with multithreading is so much faster than copy, xcopy etc.

Bear in mind, that a lot of copy redundancy may be being bypassed doing this, so if media is say a slow SD card, I would not use multithreading but a ssd should be fine.

In the end, you should check critical files are copied with no corruption.

I accept I may be wrong about copy reliability but it does not do any harm to do some spot checks e.g. if text, use good old fashioned fc command.

Once you are convinced files are copying without corruption, then multithreading is way to go.