Probable Validiation Solution Found

I sent this into Acronis tech support which should prove quite useful for people having issues with backup validation and corrupt reporting by True Image Home 10 (or whatever version):

OS: Windows XP Pro SP2
Product: Acronis True Image 10 Home (latest build installed)

I (like many others) have problems with validating backups which have been copied using the windows standard copy and command prompt copies (usually the md5 hash values differ and render the backup as 'corrupt'). Here is a solution which should work in almost all cases for either USB or Firewire external hard drive units:

If you are backing up a drive (say My Computer) and you have enough disk space (or a 2nd internal HD with lots of free space), you can do a local backup and then validate it (which should be fine).

After I did this, I ran an md5 hash against the backup I created (about 28GB in size). here is the output from FSUM using -md5 as the option:

; SlavaSoft Optimizing Checksum Utility - fsum 2.52.00337 <www.slavasoft.com>
;
; Generated on 09/30/07 at 16:23:18
;
1be49928cb3db209c27d7ac8645dd809 *drive-c.tib

Then I set up Microsoft SyncToy (latest version is 1.4 and works in XP or Vista), and is designed to keep stuff synced between local and external hard drives, pretty much hassle free. After doing this and having the backup file sync over to my USB external HD unit (Quantum 3.5" mobile drive, with 500GB PATA inside), I then computed the md5 hash for the file on the USB external drive (which is an exact match for the one on the local hard drive, and I also validated the copy on the external USB drive as good through Acronis True Image 10 Home). Here is the hash value computed for the file synced to the External USB HD:

; SlavaSoft Optimizing Checksum Utility - fsum 2.52.00337 <www.slavasoft.com>
;
; Generated on 09/30/07 at 18:13:00
;
1be49928cb3db209c27d7ac8645dd809 *drive-c.tib

While it's NOT an ideal solution, this should help people who are being hit with the 'corrupt' problem during backup validation (hope this helps)

 

The TI validate mechanism is essentially the same method but calculates an individual checksum for each 256K bytes instead of the whole file.

Using another checksum calculator as you did is useful for checking out basic file transfer fidelity in Windows but does not do anything for confirming the transfer fidelity when using the Linux recovery environment which is a completely different set of device drivers.

 

Well, I suspect the Microsoft SyncToy aided in the proper transfer of the image from HD to external USB Hard Drive Enclosure, as the checksums were the same, after the transfer was completed (and it's easy to use). I'm not sure about the backup directly to USB External HD Units (or Firewire 1394a/b either).

 

I hope this helps those with whatever the problem is. As I never bother to validate I'm just curious to know what is happening here. Are you saying that some people are making local images which validate ok but when copied to another drive the validation fails ? or is it the case that when copied the images can no longer be restored ? I do sometimes make an image to another partition and then later cut and paste to an external. the image from the external restores ok.

 

I would expect the Windows Copy command to be one of the most debugged commands on the face of the earth - not necessarily by MS developers but by the millions of people who use it every day. If you can't reliably use Windows to copy large files to another device then you likely have a bad device, cable, or device driver.

 

This has been reported, usually with external drives. It usually is a chipset in the PC/USB drive that don't like very large files or a bad cable. Sometimes a bad disk in the external case as well.

Using the XCSC free checksum calculator or equivalent will reveal the problem as well as a TI validate.

 

Thanks - but it sounds like they are not only failing to validate but the process of transfer is really making them useless ?

 

I would say it is impossible to alter the contents of a file and still have the checksum remain the same. If it won't validate then it certainly is very unlikely it will restore properly. AFAIK, the TI restore evaluates the checksums as it proceeds through the archive ensuring it is getting valid data from the archive file.

It is possible to corrupt the file on writing because of a HW or SW fault and once this happens it is indeed useless.

 

I had that validation thing happen once when transferring between internal hard drives. At the time I didn't know you could defrag drives with TI images, and I thought moving them to another HDD and then back would do the job safely.
It didn't. Fortunately, I had copied the image that got "corrupted" to DVD first, and then copied that to an external drive to validate, so I didn't lose the image.
All drives involved checked out OK, as did my RAM, and I wasn't able to duplicate the incident.

 

I wonder too about cables. I have two ext. USB drives - one in an Icy Box enclosure and the other is an integrated Seagate USB drive. The USB cable supplied with the Seagate drive is double the thickness of the the cable supplied with the Icy Box. I use the Seagate cable for both drives and images copied to both drives validate without any problem from the recovery CD.

I just wish all the enclosure and ext drive manufacturers would standardise their power connectors - the icy Box uses a six pin DIN plug for power !