0

I have a external, powered hard drive consisting of multi-GB video files. I believe it is likely somewhere in the process of failing. Current behavior is several minutes between connection and the OS detecting the drive (though the sound effect is rapid). Then I have some variable amount of time where File Explorer can access the drive, though navigation is very slow. (Windows is on an SSD and is otherwise very fast.) At some point (on the order of 5-10 minutes) the drive will vanish, including the disconnect sound effect. I've seen the drive in Device Manager move from Disk Drives to Universal Serial Bus controllers: "Unknown USB Device (Device Descriptor Request Failed)".

So something is clearly wrong. (Suggestions appreciated, but not the main question.) My diagnostic skills are still in progress, but this "feels" more like a connection problem than a data integrity problem. So my first step is to copy what I can off the drive. I tried one video using the normal drag/drop in File Explorer. It went too slow, but copied about 20% of the 6GB video before I heard the system lose the connection. And of course, "An error has occurred. The destination you have specified does not exist." (I question that message. It's the source that's the problem.) Realistically that's just going to happen next time as well, but I might have a chance if I copy a quarter of the video at a time. I just need to know how, with a minimum of trial and error as I don't know how many attempts I'm going to get.

My suspicion from other related questions is that robocopy or rsync might get me close. But none has quite covered this use case. This is Windows, and the nature of the interruption (a drive failure) could be relevant. A simple retry is also not enough; I will need to physically disconnect/reconnect the drive between attempts. I have no preference between intentionally copying only part of a file (somecommand source destination startByte=5885 endByte=10885 --append) or copying the full file and having the ability to resume an interrupted transfer (somecommand source destination restartable=true). The first path seems to have a particular lack of questions/answers.

How can I copy part of the huge file to new file? - My files are binary. I'm not sure this will work.

Resume transfer of a single file by rsync - is the closest I've seen. Note I'm on Windows and don't have rsync available. If this is the right answer, though, I'm willing to install cygwin as Copy files with partial resume support? (Win/Cygwin) indicates is possible.

Copy files with partial resume support? (Win/Cygwin) - is dealing with wifi.

Will robocopy resume after being aborted? and others suggest robocopy with the /Z flag. I have tried this without success: robocopy source destination /Z /TBD /W:120. One of the answers seems to be correct that the /Z restartable mode only works for network transfers. It did nothing for me. Upon drive disconnect, the transfer would fail. Upon reconnect and running the same command, it started over at 0%.

2
  • 2
    If you suspect some connectivity fail rather than the drive itself, then first test would be another enclosure
    – Tetsujin
    Jan 9, 2021 at 19:45
  • Restartable robocopy might work if you shared the drive and used the share-name rather than the disk-letter. You could also try xcopy /z and FileCopyPlus. However, copying a huge file from a failing drive with 5-10 minutes at a time will be time-consuming.
    – harrymc
    Jan 9, 2021 at 19:53

1 Answer 1

0

You might consider duplicating the drive instead of copying files unless you have strong arguments like you expect the drive to break very soon and the files only use 10% of available space.

The advantage of using ddrescue here is the log file that allows you to restart the duplicating process. You would not have to think about or program stuff to list the file tree, saving progress information, caring about duplicates not reaching initial file length due to interruption etc.

If you want to stick with robocopy I would set up a test scenario to mimic power outage on the source drive to see how robocopy reacts. That would involve target file verification.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .