Ghost 15 ebab03f1 on Verification Pass in Windows 7

New to this forum and I hope I'm posting this correctly.

 

I have Ghost 15 installed on Windows 7 (Ultimate ed.) and am using a USB connected external hard drive as a destination for whole system backups.  Compression is on (Normal), and the backup is configured to backup all but the destination drive ... I thought recursion might be a problem :-) ...

 

The backup completes for all drives, but when the verification pass gets to the point of verifying the Windows/7 system boot drive (that little chunk of disk that Windows/7 uses to store boot configuration) the process stops with an ebab03f1 error indicating a "cyclic redundancy check."

 

I've already done a very thorough "scrub" of both the source and destination drives for bad sectors, I tried removing and re-installing Ghost 15. I tried backing up the drives individually (the boot config drive backed up and verified, the C: drive didn't, but "scrubbing" the C: drive says everything is fine).  If I turn off verification on the C: drive backup (doing the drives independently), the job completes (so we don't have a problem backing up the drive, but we do when we try to verify the backup ... hmmmmm) ... I'd think that a cyclic redundancy check problem would happen any time you try to read from a drive with a "bad spot" on it.

 

Anybody got a clue what else to try?

It's a usb 2.0 port on the computer's motherboard (Lenovo T400) and a commercial USB harddrive.  The drive works fine on the adapter for regular copy or retrieval functions.  Ghost just seems to have a problem reading back it's backup image for verification.  I suspect the error code being issued is BOGUS.  That is, it's a code leak into some error routine we should not be in for the problem being experienced.

 

I suspect it's something having to do with security.  The userid in use is an administrator (in the administrators group), but I've noticed that Microsoft has determined that there are some things that even administrators are not "good enough" to touch (Sorta wish they'd recognize that I own the machine ... it's mine ... I choose to use their OS ... that could change).

 

Anyway, I'm pretty sure the drive and interface is functioning properly because of the "Norton independent" tests of read/write access, and the fact that a "CHKDSK /F /R C:" runs end-to-end without a single bad sector complaint, and it tests both allocated and unallocated disk surface.

 

New to this forum and I hope I'm posting this correctly.

 

I have Ghost 15 installed on Windows 7 (Ultimate ed.) and am using a USB connected external hard drive as a destination for whole system backups.  Compression is on (Normal), and the backup is configured to backup all but the destination drive ... I thought recursion might be a problem :-) ...

 

The backup completes for all drives, but when the verification pass gets to the point of verifying the Windows/7 system boot drive (that little chunk of disk that Windows/7 uses to store boot configuration) the process stops with an ebab03f1 error indicating a "cyclic redundancy check."

 

I've already done a very thorough "scrub" of both the source and destination drives for bad sectors, I tried removing and re-installing Ghost 15. I tried backing up the drives individually (the boot config drive backed up and verified, the C: drive didn't, but "scrubbing" the C: drive says everything is fine).  If I turn off verification on the C: drive backup (doing the drives independently), the job completes (so we don't have a problem backing up the drive, but we do when we try to verify the backup ... hmmmmm) ... I'd think that a cyclic redundancy check problem would happen any time you try to read from a drive with a "bad spot" on it.

 

Anybody got a clue what else to try?

ElGringoGeek,

 

Verify serves primarily to catch errors that occur between the system memory and the target drive.  This includes the CPU, mainboard caches, data cables, the IDE/SATA/USB/IEEE 1394 controller, and the target drive itself. The most likely culprit is system memory and it can be difficult to prove. We have a thread where a member ran several tests including overnight MemTest86+.  All tests passed. The Verify errors disappeared after new RAM modules were swapped in.

 

If you have a spare HD could you try to restore your images? A restore will probably fail.

I have 5 backup images of the Windows/7 "barefoot" instalation on this HDD and none of them will restore.  I have alternate memory for the machine, installed it and none of the images will restore.  I have an alternate disk drive for the machine, installed it and none of the images will restore (OK, so maybe somethings wrong with those images or the HDD.

 

I have installed a barefoot Windows/7 on the alternate HDD (the usual 2 partitions).  I've attempted to back that drive up to a different output media (just in case the backup media is the problem), because, of course, Ghost tells me there is a CRC error and does not tell me what device the error occurred on.  That process gets me a CRC error (different error code ... 0x0e7d0001 if I recall correctly.

 

The only thing I haven't tried is replacing the entire machine and availability is an issue in that regard.

 

Verify is supposed to verify that the image taken to the backup media matches, after the fact, the disk from which that image was taken.  Granted that mainboard memory is involved, but that usually would get you BSOD problems, I wouldn't expect a memory failure to be picked up as a CRC error although I suppose it is possible.

 

As I said in a previous post, the backup media is a USB connected HDD.  I use it extensively for operations other than backup without the slightest problem.

 

I'm a big fan of the KISS methodology ("Keep it simple, stupid!").  It seems to me that Norton is missing a tool (which at least should be on the standalone boot CD) that simply allows me to take a sector by sector copy of the drive as a backup (no fancy stuff like compression, etc.) and allows me to restore that sector by sector copy to the same type of disk (or maybe an alternate, but that's a different discussion).  The concept being shear safety ... when you have problems with Ghost, use this to prove that a simple methodology works.

 

The bells and whistles are nice, but in the end ... success and simplicity wins.

 

I'm  running out of hardware things to try, and it seems WAY ODD that Ghost gets all the way to the closing moments of a backup or restore before failing.  Lots of physical I/O and buffer management going on and the failure point is ALWAYS in the last few seconds of the operation ... what's the probability of that?

 


ElGringoGeek wrote: *SNIP*  It seems to me that Norton is missing a tool (which at least should be on the standalone boot CD) that simply allows me to take a sector by sector copy of the drive as a backup (no fancy stuff like compression, etc.) and allows me to restore that sector by sector copy to the same type of disk (or maybe an alternate, but that's a different discussion). *SNIP*

 

See the attached image. I believe this is as close to sector by sector cloning you can get with Ghost 15.

 

5323iA82638E53F62767A

 


ElGringoGeek wrote:

 

The only thing I haven't tried is replacing the entire machine and availability is an issue in that regard.

 


 

ElGringoGeek,

 

You have done some great testing on this. I'm starting to get lost by the amount of detail in this thread but have you tried creating the images to an internal HD or to a different external HD? Creating an image to another partition on HD0 would be acceptable too. Then see if it verifies.

 

Restoring an image to a HD in another computer would be informative as well. If it work it tells us there is something wrong with your computer. But if it doesn't work your external HD or the image itself could be the problem.

 

My feeling is that you have a hardware issue.