pishposh

Just read this!

I'm otherwise tied up for today--but will be glad to read through your postings later--if it's not too late!

pishposh

Hmmm...the .gif format you have chosen will be very difficult to work with--hard to *quote* or *copy* text to reference in a forum posting!

Regarding your *ghost1.gif*--"Ghost's Confusing Lineage", you can find a fairly accurate outline here:  Ghost (software), "General Hardware-Oriented System Transfer".

Ghost 2001, 2002 and 2003 were retail versions of Ghost.  Ghost 6.0, 7.0 and 7.5 were the Corporate versions that most closely resembled those retail versions.

Usually the next Corporate version was already released with added functionality before those functions were incorporated in the next release of the retail version--so for instance when Ghost 2003 was released--Ghost 8.0 was already released to the Corporate folks.

Ghost 2003 was the last retail version of the Classic Ghost (DOS based) program prior to Symantec switching the new consumer (i.e. retail) version of Ghost, based on PowerQuest's Drive Image version 7.  Ghost 2003 was most like Corporate Ghost 7.5, and never had the functionality introduced in Corporate Ghost 8.0.

More comments later...

NightOwl wrote on Feb 12^th, 2010 at 10:36am:


See if the attachment (.rtf in .zip) suits you better.  (Some formatting prettyness was lost, but it's legible.)

Quote:


Yup, the Wikipedia article was part of my homework/research.  However, the way it's written, I had a hard time telling for sure whether it meant year-numbered names ("Ghost 2003") always meant consumer and version-numbered names always meant corporate.  For example, look at how "Ghost 6.0 (Ghost 2001)" and "Ghost 7.0 / Ghost 2002" are listed.  Makes each sound like a single product with two names.  The description of 7.0/2002 even makes it sound like it was ONLY a consumer version, called "2002", and only identifiable via Help > About as 7.0.

That's why, in my draft, I settled with the roundabout approach, saying "Under Symantec, consumer and corporate versions of Ghost were released using a mixture of the software’s traditional naming and year-numbered naming."  Technically by not even making an attempt to say which versions had which names, the statement otherwise remains correct. 

Quote:


Thanks. 

Quote:


Unless someone from Symantec's ghost development team shows up, I guess we're all rather uncredentialed, aren't we?    No worries.

(Hmm, according to that Wikipedia page, Ghost development moved from its ancestral home in New Zealand to India late last year.  Guess there's little chance the new maintainers will be showing up here, in that case...)

pishposh

Moving on to the next section:

Quote:


And the:

Quote:

These modes can be selected from the Ghost programs interface--on the opening page there is a menu choice called *Options*, once selected, there are a number of tabbed options available--selecting the *Image/Tape* tab brings up the selection box for these modes.

Alternatively, one can select these options from the command line that loads the Ghost program:


Default mode--no added switch is used
Image Boot--use the *-ib* switch
Image All--use the *-ia* switch
Image Disk--use the *-id* switch


I personally only use the *Default* mode and the *Image Boot* mode.    I'm not real familiar with *Image All* or *Image Disk*--I've looked at them, but their descriptions have left me wondering sometimes--see later! 

I think you may have the *Image Boot* mode incorrectly described as forcing a *sector-by-sector* direct clone or image creation.  I think only *Image All* and *Image Disk* (or the *Image Raw* switch you talk about at the end of your second *gif* file) force Ghost into the *sector-by-sector* mode.


(Note--of these modes (according to the User Guide), *Image Boot* forces one to do whole disk only tasks--no *partition-to-partition* or *partition-to-image* procedures--apparently an individual partition can not be restored from an image created with *Image Boot*.  And, one would think that *Image Disk* would also have this limitation based on its description below--but, read on--it says otherwise!!!!--so which mode is correctly described and which is incorrect--*Image Boot*--or *Image Disk*????)


So, I think this is the hierarchy of ascending data inclusion modes:



Default--intelligent imaging (or direct cloning) + absolute sector 0 only of MBR tract included

Image Boot (*-ib*)--intelligent imaging (or direct cloning) + entire MBR tract (sectors 0 thru 62) included
(Whole disk only tasks?, but see below!?)

Image All (*-ia)--sector-by-sector imaging (or direct cloning) + absolute sector 0 only of MBR tract included

Image Disk (*-id)--sector-by-sector imaging (or direct cloning) + entire MBR tract (sectors 0 thru 62) included
(Whole disk only tasks?, but see below!?)




Here's where I find the User Guide descriptions of these modes hard to follow:

For the *Image Boot* (*-ib* switch):

Quote:


But, you get down to the *Image Disk* (*-id* switch): 

Quote:


So, if the *Image Boot* functionality is included in the *Image Disk*--shouldn't it have the same limitations as the above *Image Boot*--i.e. preventing partition-to-partition or partition-to-image functions with the -ib switch?  The description of *Image Disk* seems to begin to confirm that......

Quote:


But, then goes on to say:

Quote:


By all logic--shouldn't that have been a *CAN NOT*.

That's why I sometimes say the User Guide leaves me wondering--I think I need to test the above for accuracy!!!!!

Your comments or experience????

Perhaps, the User Guide just fails to mention for *Image Boot*, that you can restore an individual partition for an image file that was created by using *Image Boot*, just as it says you can do having used *Image Disk*--again, would have to confirm which statement is correct vs which statement left out needed information!

Quote:


Yeah, I saw that mentioned in the documentation too, and have also been wondering why, exactly, Ghost wouldn't technically be able restore individual partition(s) from an -ib disk-to-image backup while being able to restore individual partition(s) from an -id disk-to-image backup.  Both modes capture sector-by-sector dumps of the 63/2048 (CHS/megabyte aligned) sector MBR track.  So -ib shouldn't produce an image any more lacking in partition info than an -id image!  Of course, -id captures the MBR track in full and any 63/2048 sector EBR track(s) in full, whereas -ib only captures the MBR track in full while only "interpreting" any EBR track(s)' partition info and saving only said interpretation(s).  But even that shoudln't be the reason.  Default mode also records mere "interpretations" of partition parameters from EBR(s), and yet default-mode disk-to-image backups can have individual partitions restored from them, yes?  So that tells me Ghost's "interpretations" are enough for restoring individual partition(s) from disk-to-image backups, -ib or otherwise.

Anyway, on top of all that, this new -ia -ib combination being possible raises the question of whether individual partition(s) can be restored from disk-to-image backups done in "-ia -ib" mode.  I.e., is that ability dictated as yes by the -ia in "-ia -ib" or as no by the -ib in "-ia -ib"?

Sigh.  Guess confirmation is needed whether individual partition(s) can be retored from an -ia -ib disk-to-image backup ... and just for the sake of verifying Ghost's cryptic documentation, whether individual partition(s) can in deed be restored from -id disk-to-image backups like the manual seems to claim.

Pfew.  Thanks for all your help so far.  If you've got any more, lay it on me.  This "homework" assignment of mine appears to be due Wednesday, according to Da Boss.

P.S. Looks like according to this, Norton Ghost 2003 is not 8.1 as said in my draft, but a consumerized version of 7.5.  So, that's another note-to-self for my final draft.

pishposh

Quote:

So, it looks like we have now passed your dead line--FWIW I didn't see any other issues in the information you posted.  But, I've spent a little more time reading (and re-reading  ) some of the information, and thought I'd make a few more comments.....

From Switches: Sector copy:

Quote:

I've seen this comment multiple times from various sources--all well and good!  But, what has always *troubled* me is this fact--if restored partitions from the image (or direct cloning from source to destination HDD) were not located on cylinder boundaries to begin with--how exactly is it that the original source HDD did not have those partitions located on cylinder boundaries?  These partition were presumable created, and were in use prior to making a Ghost image--and someone was successfully accessing the data without using a *disk editor*--why does Ghost have to adjust the restored partitions to anything other than what was used on the original source HDD from which the image was created--or used to do a direct clone to another HDD?????!

There must be some *voodoo* magic going on in the background that no one bothers to explain--source HDD can be accessed just fine (I would think this means that the partitions *are* located on the necessary cylinder boundaries), but destination HDD must have the partition aligned in some other fashion to have them start on cylinder boundaries in order to able to access data successfully--my head hurts......

*Image All* (*-ia* switch)--seems to say it *All*--but, actually this really means *sort of all*!!!!!  Well, I guess they had to name it *something*!  But, I guess it's easiest to understand what *is not* included in *Image All* vs *Image Disk*....

*Image All* does a sector-by-sector image of all partitions--but, leaves out any *unpartitioned* space--*Image Disk* would add sector-by-sector data of the unpartitioned space!  And, *Image All* includes the absolute sector 0 boot sector, but leaves out the rest of the *boot tract*.  And *Image All* leaves out any extended partition table sector-by-sector data--it just saves the needed information to *recreate* the extended partition table(s).

Quote:

So, using both *-ia* plus *-ib*, you get a sector-by-sector image of partitions (unpartitioned space is left out), and you now get the entire boot tract sector-by-sector, but all extended partition tables and tracts are left out--but the necessary information to recreate the extended partition tables is saved, or transferred if cloning directly!

*Image Disk* creates a sector-by-sector of all partitioned and unpartitioned space, the entire boot tract, and all extended partition tables and tracts.


But, what exactly is meant by *boot tract*?!

Quote:

I think the definition of *boot tract* has changed over time!  Back when Ghost 2003 was out, along with Corporate Ghost 8.x--this meant *sectors 0 thru 63!  With the advent of WinVista (and now Win7), I think *boot tract* may mean *sectors 0 thru 2048*--or *sectors 0 thru 63*--depending on the partitioning tool used initially--someone who understands this better than I would have to clarify that!!!!  But, earlier Ghost versions prior to Vista compatibility, probably are not *sectors 0 thru 2048* boot tract aware.  Here's a reference as to when Ghost was made Vista compatible--GSS v2.5:   Ghost Solution Suite Compatibility with Windows Vista SP1, Windows XP SP3, Windows Server 2008, Windows Server 2008 R2, and Windows 7.

So, you have to be very *alert* as to what version of Ghost you are using--and how it functions, what OS is being used, and what partitioning tool was used originally if you want to avoid attempting a Ghost procedure that might *mess* thing up for you!!!!

My head still hurts.....

NightOwl wrote on Feb 24^th, 2010 at 11:56am:


Go ahead.  I can always produce a revision. 

Quote:


Simple explanation.  It comes down to different HDDs having different CHS geometry despite all HDDs being equal in the LBA sector numbering domain:

Assume LBA sector number 10,000,000 on HDD X is the start of a new cylinder, and that a partition also starts there.  Now, on HDD Y, absolute LBA sector number 10,000,000 may NOT map to the start of a new cylinder given HDD Y's unique CHS geometry.  With this in mind, consider that most operating systems (until very recently*) use CHS to access disks and require partitions to begin on new cylinders, and the problem becomes obvious.

So, this issue that's wracking your brain need not wrack your brain in the first place because the issue itself has nothing to do with partitions not being aligned to cylinders on source HDDs.  It has to do with Ghost making a LBA-sector-by-LBA-sector backup, and then when restoring, needing to possibly paste those sectors onto the destination drive at a slightly different LBA sector offset -- one that is the start of what is a new cylinder on the destination HDD.

(*) = Vista is the first Windows operation system to abandon internal CHS addressing of disks.  It uses LBA sector addressing internally instead.  When Microsoft made this change, abandoning CHS, it was forced to decide (arbitrarily) on a new number for how many sectors would represent "boundaries" for partitions.  As it turns out, they settled on 2048.  2048 because at 512 bytes per sector, 512 bytes * 2048 sectors = 1,048,576 bytes, or exactly 1 megabyte.  Thus with 2048 as the partitioning boundary block size, partitioning becomes very simple: you can now specify partition sizes in increments of exactly 1 MB!  (This is also, incidentally, why the MBR boot track -- and EBR boot tracks -- inflated from 63 sectors under CHS operating systems to 2048 sectors under the new LBA Vista/7 operating systems.  Since partitions should now start on 2048 sector boundaries under them, and since *some* amount of the first 2048 sector block (LBA sectors 0-2048) is used for the MBR, the NEXT/FIRST available sector to start a partition at the very beginning of becomes sector absolute LBA sector 2048.  Thus the MBR boot track expands as a mere coincidence of that.  (And of course, same with EBR boot tracks.)  If you want more info on this subject: http://www.mytechsupport.ca/forums/index.php?topic=12612.0

Anyway, continuing to the next items...

Quote:


Well, when thinking exclusively of the bytes on a HDD that lie *within* partitions, "Image All" does in deed image "all"...