Ghost Solution Suite

Hello experts,

I made a ghost image from an NTFS partition with over 90GB data. Let me describe this procedure in detail, because I think it might help: it first created a 17GB gho file (say, pers.gho) in my first backup partition (D:) and then the partition ran out of space, so I specified another partition (C:) to store the next segment, a 80GB ghs file (pers001.ghs) was created. During that time, I realized the partition C did not have enough space as well, so I cleaned up the first partition (D:) and made up some space. After partiton C ran out of space, I specified partition D again and the third file (pers002.gho) was created, about 4GB. And the dump finished successfully.

Later I decide to recover the data in these files. I used ghost64 to do that, but after about 18GB data was recovered, ghost told me an 'unexpected end of file' error was encounted (error code 10008) (since I chose lite compress when dumping my partition, it might be exactly what the first 17GB gho file contained) and cannot continue. I tried to check the integrity of the gho file and got the same result.

Then I tried to open the image files with GhostExp (version 11.5.1.2266), and it tolds me to select the last segment, but either pers001.gho or pers002.gho did not work, GhostExp just told me to select the last segment again and again =(

I also did a hex dump to these image files in the way described in this topic:<http://www.symantec.com/connect/forums/ghost2003-explorer-cant-handle-multiple-segments-spread-hd-and-dvd>. The dumped files are in the attachment. May this would help.

Since the partition I dumped is cleared, it is the only way for me to recover the data. Please help me. Thanks very much.

Attachment(s)

hexdump.zip   13 KB 1 version

The person most likely to be able to help you is Nigel Bree, who although no longer with Symantec, does still provide support in these forums on occasion. His direct email is in the other thread you referenced, so it may be worth an email to see if he can help you further.

The object lesson here is that you should always check that an image is readable before losing the source, especially if you have had to scatter the image segments all over the IT landscape.

Hello EdT,

Thanks for your reply. I did write to Nigel at the first time but he told me that he could not help me neither. Does that mean I have no hope to get my data back? Really sad.

From looking at the dump you attached the image files are generally structurally OK - in the majority of cases where folks contact me they are all blank - so there's a lot of data there which is potentially recoverable, the problem is getting it out.

It used to be that if you sent the image to us at Symantec New Zealand I'd be able to work with it and the Ghost Explorer source code to figure out something, but since I had to give up all access to the file format specifications and the source code when I was laid off, you've really only got one option.

If you use the -ntexact or -ntc- switches to Ghost, then when it restore an image it tries hard to put things where they used to be in the original source filesystem. Normally this isn't important, because you want Ghost to rearrange things properly to suit the new disk, but due to some really stupid design faults if Ghost hits any kind of error during restore, it won't try and tidy up the data it did restore to make it valid based on where it relocated the data to in the restored system.

Because using the -ntexact and/or -ntc- switches puts things back in their original disk locations or as close to them as possible, there's no need for Ghost to rewrite as much to ensure that the restored data is structurally correct, and this means that when Ghost bails during an error, it's much more likely that what it did restore will make sense to Windows - this depends somewhat on the Ghost version you use, because newer versions of Ghost are more aggressive at changing things during restore and this is less likely to work. Certainly for old versions like Ghost 2003, this trick would generally at least mean that CHKDSK would be able to recover the restored filesystem to some kind of useful state, but whether the more recent versions do is very much more hit-and-miss.

Given that there's no real way to get this kind of situation looked at any more, this is basically your best hope.

Thank you Nigel, 

I tried to restore the image using the -ntexact switch but it doesn't change anything. It seems to be that ghost does not know how to find the next span, not bad image file.

I also tried to recover the GHS segement files directly, but ghost told me that the GHS file(s) I specified is not a Symantec Ghost file, or is not correct span segment.