Windows file copy pausing

Ok, to make the 3rd-level backups I keep offsite, I end up copying a single large (1.2TB) file from one USB drive to another...typically takes about 3 hours and change. About half the time, at some point during the process, it will pause as shown below. I can resume it, sometimes it will finish, sometime pause again, never fails to (eventually) copy the file. It does not seem to be correlated to whether I'm using the computer during the copy (I usually don't), and I've tried all the obvious power settings, including preventing screen shut-off. (And no, the computer is not going to sleep.)

Win10, all updates, i7 desktop. Any clue what's going on?
Attachment 479245

Windows 10? Is the computer online? One bad guess would be Microsoft may be invading your computer and pausing the copying--

Could the pause be to give the drives a chance to cool down? I was noticing the other day my portable Sandisk 1tb SSD gets surprisingly warm at times...

--Have you checked your event logs? May be a clue there?

Quote:

---

Originally Posted by Kev Williams

Windows 10? Is the computer online? One bad guess would be Microsoft may be invading your computer and pausing the copying--

Could the pause be to give the drives a chance to cool down? I was noticing the other day my portable Sandisk 1tb SSD gets surprisingly warm at times...

--Have you checked your event logs? May be a clue there?

---

Possibly a pause to cooldown one or both of the USB drives, but nothing relevant shows in the logs and no error messages showing anywhere. Anybody know a way offhand to access the SMART logs on the drives themselves?
They're both warm, but not that warm. And no way to tell which of the two (if either) triggered the pause.

Re accessing SMART data. There are people more knowledgeable than me about this stuff but smartctl run from a live USB is fairly informative. I don't know that smartctl comes prepackaged by most distros but perhaps starting the live USB (I'd suggest Linux Mint) then downloading smartmontools (www.smartmontools.org) and running it might prove informative. There is a GUI for smartctl called GSmartControl, I don't know how or if it can be run from a live USB. There is probably a simpler Windows solution but I don't know of them.

A couple of things to try (SWAG):

1. Disable Antivirus. A long shot, but maybe.

2. Update the drivers for the device. Technical and annoying to do if you do not know how. Might help.

3. How is the target drive formatted? Default formatting is probably FAT-32 or FAT-16 depending on size. I understand this happens less often with NTFS formatted drives, so you might want to give that a try.

4. Do you see the same behavior when you copy from the command line rather than the GUI? Do you know how to copy from the command line?

5. Sometimes running check disk against the drive can help; sometimes not. Seems silly but maybe.

6. Defragment the drive? I would not expect this to help if it is a thumb drive or SSD since that should auto-fragment to help with wear leveling; well I assume it should, but it was a suggestion I do not put much faith in.

7. By default write caching is disabled for external drives on Windows 10. You can enable it from the device manager (under policies tab I think).

8. One person recommended disabling Remote Differential Compression because it can consume significant CPU cycles, but it seems unlikely this would be used for a file copy so should only eat the CPU if you were using it while connection to something else. And if you have a newer computer it should not matter at all. So, seems silly, but this is set on the windows features.

Quote:

---

Originally Posted by Andrew Pitonyak

A couple of things to try (SWAG):

1. Disable Antivirus. A long shot, but maybe.

2. Update the drivers for the device. Technical and annoying to do if you do not know how. Might help.

3. How is the target drive formatted? Default formatting is probably FAT-32 or FAT-16 depending on size. I understand this happens less often with NTFS formatted drives, so you might want to give that a try.

4. Do you see the same behavior when you copy from the command line rather than the GUI? Do you know how to copy from the command line?

5. Sometimes running check disk against the drive can help; sometimes not. Seems silly but maybe.

6. Defragment the drive? I would not expect this to help if it is a thumb drive or SSD since that should auto-fragment to help with wear leveling; well I assume it should, but it was a suggestion I do not put much faith in.

7. By default write caching is disabled for external drives on Windows 10. You can enable it from the device manager (under policies tab I think).

8. One person recommended disabling Remote Differential Compression because it can consume significant CPU cycles, but it seems unlikely this would be used for a file copy so should only eat the CPU if you were using it while connection to something else. And if you have a newer computer it should not matter at all. So, seems silly, but this is set on the windows features.

---

