Ghost Solution Suite

I'm using ghost32.exe/ghost64.exe 11.5.1.2266 to backup TrueCrypt-encrypted system partition of Windows7 x64. Because of encryption I have to use ghost's "OS volumes" feature. When restoring this partition (from WinPE or another Windows instance) I have 2 possibilities: 1) restore to partition (and lose the encryption) - this works and the OS is successfuly booting 2) mount the volume in TrueCrypt using "Mount partition using system encryption without pre-boot authentication" option and restore to corresponding "OS volumes disk" volume (and save the encryption) But then when booting, the TrueCrypt Boot Loader ends with error of type Cannot read sector 4567893245. I compared NTFS boot sector after restore against its original version and found that these two items in Bios Parameters Block (NTFS BPB) differ: 1Ah WORD Total number of heads/sides 0x0001 instead of 0x00FF (255) 1Ch DWORD Number of hidden sectors (those preceding the boot sector) seems random instead of 0x00000800 (2048) After manual correcting this, the restored OS boots without problems. Can someone review this issue ? Thanks

Who did you have in mind?  With Nigel Bree now gone from Symantec, there are fewer employee visitors to these user forums.

It would also help if you could confirm whether the issue you describe applies to ALL the different hardware PCs you are working with, or only apply to a specific model (or models) in which case the exact model and bios version would be good to know.

Also, are your systems equipped with SATA hard disks, are you booting WinPE and are you using compatibility mode or AHCI settings in the bios (if SATA disks are present)?

I'm new to this forum and I would appreciate other users' experience with restore operation to single "OS volumes disk" volume. In fact, I have run the described scenario only on my notebook as I have no oportunity to test on other computers. My configuration is Asus M70Sr notebook with HDD in SATA/AHCI-only mode, AMI BIOS version 206 08/06/2008. My suspicion is that Ghost incorrectly gets the two BPB values from "OS volumes disk" (reports number of heads = 1 :-) instead of from the real target disk (number of heads, partition offset). As I mentioned above, when restoring directly to partition, original (and correct) values are writen to BPB.

DOS or WinPE  boot?

First, to answer your question: to make an image of my single (bootable and system) partition using ghost "OS volumes feature" I (can) use ghost hot-imaging (VSS volume snapshot) on the running system, another instance of Windows or WinPE 3. Restore operation (again using "OS volumes feature") can be accomplished in the two latter environments. The combination of backup-restore environments doesn't matter in this case, I think. (I don't use DOS a long time :-) I'm facing the problem when booting the restored partition. The boot sequence should be: BIOS -> TrueCrypt Boot Loader in disk track 0 -> NTFS boot block code -> bootmgr ..... But I end up in NTFS boot block code (probably) with Cannot read sector NNN error because of incorrect values (Number of hidden sectors and/or number of heads) in NTFS boot sector. And now, how you could simulate the problem: 1) make new image file using ImDisk (without MBR), format it NTFS and mount it as non-removable (to be visible in the list of "OS volumes") (http://www.ltr-data.se/opencode.html/#ImDisk , you may use another similar software, I think) 2) look at offset 1Ch (DWORD) of the image file by hex viewer, you should see NTFS boot sector and the value 0x1 or 0x0 3) call ghost32/64.exe -dd and in GHSTSTAT.TXT find the reported VolumeSectorOffset of this volume 4) create .gho file of the volume using "OS volumes feature" 5) restore .gho back 6) again, look at offset 1Ch (DWORD) of the image file, it will probably contain the value reported in GHSTSTAT.TXT and not the original 7) make a copy of ImDisk image file, mount it with another letter and restore already created .gho file to it 8) check the value in NTFS boot sector - will contain another (higher) value reported for this "OS volumes" volume as VolumeSectorOffset Similar issue with Total number of heads/sides value. I will test if this value alone influences my ability to boot. And that's all for now :-) Thanks for your attention