E0007003: Failed to read data from the disk: A possible reason might be bad sectors

OK, this is a long running one, so get your thinking caps on!

This fault has reoccurred for countless months, I have tried everything Acronis support had to suggest, thought it had gone a away, and now it turns out it hasn't gone. I really haven't the heart to pursue Acronis any further over a fault they seem unable to fix. Here goes:

Once a week, ATI v11 is scheduled to run (at an idle time) a 'My Computer' (all partitions) differential backup of my PC, to my external USB Hard Drive (Seagate), followed by verification. Usually, having backed up OK, the verification fails with the message:

"E0007003: Failed to read data from the disk: A possible reason might be bad sectors on the disk"

Often there's an accompanying message re 'Insufficient system resources exist to complete the requested service'. I get up most Saturday mornings to find the failed verification message. Without rebooting or changing anything, I then manually verify the backup, and Acronis always says that the backup is fine. This suggests it is a bug. In the course of many months support from Acronis, I have tried:

Uninstalling ATI completely and reinstalling the latest version

Deleting the 'base' full backup which the differentials build on, and starting again.

Deleting unwanted files so my PC's hard drive (250Gb) is less than half full.

Reformatting the external hard drive (NTFS).

Checking both PC and external hard drive for errors using the most thorough Windows options, and chkdsk /r, and manufacturer-specific disk utilities which check both disks for endless hours, but find no fault ever.

Connected the external HDD to a different, non-shared USB port

Replaced the USB lead with a high-spec Belkin one.

Ran memory checking utilities for hours which confirm my 3Gb or RAM to be fault-free

Downloaded the latest Snap.api drivers provided by Acronis

Reduced the HDD writing speed by half, in case that was the cause

There's probably other things too I've tried, which escape me. The important point is that my Dell PC works fine, has plenty of free 'resources' no fault has ever been found on internal or backup HDD, and that as a manual verification always succeeds, it would suggest that the error is a 'bug'.

Googling this problem yields post on this forum back with ATI v9, but don't shed any light.

If I backup my laptop to the same Seagate HDD using ATI v11, this always works fine. I have other copies of ATI v11 running similar nightly backups at work, and these always succeed. So I can't say it's ATI v11 at fault specifically. Trouble is, nothing seems to be at fault. I have a healthy Dell PC with plenty of free HDD space and RAM, fully up-to-date with Windows patches etc, scanned regularly for Viruses etc.

It just won't verify a scheduled backup with even 50% success rate as an automatic option, but always succeeds to manually verify afterwards. I'd really appreciate anything I or Acronis Support could have overlooked here.

 

Hi,

1. did you try to connect the Seagate-HDD to a PC-internal HDD-Slot?

2. did you try an image by starting with the Ti-rescue-CD?

Sorry that there are more questions. I feel your pain...

 

If you have another computer and another hard drive, then I would...

- hook up the current seagate to the spare computer. Install TI with same scheduled backup - run the scheduled backup and see what happens.

- hook up the spare harddrive to the current computer (swap out the seagate), run the scheduled backup - see what happens

Maybe you get lucky and isolate the problem to either the computer or the harddrive.

One other thing - have you done a restore from one of these tib files that gives the error message? Do you know for a fact that the tib file really is valid? The after-the-fact validation might be a false positive. Maybe there really is something wrong with the tib file that is causing the error message during original validation.

 

For what it's worth, I ran into a problem with TI10 on a friend's PC when her external USB hard drive was attached to a Belkin, powered USB hub that then connected to the rear, motherboard USB connection. It would start a backup, but go comotose after a few minutes. I finally connected the USB drive directly to the PC's front USB connector and all was well! I know an un-powered USB can cause problems as some external HDDs draw quite a bit of power from the USB port, but this was a first with a power Hub.
I would connect your drive to a rear USB port, as it's connected as close to the motherboard USB controller as possible.
Good Luck!

 

Thanks for the replies. You're right, Mr Morse, about the pain.

I have occasionally tried restoring the odd file as a test, which has always worked, but never the whole PC image as I've never needed too, and it would seem a risky experiment. It never occurred to me that the backup might actually be corrupt, as it always verified OK manually.

Lately, I've been plugging the drive into one of the two front USB connectors on my Dell (the other empty) hoping that this would 'isolate' any cross-USB device interference. Previously I always used a rear port. I'm aware of the comments re powered USB hubs and have never used it this way, always plugging it into one of my Dell Dimension 5100's front or rear USB ports. The Seagate HDD has it's own power adaptor, so this isn't a USB power issue.