In order...
1. Unlikely, but I'll try whitelisting the file type, Don't need the computer wasting time scanning it in any case.
2. They're just generic Seagate drives using the default USB drivers.
3. Both are formatted NTFS. Seems like that's already the default these days for anything over 1TB or so.
4. Haven't tried it from the command line. I know xcopy is (or used to be faster) but it didn't seem like there was any point for a single-file copy.
5. Ran chkdsk on both a week or so back when there seemed to be a lot missing space on the big one. Turned out to be a deleted partial backup that had made its way into the recycle bin...I hadn't even realized recycle bin did anything with external drives.
6. Did that also as part of #5. In any case, all these drives have ever been used for is storage of these megafiles, so fragmenting isn't really a problem.
7. That might make a difference if there are errors causing a lot of retries on write, but then it sort of just masks the underlying issue, doesn't it?
8. No compression in play here that I know of. If I were going to compress this stuff, I'd do it when the file is created, not during the copy.

I'm leaning toward it being some kind of intermittent thermal issue, just wish there threw some kind of visible error code. If so I hope it's in the destination drive, as it's cheaper and I already have three of them.

what do you mean by 3rd level backup?
my ASUS router would quit when it was used. It was porobably an ic getting hot.

#8 feels like a stretch, but, I am pretty sure the compression has more to do with remote connections, nothing to do with hard drives. I do not think it would be possible to save any time at all to compress in that way unless it was a compressed file system. My expectation that it is like the ability to compress data while sending over SSH where it is built into the protocol. The concern with it is that it might slow down the CPU.

If you can attempt a copy using the command line only, it will remove the GUI as a cause for the pause. I often resort to the command line to copy files on Windows just so I do not need to deal with the GUI idiosyncrasies; not that it seems reasonable that this should be the problem.

I assume that nothing shows in the event log.

Quote:

---

Originally Posted by Chuck Wintle

what do you mean by 3rd level backup?

---

In decreasing frequency...
Level 1: all three computers do image backups to the NAS.
Level 2: the entire NAS backs up to a 8TB USB harddrive on the main computer, creating a 1.2TB file (currently).
Level 3: the latest NAS backup file on the 8TB gets copied to one of two portable 5TB USB harddrive (that's the copy operation that we're talking about here)
There are two of those 5TB drives: the 'old' one is in an offsite location, the 'new' one is in a fireproof safe in the garage. They get swapped when the 'new' one fills up.
Overkill? Yeah, probably...until I actually need it. :) Haven't so far, knock wood.

Quote:

---

Originally Posted by Andrew Pitonyak

If you can attempt a copy using the command line only, it will remove the GUI as a cause for the pause. I often resort to the command line to copy files on Windows just so I do not need to deal with the GUI idiosyncrasies; not that it seems reasonable that this should be the problem.

---

Can't hurt to try the command-line thing next time. Thanks for the suggestions.

I'd try Robocopy rather than xcopy. Faster and likely more stable. I've used it for backups in the past of virtual machine files that are multi-terabyte and it works well.

Derek

Quote:

---

Originally Posted by Derek Meyer

I'd try Robocopy rather than xcopy. Faster and likely more stable. I've used it for backups in the past of virtual machine files that are multi-terabyte and it works well.

---

Huh. Haven't seen that one before...then again it's been a (very) long time since I felt the need to anything meaningful from a Win/DOS command prompt. The 'restart' mode may let it ride through whatever is causing the pause.
Thanks.

UPDATE: It's apparently a thermal issue with the smaller (portable) drive. Had CrystalDiskInfo running and happened to notice the temperature indicator go red at 50C right before it paused.

Oddly enough the other drive was showing green at 57C at the same time.

Hit restart, and it continued and finished (about 45 minutes later) at the same indicated temps and a higher overall transfer rate for the second portion...what's that about?

Quote:

---

Originally Posted by Lee DeRaud

UPDATE: It's apparently a thermal issue with the smaller (portable) drive. Had CrystalDiskInfo running and happened to notice the temperature indicator go red at 50C right before it paused.

Oddly enough the other drive was showing green at 57C at the same time.

Hit restart, and it continued and finished (about 45 minutes later) at the same indicated temps and a higher overall transfer rate for the second portion...what's that about?

---

are these both mechanical drives or solid state?

Quote:

---

Originally Posted by Chuck Wintle

are these both mechanical drives or solid state?

---

Both mechanical Seagates. The portable ("to") is 2.5" 5TB, the "from" is 3.5" 8TB.