Ghost Windows 7 Ultimate 32-bit All Driver All Program
Boone Southern
I am using GhostSuite 2.5 to create images for Windows 7. I start the session from GhostCast Server (version 11.5.1.2266) and use the USB Ghost Boot Disk to boot up the laptops that I need to restore the image to. I have been using this version for almost a year and have never had this problem before.
I have "backup" images of 2 important laptops, just in case anything happened to them. Well, they both had an issue this week & I am trying to restore the image that I had created for each of them a few months ago.
Here's what I do to create the images. I set up the session from GhostCast Server. I do DISK images for Windows 7 with FAST compression. I create the image on a local hard drive on the Ghost server (G: drive). I do this all of the time, and don't have any issues restoring.
Well, we ran out of room on the G: drive a few months ago, so I copied these 2 "backup" images out to a network share drive. Once they were finished copying, I opened up each one, just to make sure Ghost Explorer opened it OK so knew the image was still OK after copying it. Both images are very large (around 25 GB) so they took a long time to open off the network share drive, but they did open OK and I was able to browse folders in the image. Since I needed room on the G: drive, I deleted the 2 "backup" images that I had just copied out to the network drive.
Now, a few months later, both of the laptops need to be reimaged. So, I made room on the G: drive & copied both "backup" images from the network share drive back to the G: drive on the Ghost server. I tried to do a restore (the same way I always do), but I am getting the following error on BOTH images:
I normally use Multicast (I didn't realize there was a Unicast option), so I tried Unicast, but that didn't work either. I tried multiple switches. I tried to open the images off the G: drive & they open up fine. I tried to COMPILE the image into a different named image, but got the same decompression corruption error on the restore.
Both of these laptops have software installed that is a royal pain to get set up & configured, which is why I ghosted them as a backup to begin with. I just wanted to be able to restore these images instead of having to go through the time & hassle of reinstalling the software, etc.
From a number of past postings, it is my assessment that opening the images in Ghost Explorer may have led to the corruption. There is no specific evidence of this I can point to, but corruption and the use of Ghost Explorer have been reported together on too many occasions for this to be entirely coincidental in my personal opinion.
You made a passing reference to DOS - I also recall a user posting that his experiments had shown that an image size around 27Gb was the maximum he could generate using DOS. If you are currently using DOS, I would STRONGLY suggest moving to WinPE as this is sooooo much better with modern hardware.
Finally, I cannot advise you whether your images can be recovered in any way. This is an area where Nigel Bree, one of the former Ghost developers, would be able to advise you, so if he sees this posting he may be able to suggest a course of action.
Just to be clear, merely *opening* an image with Ghost Explorer cannot possibly corrupt an image for the simple reason (easily verified with Process Explorer) that Ghost Explorer does not open the files constituting an image read-write but rather opens them read-only. Also note that Explorer works with read-only files on CD, so... the simple fact is that working with image data strictly read-only is what it was actually created to do, and image modification was a separate feature added years later with entirely separate code paths up and down the line.
So it *is* possible to corrupt images with Ghost Explorer, but it requires deliberate action. You have to do something like drag-and-drop a file into the image and then kill the Explorer process (or have it run out of disk space, or hit a hard media error) *while it's rewriting the image*. When you use Explorer to do a destructive action (such as dragging and dropping a file into it) the underlying image file is closed and then re-opened read-write so that the explicit request to modify the content can be actioned. But not before!
It's also very true that Explorer is not, and never has been, any kind of useful guide to whether an image is structurally valid. It processes the image file in an entirely different way to Ghost, which is why the -CHKIMG flag exists and has been documented as the right way to check an image for structural validity for basically as long as the Ghost product has existed.
The 90% reason for reported image corruption on restore (other than damaged or marginal optical media) is driver failure/bad hardware. Usually the images are not corrupt when tested with -CHKIMG on a host system, but during restore (whether via network or some other method) reports failure; the ones of these cases that have been resolved with different drivers (actually, the cause is usually some form of in-system data corruption in the chipset which is worked around by a particular driver aware of the chipset bugs).
Beyond this, there's a small residual number of cases which have been reported over the years which aren't easily explainable and in which an image fails to verify with -CHKIMG immediately on creation; unfortunately, no such case ever resulted in a customer willing to supply said image for developer analysis and recovery. It may well be that the underlying trigger is a subtle fault in Ghost which is data-dependent, and that a small number of particular image files contain a specific data pattern which causes a repeatable failure. However, no case like that ever resulted in a customer willing to supply an image to determine the cause (note that up to 2009 when the site was closed, we at Symantec New Zealand had a standing offer to ship image data to us at our expense for analysis and we would make a best effort to recover it at no charge).
For instance, if there was a subtle fault in the data-decompression code, it might live undetected and only appear in some specific images, because data compression is an innately data-dependent process with subtle edge cases. A fault which affected, say, one in 2^16 images because they contained a data-dependent boundary fault would be almost impossible to detect until someone ran into an image which was structurally valid but triggered that code path and failed to restore - once such an image which had such a fault emerged, discovering the cause using a debugger would be simplicity itself, but having the trigger data would be crucial for determining the cause.
Maybe such a category of error exists; it's certainly not beyond the bounds of possibility, and back in the day we'd certainly have been willing to pursue that possibility. Quite what the best approach now is, I can't suggest much. Ghost Explorer should be able to recover most of the files from the image (since as I noted above, it uses different techniques and code to process the data in the image file than Ghost does), but in general when -CHKIMG fails then Ghost has no recourse to continue and you can't use it. So, Explorer is the only route.
Unfortunately in terms of official Symantec support, I suspect now there's basically nothing. While I'm sure the current maintenance team would be more than willing to take on recovering customer data just as the original team used to be (the current team are good guys, committed to customer care, and understand how doing that kind of work is important for the health of the product) my understanding of their situation is that they can't take on work not explicitly referred to them from Technical Support - they are just too underfunded and understaffed for the job of GSS maintenance.
Nigel - are there any boundary conditions when creating large images using DOS ? A customer reported that DOS images appeared to fail around the 27Gb size, but do you happen to know if this corresponds to a known factor or is just heresay?
I don't think so. We did our own internal tests regularly with DOS-based imaging on images *way* bigger than that from around 2004 onwards (as 2Tb disk arrays started appearing then, so support for >2Tb NTFS filesystems was a big push in the Ghost Enterprise 8.x releases). If there was a specific problem with Ghost and mere image size, we'd have heard about it bigtime sometime in the last 6 years.
Internally, Ghost's structure for abstracting platform differences like DOS files/Win32 files/GhostCast/direct NTFS over IDE/ASPI wasn't ideal, but it worked well enough that I really don't recall an issue like that in Ghost.
One image-file-size bug did slip through our QA during that era, incidentally, but it wasn't in Ghost. We changed versions of Visual Studio we built with in one release and for some reason one of the library functions in Visual Studio that took a 64-bit file offset was changed to silently truncate the value to a 32-bit offset. My memory (which is a bit hazy now, this was years ago) is that it bit Explorer when working with unsplit GHOs. However, that was the only error like that I can ever recall, and it appeared at the 2Gb boundary, and it was an "oops, here's a new executable on the FTP site" fix really fast after release.
I always open the images in Ghost Explorer afterwards and have never had this problem until now. The only thing different was that I opened them off of the network share, which took FOREVER to open them since they are so big and it had to pull it off the network.
I wasn't really in doubt that the server to server data copy might not have generated a faithful copy. My being overly cautious is the only reason that I open them up in Ghost Explorer afterwards. I only use the basics in Ghost & I was not even aware that this was not a valid way to test the integrity of an image. I always assumed if it opened up, then the image was OK.
I definitely wouldn't have dragged and droppeda file into the image or anything like that. The only thing I MAY have done (I don't think I did, but it's possible) is clicking the X to close the image before it completely opened up in Ghost Explorer off the network drive since it took a really long time.
b37509886e