I'll try the verification test, but my image averages 100-120GB of the 160GB drive, so no spare space to test with.  If it verifies with the recovery disk I will consider that success.  Thanks for the suggestion. 

I'm also looking to get a v10 recovery disc, assuming the 9 doesn't work.

Does this 'solution' mean there's a corrupt file on the original ghost 9 disc or a version of one of the core components that got updated later on?

I got my hands on a Ghost 10 bootable disc and I was able to verify the image, so it appears everything is magically fine now...

This system of doing a weekly backup is the easiest, most effective means for me to have my data and apps backed up for a possible hard drive failure.  I find incrementals leaves more room for software error.  I simple have a second hard drive with twice the capacity and always have one image (last weeks) saved until the new image is completed and verified by ghost.  It's hardly "inefficient".  it's actually quite effective since the only time I would be using the image I create is if the primary/backed-up drive fails.  This is for my home setup, not for a client.  Most of the business clients use veritas, which comes with its own issues as you're probably well aware.  :p

No problem Brian.

I didn't even try the 9 disc because I ended up getting the v10 disc and didn't want to waste time trying 9 just to find out it didn't work.  I'll keep the v10 disc for restores and the retail v9 30MB package for installs.  All symantec cares is that you have a valid key.

The bottom line is that no matter what I tried I couldn't get my copy of v9 to work.  It wasn't until I tried the smaller, non-bootable version that this started to work again.  I find that highly suspect, and if I had to guess their release of the bootable CD was premature and fixed their mistake later on in the downloadable/non-boot package.  We'll see if more people use this as a solution.   That will be all the 'proof' we need of the cause...

stoopid wrote on Nov 4^th, 2006 at 12:24am:

I've found that Ghost 10 will restore a ver 9 image but Ghost 9 will only occasionally restore a ver 10 image. It usually gives an error.

Hi, it's me again.  lol

Tried True Image, and during the verification it failed.  So I determined that I would change around drives on the ide cable.  Loaded ghost again, got through the first backup... now to see if it works next week.  I haven't given up, but the fact True IMage also failed, and I don't believe it's the same PQI engine, indicated a problem in my configuration.  Why this suddenly became a problem beats me.  Perhaps I've always been riding the edge of stability or data integrity with transfers between the drives and something finally pushed my system over that edge.  Your guess is as good as mine, and I'll report back later next week to report if it's still a ghost issue or a problem resulting from a flakey ide setup.

Ghost works now.  Appears I was getting data corruption between ide drives.

Now for a partial admission of fault - I originally had both hard drives on the same cable (see username ).  It really has to do with placement of storage devices in my crowded mini tower (HTPC).  I surrendered to having to attach mounts so the second hard drive could go into the 5.25" slot under the dvdrw drive, and thus be a slave on that ide cable/channel rather than be a slave with the main hard drive on the same channel.

My original thinking was that this was working for many many months and then stopped.  Seeing others with the same problem confirmed my fears, but it seems I was wrong in my initial conclusions.

The way IDE controllers work (been a while since my A+ class, but here goes) is that the devices on the same cable/channel cannot be performing tasks at the same time.  It's not that it refuses to copy data, but it puts a lot of stress on the controller to do its job, having to constantly start reading from one drive to stop for a millisecond to write that data to the other drive.  This will slow things down as well as increase the potential for errors. In all that extra work a one or zero gets lost and data verification will obviously fail.

I probably should have looked up the details of ide technology on wikipedia/about.com or something before posting this as I'm sure some of it is wrong, but it's really not important I understand why so long as I follow the rule to have storage devices on separate ide cables/channels whenever possible.

It's been awhile since I have visited this thread, but the problem documented by stoopid seems to conform to my earlier thoughts. I am wondering if stoopid had ran ECC or registered RAM (OK, registered is overkill for a home system, but ECC?) if this problem would have manifested itself differently?

We all do stupid stuff when building our own rigs (otherwise I would be the next Michael Dell) which is why I like the added insurance of ECC (not that my laptop has any, so who am I to point fingers. Well, it is a Dell! But then again, I deleted all their hidden and not so hidden partitions, GHOST 2003 don't fail me now!)

My point was that ECC RAM may have trapped the bad calls the IDE controller was sending and either corrected the problem or halted the process? More generally, I much rather have an image write fail than succeed only to discover months later that the image is corrupted because a solar flare occurred during the write process.

A 100 GB image is a lot of 1's and 0's that have to be exactly right with no mistakes whereas I may never discover the one file that was corrupted in a back up process of 100 GB of data files.