verification puzzlement

Back-up to external HDD's works fine, and verifies (using ATI-11, final build, and Vista SP 2). However, latest backup to internal secondary HDD would not verify (either when did an incremental and tried to verify, or when later tried full back up and tried to verify).

Back up that would not verify otherwise seemed OK (would mount up and I could explore it - and seemed the right size). In past weeks and months, back up and verification to this secondary internal drive went off without a hitch.

Have read recent previous threads on verification - so tried to verify after boot up from ATI rescue disk, in linux environment - and the full back up that would not verify in windows verfied with no problem. I would imagine the opposite is more common - that back ups within windows environment might seem OK but bomb out when boot up with rescue disk in Linux environment. Is this indiciative of a problem just in secondary hard disk (or its cable) rather then a memory problem? If so, why did it work in Linux? Maybe the key to the mystery is just the re-booting of the computer between the verification attempt within windows and the successful verification within Linux?

Any thoughts would be appreciated.

Have NOT yet run memory diagnostic, or run chkdsk on the secondary internal drive, or attempted to restore from this latest back up.

 

You're right, validating in Linux is usually a more common problem. There was a version/build of TI where creating an archive and then immediately validating it gave erroneous validation failure errors but I can't recall the exact details. Does your windows validation fail if you create the archive then exit from TI, reload TI and then validate?

Windows and Linux wouldn't use RAM exactly the same way so there is a chance you might have some marginal RAM particularly if it used to work. Since the Liunx and Windows driver's don't operate the HD in exactly the same way it could be that the Linux version is doing more read re-tries or some other reason is allowing it to have more luck with accurately reading the file. I wouldn't be real confident about the archive until the actual cause was pinned down. You could try downloading memtest86+, free from www.memtest.org and let it run overnight. Won't do any harm and it will eliminate to a large extent one potential cause.

Have you run chkdsk X: /r on the partition the archive is stored on? Replace X with the drive letter of the partition being tested.

 

Re: verification/validation puzzlement

seekforever: many thanks for your response - apologies for this tardy update

After further testing, here is the situation:

failed validation occurs every time I attempt to validate an archive that has been placed on my secondary internal HDD (letter designation I: on my computer), whether validation attempt is immediate, or whether after reload Acronis ATI 11 - or even after re-boot. When validation attempt bombs out, it does so near the beginning - within the first minute or so.

BUT validation is successful every time the archive is created on an external HDD

AND

validation is successful, even if archive is on secondary internal HDD, IF I do the validation off of Acronis Bootable Rescue Disk (in linux environment).

I have the latest (and I presume final) build of ATI 11 (build 8,101), though my rescue disk was created with a special ISO from Acronis when regular rescue disk would not work with my chipset (ICH9, ICH9R).

Have down-loaded and used Memtest86+ ver 2.11 and after a few hours of testing (5 passes) no errors reported with RAM. I realise that a longer test might be called for (overnight or 24 hour test perhaps). The built in Vista memory check utility also showed no errors.

Also ran chkdsk with no reported problems, though getting it to run was a challenge. First tried from within Windows (Computer right click->tools-error-check). Working from within windows was possible since checking secondary internal disk and not C: system HDD. With both boxes of utility checked ("automatically fix File System Errors" and "scan for and attempt recovery of bad sectors") check would hang up at step 4 of 5. Using Start->command -> chkdsk I: /r check also seemed to hang up at step 4 of 5, after completing about 10% of data file processing (both when run within windows command window, and when run with windows started up in safe mode). Finally got chkdsk to run within windows by unchecking the first box ("automatically fix File System Errors") and having a successful run-through in a few hours - then ran it again but unchecked second box and checked first box - ran through in a few seconds.

Not sure where that leaves me. I could go out and buy another external HDD and try restoring an archive from I: onto that external, to see if it will restore even though fails to validate, but I strongly suspect it would restore successfully - especially since that restoration would be within linux environment - but having said that I would like to get to the bottom of this mystery. As previously reported, that problem with validation is of recent origin - though PERHAPS only since redid my entire computer after constant crashes - I switched my secondary internal to main HDD and reinstalled Vista and all rpograms - and the old main HDD became my new secondary internal (after re-formatting it). Both internal HDD's appear to work without fault (except this Acronis validation problem) and to pass all tests.

I wonder if this could be a cable problem? But then why OK when validate with rescue disk?

