One Cure for Error E00070020 !

Curiouser and curiouser...

I wanted to make this more visible than just appending another post to my thread on the topic earlier today.

It occurred to me that the issue might be one of XP drivers and bus timing, since the CD-based, somewhat-slower backup worked, while backing up under XP created random errors.

I thought I'd see what happened if I backed up to another area on the same physical drive. My theory was that this would avoid any possible timing conflicts between two internal SATA drives, because the system would have to seek between reading and writing.

Sure enough, it worked! While running under XP, I backed up to a subdirectory on one of the drives I was backing up, and unlike any other disk image utility I've ever used, TI 10 Home allowed me to backup to the same drive I was backing up. Nice!

TI was even smart enough to suggest that I copy the file to another drive later for safety. Although it ran about 40% slower, it completed successfully and verifying the file shows a valid backup.

Further investigation revealed that the backup to the same drive is about 60% larger than the valid backups made using the recovery CD and backing up to the second drive. Apparently it is not being compressed as it was to a separate drive.

The problem this now leaves me with is that if I use Windows to copy the .tib file to my other internal drive, the copy does not verify, although the original does.

Sigh...

 

The only problem I have had with TI images was caused by images not validating because of a marginal SATA cables. Replacing the cables cured the problem. I did find some references in the Event Viewer about (IIRC) parity errors and the suggested solution was, quite correctly, to replace the cable.

There was no indication under normal use that there was any problem with reading files.

Did you have the compression set in the Options when you did the backup? It should make no difference whether you backup to the same drive or a different one as far as the size of the archive goes.

 

I have come across and cured this problem on three occaisions on different machines. Two of the cases were down to bad RAM.

When attempting to resolve this error, I would suggest the following, in approximate order of likely cause:

- Overclockling or very optimistic BIOS/timing settings.
- Bad RAM
- If target drive is external, chipset/driver issues.
- Incompatible Linux driver(s)
- Poorly seated or creased/damaged cable.

1,2 & 3 in particular are easy to eliminate if they are not the cause.

F.

 

Another thought: Is the drive a SATA2 (in the common use of the terminology, meaning 3Mbps transfer rate) drive running on a SATA1 (1.5Mbps) controller without the drive's jumper forcing the drive to run at 1.5Mbps. They are supposed to back off to the slower rate but it doesn't always happen. This fixed someone else's problem but I can't recall the symptoms.

 

E00070020's resolved with a workaround...

All good ideas, guys, but I have to conclude that this is a software driver issue on my system, and probably not hardware. All of the symptoms I've described have been reliably reproducible, and I've performed each test several times, as I've been incredulous myself.

I've run memtest for more than an hour today with NTF, and I'll do so again overnight. My clock speed and BIOS settings are ASUS/AMD factory default. I did not change the TI compression settings during the 'same-drive' tests.

In the past couple of hours I've also experimented with various combinations of NTFS compression and turning write caching off and on on the backup target disk, with no relief.

However, what has just now worked twice in a row was to quit using XP's file system (assumption on my part) by creating an Acronis Secure Zone partition for a backup target instead of an NTFS volume.

It seems to backup a bit faster than to the NTFS volume, and I've created two full backups of about 20GB of data with no Verify errors during, or separate from, the backup.

I also just completed a full restore of the files/folders to a directory, and the file- and byte-counts are the same as the original volumes, at least as reported by windows.

So at least on my system, the resolution appears to be to use the Secure Zone with Incremental backups, rather than multiple full backups, which had been my previous practice.

Phew - what an ordeal it is to get a "simple" backup program to work. Did I mention that Ghost 10.02 also didn't work for me?

 

In case you aren't aware, the Acronis Secure Zone is formatted FAT32 so if the images are bigger than 4GB (max FAT32 filesize) they will automatically be split at 4GB.

I was under the impression the archive size changed when you used Windows vs the rescue CD. They don't necessarily have the same options set.

You mentioned that you couldn't verify after copying the files to the second drive with Windows. You might get a bit of a handle on that by using a checksum calculator such as XCSC free from:
http://www.irnis.net/soft/xcsc/
Calculate the archive file(s) checksum, copy them and calculate it again and they should obviously agree. If so, copy the files back to the first HD and check the calculation again. Bad RAM could cause this to fail as well as a disk problem.

 

Re: E00070020's resolved with a workaround...

One hour is probably a bit early to make any conclusions. I would run for 6-8 hours at least.

Can you also confirm which version/build you are running, and whether this information is the same for the recovery cd. Also, I infer that you are backing up to and internal drive. How does this differ from your source drive.

F.

 

Well, I ran memtest for over 12 hours last night with no hits. The drives are both SATA internals. One is 320GB, the backup is 80 GB. Aside from backup, the only other thing on the 80GB is my swap partition.

The archive size increased by 60% (running under XP) when I put the backup target on one of the source partitions, and yes, it was the same "standard" compression setting. All 'drives' are NTFS.

The TI versions are 10.0/4942.

Clearly there is something going wrong when writing large files on the 80GB drive, but it seems to work when I use the TI secret partition.

Weird? Oh, yeah...

 

When you backup to the second drive does it validate OK from XP?
When you attempt the restore from the second drive do you get the error following an explicit validate from the Linux environment, or from the restore operation. If the latter, what happens when you do the Linux validatation?

What happens if you swap the two SATA cables over and then backup to the second drive ?

F.

 

No, nor does it validate from the recovery CD.

Validation error from all of the above, when I backed up to the second drive of copied a valid backup file to it.

I haven't got inside the box (yet), but that's a good idea - thanks.

 

Did you try the cable swap ?

F.

 

Not yet - been doing my taxes.

Today I did some further testing with this. I re-created and reformatted the backup partition on drive 2 in several ways, with the same results:

- If the target 70gb partition is formatted NTFS, a new backup archive is corrupted, and a valid .tib file copied from the first NTFS drive to the partition gives a verify error.

- If the target 70gb partition is formatted as FAT32, a new backup archive is corrupted, and a valid .tib file copied to the partition gives the same verify error.

- I then created a TI Secure Zone, taking half of the space of the FAT32 partition. I can create and successfully verify a backup to the Secure Zone, but not to the remaining 30GB FAT32 partition.

It's pretty clear to me that this is not a disk error, as Windows backup has no difficulty using the NTFS partition on the second drive as a target, while both TI/Windows and TI/CD give the same reproducible error.

I'm wondering if this is perhaps related to my Athlon 64 X2 dual-processor configuration having an issue with the high-speed IO software that TI uses?