I did try booting from the ATI rescue CD, and this backed up without error. I don't recall Acronis support commenting on this much, however.

I have in effect tried the Seagate HDD with another PC (laptop) which worked fine. This tends to rule out this USB drive as faulty. I haven't tried connecting the Seagate drive to an internal PC slot, as this would mean dismanlting it, and there is no evidence (after hours of detailed scans) that anything is wrong with it.

Circumstantially, it feels more like the Dell PC is under suspiscion, but I cannot find a damn thing wrong with any part of it. I do have another external USB HDD though, I will try soon a backup to this. But with similar reports back with ATI 9, I can't help wonder if something else is happening here?

 

External cases for hdds has their own controllers.
Not all PCs support these.
Perhaps your DELL is such a PC.

I would dismount the Seagate and try it at an internal slot.
Only to be sure...

 

You mean that going via the USB interface wouldn't make the Seagate's internal controller 'invisible' to the process?

Interesting idea if so, but I did think that a Dell PC and Seagate USB HDD were too major/global brands to encounter such incompatibility?

 

Don't be so confident about 'global' brands

It COULD be possible.
It MUST not be the reason.
But it seems you are interested to find the reason for the fault.
Try it to except this possibility.

 

I will try it soon. Meanwhile, I'm trying a backup from Dell to newer Seagate USB HDD. Will be dissappointed if a controller can prevent a USB device from working however, I thought that it just transferred the data to/from the USB port in its own way? Didn't think 'compatibility' existed as a concept in such things?

 

In my experiences with Hardware, Software, etc I have seen a lot of incompatibility. Sometimes amazing/incredible.

 

One last thought. How large is this backup image?

USB devices and hard drive interfaces are occasionally size sensitive. They aren't supposed to be, but some have a bug that causes errors for large files. This usually doesn't show up until files are more than 1GB and sometimes not until they are 10 GB. Therefore, it never appears in ordinary use, but it can appear in backing up.

You can test this by simply splitting the backup image into 1GB pieces, and if that validates succsessfully every time, try 2GB or larger pieces until you start to see errors.

It certainly seems that you have tried everything else.

Of course, I never validate automatically. I manually validate and also from the Rescue CD for a few backups. If every time it validates, I assume that the hardware and software are good and no further validations are needed except randomly or when there has been a hardware change. I've never had a problem doing this. So, sometimes too much information leads to frustration.

 

jmk94903,

Why? I understood that an unvalidated backup was a potentially worthless thing? Why would a manual validation, some time later, be any better/safer?

I am interested in what you say about file size. The backup is big, 76Gb as a base and perhaps 10 or 20Gb as weekly differentials, but of course a full backup of 'My Computer' when your HDD is 250Gb isn't going to be small. I'd be very interested to know more if large backup files 'don't work' for some buggy reason? One of ATI's major attractions over rival backup software is that you can image the whole PC, with the option of a full restore later or else just picking a few files & folders. Most competitors are either full image backup/restore or else specified folders backup/restore.

I've been thinking about what Mr Morse was saying last night, that there could be some incompatibility between my particular PC and USB HDD, although both components work fine when paired with ATI running on a different PC or HDD. I'm not totally happy with this theory, mainly as the detailed HDD disk checks (Windows/chkdsk r/Seatools Utility) which run for hours, have never found a single fault. Surely, if my Seagate HDD's controller was unhappy talking to my Dell PC, there would have been apparent errors galore in multi-hour disk scans? Why only crop up in a one hour validation after ATI backup?

As a slight aside, my experimental backup of the Dell PC to a different USB HDD (a 750Gb FreeAgent Seagate, few months old, as opposed to the usual 300Gb 2 year old one) did succeed without error. But fresh/initial full backups have always tended to validate OK, so I'll report more of this when I've had time to run off a few diff updates.

 

A validation done later isn't better other than perhaps it might indicate if you have a "weak" spot on the HD where the magnetic field dies away quicker than it should. OTOH, a validation done later is as valid as one done right away. TI does validations be reading the archive and then recreating the checksums that were included in the archive at the time of creation. There are 4000 checksums per gigabyte and if only 1 doesn't compare properly the archive is declared as corrupt. It is a pretty stringent test and it also takes into account that the data is correct all the way into RAM, not just at the HD controller.

