The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
My backup strategy is pretty simple: Invoking Robocopy from a small PowerShell script that works out the logic of identifying the backup drive, as its letter might not always be the exact same depending on what else I might happen to have hooked up. I like Robocopy because it's as simple as a recursive "copy star-dot-star", and it automatically skips anything that hasn't changed. Also, having a straight copy of the file system means I have direct access to any file, without relying on some BLOB that can only be accessed by some proprietary backup software that has to be installed on whatever system I hook up the backup drive to.
In any case…I have 2 backup drives (normally, one offline, sitting next to the computer, and the other at the office for monthly rotation). Both are in external USB enclosures. Both have started exhibiting the same problem where the machine would stop reading (writing?) at the same point on the same file (some large-ish file, but otherwise totally random in the sense that there’s nothing that sets it apart from plenty of others). CPU activity settles down to nothing, same with disk reads/writes, then I can’t kill Robocopy with Ctrl-C or kill the PowerShell session with Task Manager. Logging out/rebooting can’t “cleanly” terminate the process either, as it just sits there forever (I've let it run overnight) and I have to hard-reset the system. Or, yank out the USB cable--then the system comes back to life immediately. Not good—I fully expect this sort of thing to eventually result in corrupt files/file systems if I have to keep doing this.
After rebooting (or re-inserting the USB cable), if I restart the same copy operation, it may manage to proceed further, or get stuck at the same point on the same file again. With enough retries, I suppose I could complete the full backup eventually, but obviously that’s not the way to go.
Copying the offending file with Explorer to the backup drive again results in the same thing – it eventually just stops (doesn’t complain about any read/write error, just no further progress is made).
Everything at this point is suggesting a bad source file. But if I move the file elsewhere or delete it altogether, then the same thing happens again with the next large-ish file it might encounter. Or it might not.
I ran chkdsk /f on the source and both target drives. No problem whatsoever. I don't know how thorough chkdsk is, but it claims everything is squeaky clean.
The crazy solution? Hook up the backup drive to another system, and run the backup through a share across the LAN, instead of directly from local (internal) drive to local (USB) drive. Then all files can be read and the full backup completes without even a hint of any sort of slowdown at any point.
Since I'm copying across the LAN with the same USB cable, the only thing I have left to blame is the source computer's USB port. There's only one at the front, and the ones at the back are unfortunately rather difficult to reach (it's a lousy physical setup), but I'll have to try that just to confirm.
In the meantime...if I get the same thing through another port...what else is left I should I be looking for?
(and yes, the anti-virus remains completely quiet)
My backup set includes files that are tens of GBs in size, and I haven't seen any problem with those. I suppose I shouldn't have said that it only happens with large files, but rather, that I haven't seen it happen with small files.
I use EaseUs Todo Backup. It puts the files in a ".pdb" blob that can be opened by Windows Explorer.
Really? Windows Explorer natively understands these BLOBs created by a third-party program, so a machine that's never had it installed on it before will understand these file types? I find that dubious, because I just created an empty .pdb file, and Explorer showed a generic icon and set the type to "PDB file", which tells me it's an unregistered file type and Windows wouldn't know what to do with it.
You're right. If I double click on a pdb file (created by EaseUs) on a computer that has EaseUs installed on it, it opens in Windows Explorer. But if I try it on another computer that doesn't have EaseUs installed, it won't open it. It really is Explorer opening the file, not the EaseUs app. I looked in the registry for what kind of magic it could be doing to make that happen but didn't see how it's done. Whatever it is, it's not the standard HKEY_CLASSES_ROOT\.pdf registry key. Must be some kind of extension added to Explorer. Sorry if I got your hopes up.
Must be some kind of extension added to Explorer. Sorry if I got your hopes up.
Of course it's an extension. And no, I didn't have one iota of "hope" this would even be possible without said third-party software.
I still prefer having a plain copy of the individual files--nothing will change that. That way, anything that can read NTFS will be able to read my backup. One less thing that can go wrong, really. Just how resilient is EaseUs to corruption in its own files?
I haven’t had any problems with it yet. My wife is constantly losing files and I’ve been able to recover them all so far. Just had to reload my C: drive from backup because it wouldn’t boot (after several attempts to fix it). It restored and booted right away. Just one issue minor issue with Windows that I had to fix after the restore, which I can’t blame on EaseUs.
I missed the part where it works over the LAN. You can disregard my post completely.
But have you checked how deep your directory structure is?
The length of the path might be up to 32k characters long in NTFS, but the Explorer doesn't support more than 260, and if you do it over the LAN the path is often shorter