Any comments and experience welcomed.
I used a 40 GB GPT HD containing a 10 GB partition. The partition was seen in Ghost and could be used as a destination drive. ie I could write an image of the Win7 partition to the 10 GB GPT partition.
Ghost 15 could not create an image of the 10 GB partition and could not do a Copy Drive of the partition.
Brian_K wrote:Any comments and experience welcomed.
I used a 40 GB GPT HD containing a 10 GB partition. The partition was seen in Ghost and could be used as a destination drive. ie I could write an image of the Win7 partition to the 10 GB GPT partition.
Ghost 15 could not create an image of the 10 GB partition and could not do a Copy Drive of the partition.
Hi, Brian. This is consistent with the Ghost 15 Documentation. My understanding is as follows:
Ghost 15 knows how to use a non-bootable GPT Partition as a Target Destination. Ghost also knows how to use a GPT Partition as the location for a Source file for an image Restore of an MBR-style 48-bit-LBA Partition. This implies Ghost 15 can write to a GPT-style Target Partition during a Backup - or read that GPT Source Partition's image file during a Restore - using the same kind of system calls Ghost would use to write/restore to/from a Network Share.
However, to Backup a GPT partition, Ghost must be able to build an *.sv2i file with a copy of the MBR, the 48-bit-LBA Partition Table data and the GPT data - when it backs up all the Partition Info for that Source Partition on a Hard Disk with a GPT as well. The problem is, Ghost knows absolutely nothing about what it needs to do to be able to read the needed GPT information from the source Hard Disk's Partition Table - and incorporate that info into the *.sv2i file. Thusly, even if Ghost were permitted to Back Up a GPT Partition - it would not be able to restore said Partition.
During a Restore of an MBR Partition to an empty Drive - the *sv2i file data is a critical component which allows the automatic "rebuilding" of the MBR-style 48-bit-LBA Partition info - onto the Target Hard Disk. However, if Ghost wanted to Restore a stored image of a GPT partition to an empty hard drive, Ghost would have to have a complete set of Partition Table data, containing the MBR, the 48-Bit-LBA Partition Table data and the GPT data - in order to perform said successful Restore of a GPT Partition. This requires the data in the image file's *.sv2i file to contain the GPT data as well. Without that GPT Partition info - Ghost is unable to create a GPT-style Target Partition Table during said Restore.
Note: The size of the partition is irrelevant. To restore a GPT Partition - on needs to restore the GPT. If the GPT is not restored as part of a Ghost Restore - a backed-up GPT Partition's data is useless. Consequently, Ghost 15 is set up to prohibit the backup of GPT Partitions in its present form.
Another wrinkle:
When overwriting an image to a Target Drive with an existing set of partitions - Ghost compares the info in the Source Image's *.sv2i file against the info it builds by examining the Partition Table on the Target Drive. If this data matches, Ghost will give you a "Green Light" automatically when you go to overwrite the Target Partition.
However, if the info in the Source Image's *.sv2i file does not match the info that Ghost builds by examining the Partition Table on the Target Drive - Ghost refuses to generate a "Green Light" for that automatically-enabled overwrite. This is quite correct.
In order to overwrite a Target Partition with a Source Image where the Partition signatures are mismatched - it is necessary to manually select the Source Image file and then also manually select the Target Partition on the Target Hard Disk. Ghost then knows you are instructing it to cross-match between the two Partitions - and assumes you know what you are doing. Thus - at the end of the manual selection process - Ghost will give you a "Green Light" and do the required translation to allow the overwrite to occur - even though the source and target signatures and Partition Tables mismatch.
The above process works fine when working with MBR-style 48-bit-LBA partition tables, because it is possible to source and target-match the Partition data - as well as translate when restoring an image sourced from one Hard Disk Partition to a different target Partition. With full information on both sets of geometries - Ghost can understand the required translation parameters between the Source partition-table-data in the *.sv2i file and the Target partition-table-data it builds from the Target Hard Disk - in order to Restore the image file's data to a Target partition on a different Hard Disk or a different partition on the same Hard disk.
However, when overwriting a GPT partition, it is necessary to be able to compare the GPT data in the *.sv2i file against the MBR, the 48-bit-LBA Partition Table and the GPT data read from the Target drive. Furthermore, because said GPT data does not exist in the Ghost 15 *.sv2i file in its current form - and Ghost 15 does not know how to translate a GPT Partition in an *.sv2i file into a valid GPT entry for the Target Partition - there is no way to perform the Restore.
There are several things which must be updated for Backup of GPT Partitions to be supported. First, Ghost must be recoded to be able to read GPT data and store said data into the *.sv2i file when backing up any Source Partition on a Hard Disk with GPT Partitions on it. Secondly, Ghost must be able to read existing GPT data (if it exists) on a Target Disk - compare the read data to the data in the new-style *.sv2i file - translate the Partition Table on the Target Disk into a form which is compatible with the both the Target Disk's geometry and the Source File's GPT data - create or modify the appropriate GPT parameters on the Target Disk - and then do the required MFT translation as part of the Restore of the selected Partition.
Once Ghost is updated to do the above (at minimum) Backup and Restore of GPT Partitions will be supported. However, there is a whole lot more to the process. Sanity checks on the GPT. Sanity checks on the size of a created GPT Partition on the Target Drive - to ensure the Target GPT Partition is large enough to hold the Source file's data. Bad sector handling on a GPT Partition - both during backup and restore. Verification of GPT data during Backup. Verification of GPT data during Restore. Sanity checks on the UEFI/GPT interfacing to ensure that however the stored GPT Partition is restored - the UEFI BIOS will be able to read the updated GPT that Ghost creates on the Target.
And that's just the stuff I can think of off the top of my head. I'm sure there's hairier stuff I've not thought about or come up with bulletproofing procedures for - such as mixed MBR with 48-bit-LBA Partition and GPT Source environments - and the translation between the two when restoring a 48-bit-LBA partition to a Target Hard Disk that's all-GPT. And what about tying the restore of a Windows OS Partition to its associated EFI System Partition, OEM Partition (if any) and MSR - including getting that stuff in the right order - as well as ensuring the rest of the GPT Partitions have no "stray" stuff interspersed between them - so spanning is not obstructed. IMO, the required sanity checks on that stuff are going to be rather formidable. 
See the following for more details on how GPT Architecture must be maintained when moving an OS between Hard Disks - as well as how the size of some of the GPT Partitions change automatically depending upon the Target Hard Disk's size.
http://msdn.microsoft.com/en-us/windows/hardware/gg463525
Logic for all this stuff will have to be built into a "GPT-aware" version of Ghost.
Hope this helps your understanding.
Any comments and experience welcomed.
I used a 40 GB GPT HD containing a 10 GB partition. The partition was seen in Ghost and could be used as a destination drive. ie I could write an image of the Win7 partition to the 10 GB GPT partition.
Ghost 15 could not create an image of the 10 GB partition and could not do a Copy Drive of the partition.
twixt wrote
During a Restore of an MBR Partition to an empty Drive - the *sv2i file data is a critical component which allows the automatic "rebuilding" of the MBR-style 48-bit-LBA Partition info - onto the Target Hard Disk.
twixt,
Thanks for confirming we should avoid GPT partitions unless they are necessary. Such as a HD larger than 2 TB.
I'll have to disagree with your above statement. The .sv2i is of no use to me. I usually delete it as I don't do multi-partition restores. As a test, I marked a sector in the first track so I'd know if Ghost was restoring the correct MBR (actually the First Track). Ghost then imaged the OS partition on that HD. All the Ghost backup files except the .v2i were deleted. The First Track on that HD was then zeroed with a Disk Editor. The Ghost image was restored along with the "Restore MBR" option. I checked with a Disk Editor and the marked First Track had been restored. So all that is needed for a Ghost restore to an empty HD with no MBR is the .v2i.
What happend when you tried Brian?
You said the GPT partition could be seen by Ghost, did it not let you select it as a source for the image or did it start the image creation and then give you an error?
Dave
Dave,
I'm really pleased you asked that question because I hadn't recorded the error message for the failed image backup and Copy Drive. I think it was along the lines of a VSS error. No problem, I'll do it again.
I restored my Win7 image which contained Ghost 15 so the test computer was as before. I recreated a 10 GB GPT partition on the 40 GB HD. This time I was able to create an image of the GPT partition and do a Copy Drive. I deleted the 10 GB GPT partition and from the Ghost CD RE restored the image to the unallocated space on the GPT HD. The previous files were present in the restored partition so I know it worked. Easy.
I withdraw my comments about Ghost 15 not being able to work with my GPT partition.
Edit... The restore works whether a .sv2i is present or not.
Thanks for doing that again Brian. It's odd it didn't work the first time because you must have used the same tool to make the partitions.
Maybe Ghost 15 is fine with them as long as they are under 2TB and not the system partition.
Guess we need someone that can boot to EFI to check that last one.
Dave
Edit- By the way, when you make a cold image Ghost doesn't make a .sv2i file. If it was necessary and contained anything of importance I'm sure it would.
Brian_K wrote:
twixt wrote
During a Restore of an MBR Partition to an empty Drive - the *sv2i file data is a critical component which allows the automatic "rebuilding" of the MBR-style 48-bit-LBA Partition info - onto the Target Hard Disk.
twixt,
Thanks for confirming we should avoid GPT partitions unless they are necessary. Such as a HD larger than 2 TB.
I'll have to disagree with your above statement. The .sv2i is of no use to me. I usually delete it as I don't do multi-partition restores. As a test, I marked a sector in the first track so I'd know if Ghost was restoring the correct MBR (actually the First Track). Ghost then imaged the OS partition on that HD. All the Ghost backup files except the .v2i were deleted. The First Track on that HD was then zeroed with a Disk Editor. The Ghost image was restored along with the "Restore MBR" option. I checked with a Disk Editor and the marked First Track had been restored. So all that is needed for a Ghost restore to an empty HD with no MBR is the .v2i.
Hi, Brian. OK, then what would you do in a situation where you did have to restore multiple partitions and place them in a certain order on the disk - as is necessary with the hidden Lenovo or Sony Repair/Reinstall Partitions even today?
I banged into that one the hard way, upgrading an IBM ThinkPad Laptop to a larger Hard Disk. I restored the Partitions in the wrong order onto the replacement larger Disk - and found that the laptop would not properly boot into the Restore/Diagnostic partition using the button procedure during laptop boot - because I had restored the partitions in the wrong order.
Thus, I had to go back and erase track0 - and then do the two restores in the correct order - before the replacement Hard Disk had the functionality of the original. Because I was doing a bare-metal Restore, Ghost had nothing to compare to on the Target - so permission was given regardless of order. Now, I know to use something like Partition Magic to verify the Partition Order on a disk before I do a bare-metal restore - so I get the order right the first time.
It would have been nice if Ghost had told me the order of the partitions on the Original drive - and warned me that I was restoring in the wrong order. I guess that feature hasn't been implemented yet. It will be a required feature for bare-metal restores on machines with bootable Windows OS using GPT.
A bare-metal restore is a unique situation. By far the most common Ghost restores are overwrites of existing data on the same Hard Disk, or transfers of Partition Data between different partitions. Without a map of the source and target partition tables to compare against each other - how is the translation-matrix calculated for the new sector-addressing scheme on the Target Drive versus the old sector-addressing scheme copied by Ghost from the Source Drive?
And then what about restoring an existing MBR and 48-bit-LBA Partition-style Bootable-OS-image onto a GPT Disk? That's going to be a very common scenario in a couple of years - so support for this is mandatory if a new version is created. But here we go again - more translation-matrix-calculation requirements between 48-bit and 64-bit addressing schemes, as well as the creation of an appropriately sized GPT Partition (including resizing options) based on the info from a 48-bit source image.
Now, let's look a little more deeply at the situation with any Bootable GPT version of Windows. Can you see what kind of thoroughgoing mess a bare-metal-restore would be without Partition Order and Partition Size guidance on a W7 box - where we have specific Microsoft-mandated Partition Order and size requirements? The GPT-Partition Layout of EFI, OEM, MSR and OS partitions must be preserved - while it may be prudent to make the EFI, OEM, and MSR Partition Areas larger on that target - to prevent partition-capacity exhaustion.
I can already see the need for utilities to resize the EFI, OEM and MSR areas being required over the next 5-10 years - as 4TB, then 8TB, then 16TB drives become commonplace. With that kind of size available - manufacturers are going to start populating the EFI, OEM and MSR areas with ever-growing amounts of functionality. The design of the "new" Ghost should be able to handle this - by at least giving the user options during a bare-metal restore to increase the size of those partitions during the creation process - when doing a bare-metal restore.
And don't forget the reverse process when making an image - which must contain all the various partitions the Bootable OS requires - as a package - when doing a backup of the OS Partition.
Then, if there is the ability to resize the EFI, OEM and MSR areas during a bare-metal restore - this automatically generates a more-complex translation-matrix when restoring the data from the source OS-image to the Target GPT partitions.
And what about overwrite logic - where it is necessary to compare the Partition Table on the source with the Partition Table on the Target - generating the necessary "nope, won't auto-overwrite this" or "yup, go ahead" response? That feature will have to be retained and the logic extended to GPT. Then, what about crossfeed-overwrite and doing the required translation when the user opts to manually direct a source image to an unrelated target partition?
There are situations where a *.sv2i file is irrelevant. That's not all situations. Right now, you are doing specific things with Ghost - where you intelligently manage the Partition Table during a restore process to ensure the desired result. That is most certainly not the typical kind of user that Ghost must accommodate. Typical users expect Ghost to handle all that Partition Housekeeping behind-the-scenes so things "just work".
For normal users, the program must supply said intelligence - since people like you are a distinct minority in the general computing population. 
Dave,
I'm glad I did the test again because it showed Ghost 15 can create an image of a GPT partition and restore that partition. I've no idea why it didn't work the first time. Maybe if I had rebooted and tried again.......
On a lighter note, I got a kick out of demonstating Ghost 15 is smarter than we give it credit. Twixt said, "Consequently, Ghost 15 is set up to prohibit the backup of GPT Partitions in its present form." and "Thusly, even if Ghost were permitted to Back Up a GPT Partition - it would not be able to restore said Partition." It seems it can do both.
I'm glad you did it again too, I got a kick out of that too.
There was a similar statement made in the NIS section about Norton absolutly not being able to virus scan a GPT drive on a RAID array. Until a Symantec employee said that he has a 5TB RAID 5 array and Norton scans it just fine.
However, it takes a while to scan that much data.
Dave
An MBR drive size limit has nothing to with 32bit, 48bit, or 64bit addressing.
It's simply an oversight that when they designed the partition table they only specified a tiny little space for the size. I can't recall but I think it is either 4 bits or 4 bytes.
The biggest number that fits in that space is 4096, you multiply that by the standard sector size of 512 bytes and you come up with 2TB.
It has nothing to do with addressing, a 32bit single NTFS file could be 4TB if it were not for the partition table limitation.
On a 64 bit system it could be whatever the heck 2 to the 64'th power is. (2^64)
But also keep in mind that hard drive manufactures are switching to "advanced format" drives that have 4KB sectors.
So who knows, maybe it will soon be possible to have 16TB MBR drives.
Dave
twixt wroteOK, then what would you do in a situation where you did have to restore multiple partitions and place them in a certain order on the disk - as is necessary with the hidden Lenovo or Sony Repair/Reinstall Partitions even today
twixt,
I have a one setup on my test computer that has 12 partitions on HD0 and most are primary partitions containing different Operating Systems. The computer can be used for bare metal restores. I can restore the partitions manually or the lot together.
Brian_K wrote:
twixt wroteOK, then what would you do in a situation where you did have to restore multiple partitions and place them in a certain order on the disk - as is necessary with the hidden Lenovo or Sony Repair/Reinstall Partitions even today
twixt,
I have a one setup on my test computer that has 12 partitions on HD0 and most are primary partitions containing different Operating Systems. The computer can be used for bare metal restores. I can restore the partitions manually or the lot together.
Hi, Brian. Then I'm confused. MBR-style Partition Tables can have a maximum of 4 entries. GPT partition Tables can have a maximum of 128 entries in the manner that Windows7 currently understands.
So, how are you managing those 12 Partitions? And is this disk a 2TB-or-less unit, or a more-than-2TB unit?
Inquiring minds want to know.
I get the feeling we have been talking at cross-purposes. What Ghost 15 can do right now with GPT is very different from what is required for Ghost to support OS-Image Restore. That is why Ghost's documentation clearly states that Ghost is capable of working with non-boot GPT partitions on non-boot Drives. This is also why Ghost has the ability to work with that secondary 40GB drive - since it is not the Boot Disk.
The changes I have been discussing - are about what would have to change in Ghost to support OS-Image Restore of bootable OS partitions on GPT Drives. This is the item which will complete Ghost's feature-set to allow Ghost to fully support GPT without limitation.
The restore of an OS under GPT has to restore a minimum of 4 things - the EFI Partition, the OEM Partition, the Partitions in the MSR Area, and the OS Partition. Thus, an OS-Image must be a multi-Partition "assembly" of those items - and Ghost must be able to restore that assembly as-a-block and in-the-right-order when doing an OS-Image restore. As far as I am aware, that is one of the things a *.sv2i file is for.
What you can do, by restoring individual GPT Partitions - is confirm support for what Symantec already says Ghost can do. To me, this is totally irrelevant. It's not how people in the "real world" are going to restore an OS-Image under GPT. My discussions in this regard are about how Ghost will have to evolve to support the restore of an OS-Image under GPT to a GPT Boot Disk run by a UEFI BIOS. This is consistent with the obvious evolutionary pathway the industry is already moving towards.
As well as what is already stated above, my other concern is the intelligence required to be added to Ghost to support the kind of "point and shoot" Backup and Restore procedures that folks who know absolutely nothing about Partition Table management can use. Thus, the need for the kind of automation I've been discussing - and the addition of sufficient intelligence to Ghost to be able to automatically figure out how to make and manage that "assembly" of GPT Partition Images that constitute an OS-Image.
As Symantec have stated, Ghost already knows how to work with non-boot GPT Partitions on non-boot Drives. However, with a UEFI motherboard the boot disk must be GPT. And no matter the size of that Boot Physical Disk - the entire Physical Boot Disk must be Partitioned, Formatted and run in GPT mode.
Can GPT be used on disks under 2TB? Certainly. The next test in the exploration of Ghost 15's current GPT capabilities will be the attempt to use Ghost 15 to Backup one or more GPT Partitions larger than 2TB - on a Physical second-hard-disk or Array larger than 2TB - to a local (not across the network) Target GPT Partition on a drive larger-than-2TB. And vice versa, Restore of same. As far as I am aware for now, this question has not been answered.
However, it is my understanding that Ghost 15 is a 32-bit Program. If that is the case - then even though Ghost can work with GPT-style Partitions on non-boot Hard Disks - those disks must be less than 2GB in size - because 48-bit-LBA is the maximum-size addressing-scheme that Ghost 15 supports. Now, do I know that Ghost 15 has this limitation when reading/writing GPT? No, I don't. Thus the need for the experiments mentioned above.
I assume that the GPT intelligence in Ghost 15 has been "tacked on" to Ghost's previous source code. If I am right, then that implies 48-bit MFT management at best. Could I be wrong about this? Certainly. Thus the need for the required testing and experimentation to prove one way or the other.
But still - we are talking about a second Physical Disk or Array. And Symantec's position on this is clear - Ghost does support GPT on non-Boot disks. But that's not what the next version of Ghost is going to be about. Consequently, the need for all the "stuff" I have been discussing to add support for GPT Boot Disks and OS-Image-assembly-intelligence into a Version of Ghost that will support GPT Boot Disks with 64-bit-Addressing.
The above implies a need for a 64-bit Version of Ghost - to support the desired features. And because support for GPT on disks larger than 2TB requires 64-bit Sector Addressing with Disk Geometry in its current form - that mandates the use of a 64-bit OS for support of Hard Disks or Arrays larger than 2TB - whether Boot or Secondary.
Note: The above is consistent with what Microsoft have to say on the subject.
That Ghost has not been fully explored until now - for its limitations in regards to GPT support in its current form - is not particularly surprising. Until the release of W7 in 64-bit form - there was not much demand for Hard Disks larger than 2TB in the mainstream consumer environment. Because no mainstream consumer OS had a large enough userbase to warrant allocation of Development Resource Funding to address the compatibility issues between Ghost in its current form and Ghost as it is desired to be - nothing got done. The popularity of the W7 64-bit OS and the general availability of Hard Disks larger-than-2TB is changing that.
With the native ability to work with disks larger-than-2TB as a feature of W7 64-bit - this support has created a demand for a new class of large disks - larger than 2TB. And even without single physical disks larger than 2TB - the ability to create RAID Arrays larger-than-2TB with any motherboard that has BIOS support for RAID disk aggregation - means that the number of machines requiring full support for 64-bit sector addressing is growing.
And with that growth - comes the demand for feature support in software to support said 64-bit Sector Addressing. Thus the demand for Ghost to support said 64-bit Sector Addressing. Thus the need for Ghost to be recast into a 64-bit form - as the most efficient way of supporting said 64-bit Sector Addressing.
I think what can be said with confidence - is that a new version of Ghost is needed - in order to have a tool that allows as efficient and as easy and as bulletproof Backup/Restore of OS-Images to GPT Boot Drives - including GPT Boot Drives larger-than-2TB - as we have now with Ghost's support for MBR and 48-bit-LBA Partitions on MBR Drives under 2TB in size. I don't think anybody contests that argument.
So, my discussion revolves around what is needed to add the desired functionality - and the most efficient ways to add that functionality to Ghost as it is currently designed. I though that was what the conversation was about to begin with. Obviously, others thought the conversation was about what Ghost 15 can support in its current form as far as GPT is concerned. Thus the confusion.
Regardless, we will see what ensues. Reality trumps.
The .sv2i is basically an XML file that tells Ghost hoe the partitions were originally laid out on the hard drive. You can open it in Notepad and view the text if you want. Oh by the way, the Ghost 15 SRD has a nice bug that restore Windows 7 partitions in the wrong order when restoring to a blank hard drive. Look at this picture to see how Ghost was going to restore the SRP after the OS partition unless it was corrected manually...
redk9258 wrote:The .sv2i is basically an XML file that tells Ghost hoe the partitions were originally laid out on the hard drive. You can open it in Notepad and view the text if you want. Oh by the way, the Ghost 15 SRD has a nice bug that restore Windows 7 partitions in the wrong order when restoring to a blank hard drive. Look at this picture to see how Ghost was going to restore the SRP after the OS partition unless it was corrected manually...
[deleted in the interests of brevity]
Yup. Knew about that. But it's a bug. Regardless, the functionality that allows for a restore of the required partition-set, in the right order, is the desired concept.
It's just that GPT is going to make things just a tad more complex...