What likely is different between your other tests and TI is the size of the file being transferred. My experience has shown that very large files are much more problematic with USB chipsets. It isn't just a case of a particular chipset but how well the one in the PC works with the one in the external drive and while there is a failure with the 2 together, they each may work perfectly with other PCs/externals. I have a machine I run Syncback on and it will choke on the occassional multi-gigabyte video file in the verify check. I would try what jmk94903 suggests and split the archive into smaller pieces to see if it helps the situation.

 

Thanks for the information, there are some interesting technical points here. I'm bound to comment on this one:

This is quite a statement. Acronis endorse the use of USB HDDs in their manual:

Whilst my 75Gb of files isn't small, with new PC's easily hitting the 1Tb mark, I think many users will have much, much more to protect. If HDDs (USB or any?) have problems with files over 2Gb, then this really needs some publicity as we all enter the video download age.

The other point I have to query is, if this is a HDD hardware bug re large files, why would it not surface just as often in the ATI manual validation I later run? You'll remember the failure rate of the automatic validation after backup is over 50% (sometimes feels like 100%!) whereas the manual one I start the following morning almost never fails to come back OK?

I'll post again when I've tried another diff backup to the newer (750Gb) USB HDD and/or the 2Gb file splitting test (which I may well try with the troubled older 300Gb HDD). But that will be an awful lot of fragments to piece together!

 

The first test diff backup (10Gb) carried out on top of the newly created base full backup (75Gb), using the new 750Gb Seagate USB HDD, auto-validated without error. It's a little soon to pronounce this combination OK, as the fault doesn't occur every time, but this experiment is adding weight to the notion that the it's the Dell PC/300Gb Seagate HDD that's somehow to blame.

I will post again when I've had a chance to carry out a diff backup, split into 2Gb segments, using the original troubled PC/HDD combination. Is it valid to just do a diff backup with archive splitting, or do I need to start from scratch with the full/base backup split too? Given the high validation failure rate of the original PC/HDD pairing, any success from archive splitting using this combination would mean much more than tests using other PCs or HDDs.

But I would like to know how the '2Gb Hardware' theory can explain the near perfect validation rate when run manually? It was this fact that originally made me suspect an ATI software bug, as the processes ought not to differ in function or success rate.

 

Good point. The "near" in "near perfect" seems to indicate something, hardware or software, being a bit on the edge. One might suspect an initiallization error in the software or the USB controller isn't happy with how it is moving from its last task to the next one when the validation is done automatically. In any case, it is a problem with potentially multiple causes.

 

OK, haven't quite managed to fathom the archive splitting test.

Having configured ATI to Archive Split to 2Gb, I tried a diff backup, using the troubled 300Gb Seagate HDD, and building on the previous (unsplit) full backup. This validated OK, but not without giving two consecutive 'Error while clone operation executed' errors. Annoyingly, it didn't split the backup and just created one large 20Gb file.

Suspecting this might be because I was trying to build a split diff backup onto an unsplit base full backup, I deleted all the backups and started again. I double checked that Archive Splitting to 2Gb was selected, but again it did not happen. Two hours later I had one large 73Gb full backup file. It had validated OK, but then fresh full backups often did validate OK.

Am I misunderstanding Archive Splitting (thought it was to spread across numerous discs, so would mean numerous files?) or is there some other reason ATI isn't doing it?

Archive splitting appears as a general setting under Tools/Options/Default Backup Operations/Archive Splitting, and doesn't appear as an option when creating a Task, so I don't see how this is being ignored?

 

Hello Roy22,

Thank you for choosing Acronis Disk Backup Software.

We are sorry for delayed response.

Could you please try choosing "Set the options manually" instead of "Use default options"?

Please also notice that splitting option is not available when saving archives to Acronis Backup Locations.

Thank you.
--
Marat Setdikov

 

Marat,

Archive splitting is not offered as an option within 'Set options manually'. It only appears an an option under ATI's general/global settings. If you mean just select 'Set options manually' but don't seek any archive splitting option, then I would point out that I always have done this. Validation after backup (the whole point of my post/problem) is set via 'set options manually'.

I have always set ATI to backup to a Backup Location, to benefit from the various options this brings. Are you saying that this is the reason archive splitting is failing? If so, why are they incompatible?

Roy.

 

Hello Roy22,

We are sorry for delayed response.

Acronis Backup Locations are designed to manage archives automatically, so manually set archive splitting is not available there.

Thank you.
--
Marat Setdikov