one backup stalling: troubleshooting steps?
One of my two backups has begun stalling, and I wanted to run my troubleshooting plan by y'all.
I'm using ATI 2020 recovery media on a USB drive.
My system drive C's (115 GB) backup (to drive G) completes fast and AOK.
My data drive F's (1.3 TB) backup (to drive H) hangs at 30% (400 GB). By hang I mean that when I wake up the next day, I need to abort this backup that has always completed within 5 hours, because after a dozen hours it says it'll take another dozen.
The setting "Ignore bad sectors" is not Enabled.
My plan:
Run (HD Tune Pro) HDD diagnostics on the Source HDD F.
Run (HD Tune Pro) HDD diagnostics on the Target HDD H.
Assuming they both check out AOK (I'd bet they won't), then I'll run CHKDSK /f on each.
Download and create ATI 2020 recovery media on a new USB drive and try it in a different port not using a motherboard header. (If even that step fails, I could put ATI 2020 recovery media on an optical disc.)
Next I guess I'd start thinking about RAM, motherboard, CPU...
Steve Smith wrote:Does the backup log for the problem backup task show any errors or other messages to indicate if it is hitting any issues?
Is there a log for a (aborted) boot media backup?
There may be if you look at the Logs option while still in the boot media, but would probably be better / more comprehensive log if you tried the same backup from within Windows if you still have ATI 2020 installed there.
The rescue media logs may be more brief but could show something if any retries are involved etc.
You can try copying all the logs to one of your drives if needed:
copy X:\ProgramData\Acronis\TrueImageHome\Logs D:\logs
Oh yes I think I recall logs is a boot media option. I'll turn it on and re-run tonight, thanks yet again Steve!
(I guess if that doesn't work I can try installing the program in Windows.)
Great suggestion to hopefully narrow it down. Just error-checking a 12 TB HDD would take a lot of time.
After the non-problematic backup completed, I went to the boot media's Log tab and saved the (brief) logs.
After I aborted the problematic backup this morning, I tried to save the log from it but the boot media crashed to a screen that kept adding dots to "Collecting Reports........." then after a minute said "Please plugin USB flash drive". I did, the PC rebooted, and I found that "AcronisSystemReport_Dec_17__2021_6_09_37_AM.zip" had been written to the USB drive.
Unfortunately the logs in the zip only applied to the non-problematic backup. (Oh, and http://dl2.acronis.com/u/tools/ReadLogFileNewGen.exe wouldn't view them [but would launch them in Wordpad]; "MVP Assistant Version 1.1.6.0" wouldn't let me navigate to open them.)
I guess it's time to follow my diagnostics plan.
Edit: I think I've narrowed down the problem. The Backup.Source drive (an SSD) passes physical diagnostics (using HD Tune Pro and Samsung Magician)(I'll try CHKDSK /f on it next). And backing it up to another (HDD) drive worked overnight! So I'll run HD Tune Pro on the (12 TB) Backup.Target drive (which I expect will take most of a couple days).
Actually both drives passed both physical diagnostics, and filesystem diagnostics (CHKDSK /f). And the RAM passed Memtest86.
So since nothing is wrong with either the Source or Target drives, and since the Source drive backs up AOK to a different target drive, I'm stumped.
So as Steve recommended I guess I should install ATI2020 in Windows and see if it's logs explain why it can't backup to the Target drive.
coyote,
Question, are you creating a new full backup of the failing task each time you run it or, are you adding to an existing backup previously created by the task? If the latter this may be the problem you have in that some corruption exists in the backup file itself and the application cannot fix it or get past it. Your statement that a task run to an alternate disk was successful lends credibility to this theory.
A sincere thank you, Enchantech, your question led to some helpful thoughts.
Not that your theory was correct, but how I wish it was! I apologize for not being more clear in the OP that the
"(1.3 TB) backup...[which] hangs at 30%"
is a Base.
But the question got me thinking about Incrementals.
So I ran an Incremental on the last successful Base backup to the problematic drive. It succeeded, but it took longer. So I developed a new hypothesis. A pretty weird one, since it's never happened to me with any of the hundred-something HDD's I've owned.
Maybe despite both drives having flawless error-check testing both physically and filesystem wise, the problematic WD Gold 12TB HDD has simply become much slower. Maybe 5 or 10 times slower.
I'd have to let a backup run for days to know exactly, but I think I may end up RMA-ing it (I have a year left on the warranty).
I'll have to say it fails diagnostics, but they won't ask which diagnostics.
(Incidentally, when they send me a refurbished HDD I'll sell it on eBay, I don't believe in putting anything but new HDDs into service. I'll use is as an opportunity to buy a bigger faster newer one.)
I have started to run new base backups to the problematic HDD two different ways, and each (going just by the admittedly-sketchy time remaining displays, is gonna take some multiple of the previous time). The two ways:
Via ATI2020 installed in Windows.
Via a new ATI2020 boot USH via a new d/l of the same ISO.
Overnight I'll gonna try it using an ATI2020 WinRE Recovery USB created from the Windows program's Tools menu. Honestly I may RMA the HDD even if it takes the right time with it (thanks perhaps to better drivers)!
I think the last thing I might try before an RMA is to Quick (I've already done error-checking so no need for Full) Format, and try a Full that way.
Hey, for anyone still reading, I had an interesting adventure when I ran "CHKDSK /f" on the 2TB non-system SSD. Doing so hosed SSD filesystem so Windows couldn't access it (saw it as "Local Disk"). I fixed it by restoring my backup from the alternate target, but I since learned I could have fixed it in the Recovery Console.
Apparently this was a known issue with a Windows update that Microsoft thought they fixed over a year ago, long before I even installed this OS. Fortunately I never had to buy y'all about it. It turns out the way to fix it is to run "CHKDSK /f" in the Recovery Console. I was quite appalled to discover that no one I reached out to had any idea what to do, including: tech support for the Samsung SSD, and the support forums for Samsung, Microsoft, and Tom's Hardware.
OMG, using the ATI2020 WinRE Recovery USB created from the Windows program's Tools menu, not only didn't the problematic backup to the problematic HDD take an order of magnitude more time, it only took 40% as long as ever before! (It usually takes like 5 hours, but instead of overnight I got to see it complete for the first time.)
I'm guessing thanks, as I wrote above, thanks perhaps to better drivers for my smoking system than the generic Boot Media. Which leaves me no more disinclined that before to RMA the problematic HDD. Right after I format it tomorrow and test one more backup.