USB and bad blocks
I got a support call the other day, leading to me looking at the case via TeamViewer.
The gist of the issue was that ZAR produced zero-length files.
The drive was from some Iomega NAS, with no RAID to speak of.
Some further quick checks ruled out permissions and UAC as possible factors.
The initial scan was fine and produced a correct directory tree;
therefore, I knew we were getting at least some data from the drive.
However, by the end of the scan, there were no files.
So I started the scan again, and I watched the process this time.
The source drive contained two partitions, the small one with NAS firmware
(that would be EXT filesystem, most likely) and the large one storing data (that was XFS).
Neither is recognized by Windows.
The source drive was connected to a laptop doing the recovery with a USB adapter.
After a while, two boxes popped up for D: and F: drives,
along the lines of "Drive D:\ contains unrecognized filesystem",
each one asking me to format its respective drive.
This is a standard Windows behavior to ask you to format any unrecognized drives you connect.
The only thing wrong was that nobody did connect the drive - the drive was already connected.
Once I saw this, it became immediately apaprent that the USB adapter had failed and was reset.
Moreover, the target drive, where data was being copied, was also reset because the USB hub,
sensing that the adapter locked up, reset all the connected ports.
This caused both source and target to be reset.
Such things are most often caused by a bad block on a drive connected via USB.
USB adapters do not handle bad blocks well.
There are two things to learn here
- Do not put the source and the target drives both on the same USB hub;
-
If possible, use SATA, not USB. SATA does not choke when it encounters a bad block or some other malfunction.
Better yet, short of a drive blowing up, failures of SATA-connected drives stay confined to that drive.
Filed under: USB.
Created Thursday, September 28, 2017