Sorry for the long ramble. Any thoughts would be appreciated. I may try and kick this over to Acronis Support.

 

Hello itobor,

Thank you for using Acronis True Image

seekforever is correct, Windows and Linux don't handle the hardware exactly the same way. The issue is related to the hardware (a hard drive cable, or a hard drive, or a hard drive controller, etc.).

We can check the hard disk partition structure, it can be the reason of the issue also.

Please download Acronis Report utility available here and run it, create a report and attach to your post.

Thank you.

--
Oleg Lee

 

I agree with runnng the Acronis report utility. It seems to be able to reveal problems that chkdsk doesn't.

 

I down-loaded utility. When run it gives message that I do not have sufficient privileges to run it (though I am the admin) - but then congratulates me on creating a repport. The report that it created is attached, but it is very abbreviated, reporting only that OS is OK and disks OK.

This issue has also been reported directly to Acronis Support: ref:00D3Zcb.50056nCPo:ref

Since last post, successfully ran Western Diagnostic disk check utility - it took about 2 hours and found no problem with the secondary internal. When tried to create a new Acronis archive on secondary internal yesterday, the archive seemed to create OK, BUT it created quicker than usual (about 10 minutes) - though ended up about the right size (54GB) - and, as usual) it would not verify from Acronis within windows AND, NOT as usual, when tried to verify off Acronis boot/rescue disk it reported to would take 6 hours - and after about 4 hours, with progress bar about 2/3rds through, it apparently gave up and rebooted my computer (I say "apparently" because computer was unattended at the time and there was no report on log file.)

When I get a chance today, I will move 2 of the Acronis archives (one that would only verify using rescue disk, and the last one that would not verify by any means) from the secondary internal to an external HDD and see if they will verify after moved.

 

Hello itobor,

Thank you for the provided information.

Unfortunately, the provided file is blank.

User Account Control prevents the Acronis Report tool from creating a report successfully. There are not enough permissions for the Acronis Report tool to access the low-level hard disk drivers. To overcome the issue please make right-click the AcronisReport.exe file and select Run as administrator. This will start Acronis Report with the administrative privileges and the report file will be created successfully.

Attach the report to your next post.

Thank you.

--
Oleg Lee

 

acronisreport.exe caused computer to crash when external drive attached. Computer has remained unstable and will need to go into shop. Memoery tests OK (memtest 86 +_ but western digital diagnostics will not run to check HDD.

Will post again when computer stable enough to run acronistest.exe

 

acronisreport.exe now in a loop- will have to turn off computer

 

acronis report attached (without external drives attached) - took many minutes and cycles before finalised.

 

Are you putting the archive in the Scramdisk partition when you have trouble?

 

not sure what "scramdisk partition" is - is that the "secure zone"? In any case, the computer and all Acronis functions have become unstable. Whether I try to create archive in internal secondary SATA II disk or one of 3 external USB (or firewire) HDD's sometimes it "hangs" and I have to cancel out. Sometimes it works. No consistency any more on which drives work for archives and which do not. Same on restore. First attempt when had total crash today failed with 3 minutes to go (after 25 minutes) - but second attempt successfully restored archive (from secondary internal HDD)- but then computer would not boot up. After a few hours, tried again and booted up from the restored drive, but running unstable. Have to go to bed now (1 am in Perth Australia), and will turn computer off. Not likely it will start up again tomorrow.

Thanks for your interest. I may be out of touch for a while as no alternative computer to access internet.

 

Computer now seems to be operational again - and have been able to create and verify Acronis archve to both external HDD - have not yet tried it to secondary internal HDD.

I suspect the problem was an intermittent fault with cable that was originally between secondary internal HDD (where problem with verification first became apparent) and motherboard port - and later switched drives around and that suspected faulty cable was between main C: drive and motherboard port (making computer very unstable). This was not apparent because fault was internittent until very recently and HDD would pass diagnostic tests until very recently.

As of late yesterday diagnostics would not even run on C: disk, and computer would almost never boot up. Even Vista install/repair disk would not find installed OS. Diagnostics ran when disk attached to another computer, so figured it must be cable or port. Put in new cable between C: drive and motherboard (same port) and everything now seems to be OK. Still testing it out, but I am hopeful that mystery is solved.

Thanks to all that commented. Will post again on this thread only if problem arises again, or if anyone posts a question or comment.