To all

I was responding to another thread, and realized that I wasn't sure what happens in the following scenario:

Many Ghosters here say they use Ghost to create an image of their OS partition only, and use other backup solutions to backup their other data on additional partitions.  

All well and good--but what happens if your HDD dies.  If you're using Ghost 2003 and you have made a backup of just the OS partition, *Local > Partition > To Image*--if you restore that to a new, replacement HDD, will it boot okay--i.e. will the necessary Master Boot Record (MBR), etc. be restored.

I know that the MBR is restored if a *whole* disk is imaged and then restored--but what about when backing up single OS partitions.

I know Ghost 9 and 10 are different--but same question?

I presume, after restoring the OS partition (telling Ghost not to re-size the restored image to *fill* the new HDD space) one would then create the additional partitions, and restore the data back to them from the data backups--correct?

I have always used *whole disk* images--so, I have never had to deal with this issue.

Thanks for the feedback.

NightOwl, you ask a very good question.

I exchanged emails with Symantec many months ago about the MBR and Ghost 9.  Symantec explicitly assured me that the MBR is automatically included in the image – although a statement of this fact does not actually appear in the Ghost 9/Ghost 10 User’s Guide, as far as I can tell.  The fact is implied by the existence of the option to restore the MBR, however, as described on page 103 in the Ghost 10 User’s Guide.

well, i can only speak regarding ghost 2003, but if you restore *only* the boot/system partition, that will work. if you didn't back up the rest of the drive, yer screwed there.

i have done the replace-drive thing a few times now, with several different version of ghost, such as 2001, 2002 & 2003.

i first partition the new drive to resemble the old drive (usually, the new drive is bigger) .. usually with 1 primary & 2 logical drives, .. i even format it first, even tho i know you don't have to. (superstitious)

works every time.

Rad


Quote:

i first partition the new drive to resemble the old drive (usually, the new drive is bigger) .. usually with 1 primary & 2 logical drives, .. works every time.

Just to clarify--you have created a *Local > Partition > to Image* of the OS only partition of a 3 partition HDD--and restoring that single partition only image to your new HDD--no problem with booting and everything is as it should be--correct?!

If you do not pre-partition--I'm betting it will not fly!

yeah, that's what i do.

most of the time, windows is *not* located on the c drive. then it's easy. (long as the drive containing the c drive doesn't need to be replaced)

when windows *is* located on the c drive (i normally don't like windows on my c drive), that's more tricky, or when i need to replace the c drive.

forget exactly what i had to do there, but it was trickier than replacing a drive containing windows which did *not* include the c drive.

why do you think it wouldn't have worked without first partitioning?

Rad


Quote:

most of the time, windows is *not* located on the c drive. then it's easy. (long as the drive containing the c drive doesn't need to be replaced)

Ah, okay--I see what you're doing--you have windows on a different HDD from the boot HDD.  On *Disk 0*, you have the Master Boot Record that points to the boot files that are on the C:\ partition--those boot files point to the *Disk 1* and the partition that Windows is installed on.

So, your image of the OS is not dependent on having boot ability--but if your *Disk 0* goes down--you're in trouble--unless you keep an image backup of that around to restore in the case it goes down!  (Isn't this like the argument against using RAID 0-stripping--where you have just doubled the probability of a HDD dieing--both of which your system depends on to successfully boot?!)


Quote:

when windows *is* located on the c drive (i normally don't like windows on my c drive), that's more tricky, or when i need to replace the c drive.   forget exactly what i had to do there, but it was trickier than replacing a drive containing windows which did *not* include the c drive.

That's the scenario I'm asking about--argghhh--you don't remember what you had to do!!!!!

Rad wrote on Aug 17^th, 2006 at 1:58pm:

i first partition the new drive to resemble the old drive (usually, the new drive is bigger) ..  .. i even format it first, even tho i know you don't have to. (superstitious) works every time.

That's how I do it. I create all partitions using a PM boot CD, then restore my OS partition. I then restore my data partitions using Windows Explorer.

I haven't tried this with Ghost 2003. I used Ghost 9 for the three HDs I've replaced in my main computer over the last 18 months. In tests this method works with Acronis True Image even though their forum members say you must use a full disk image. Drive SnapShot works too.

I actually encountered this recently. I use Ghost 2003. I image only my OS partition, not the entire drive. I started having trouble with  one system's primary drive so I Replaced it with a new one.
  Used fdisk to create primary partition then restored partition image to that. Would not boot. after some investigating I tried fdisk/ mbr and then it booted just fine. So I assume that 2003 does not save the MBR when doing partition to image.
   I have been wondering how to include it with the image though without having to image the entire drive since my data partition is huge and already backed up elsewhere.
  fdisk/ mbr  should work for me since I only have a plain ole single OS to boot, but what about systems with specialized MBR's for multibooting and such.

ckcc,

I'm pleased you responded as I'm interested to hear if Ghost 2003 could work the same as Ghost 9 if you partition the new drive to resemble the old drive before you restore the image. Is that what you did or did you just create the OS partition and create the data partition after you got the OS working?

Brian,
I I created the data partition from disk management after I got XP booted.
Also I did not format the OS partition before restoring the image. Could that affect anything? Hmmm I've got a few extra drives sitting around now. Maybe I'll do some experimenting.

ckcc wrote on Aug 17^th, 2006 at 6:23pm:

Hmmm I've got a few extra drives sitting around now. Maybe I'll do some experimenting.

That would be great. I suspect partitioning and formatting the whole drive before restoring the image is the key but let's hear what you discover with Ghost 2003.

OK Rad,
I see that you formatted first then restored the image. And you say that it booted fine? Maybe thats where I went wrong. So does formatting the partition also create a MBR that allowed your image to boot or did it just allow your MBR to be restored with the image?

Brian,
 I'm very curious now... so I'm sure gonna try a few things but not sure when I'll get it done. I will post my findings ASAP

I think that partitioning and formatting does create a MBR that allows success.

OK, so does parttioning and formating create a generic MBR that allows booting (like fdisk/ mbr did for me) or does the original MBR get restored?

ckcc wrote on Aug 17^th, 2006 at 6:43pm:

OK, so does parttioning and formating create a generic MBR that allows booting (like fdisk/ mbr did for me) or does the original MBR get restored?

ckcc,

I'm guessing. I think it creates a MBR similar to the original.

ckcc,

Where in the boot process did your computer stall? (Prior to using fdisk /mbr) Any error messages?

Where in the boot process did your computer stall? (Prior to using fdisk /mbr) Any error messages?

I really don't remember for sure... but I think it came up "operating system not found"

Update: test 1

*Installed new drive in system
*Booted win 98 startup disc
*Ran fdisk
*Created primary partition (using half of disk), did not format
*Made partition active (I may not have done this step before. fdisk warns that the partition cannot be started if not set as active)
*Restored Image created as  local / partition / to image in 2003
*Reboot
*XP starts without a hitch!!!
  So now I'm not sure what went wrong before... but I do know now My images will boot when restored to a new HD.
  Guess I'll have to try again with out setting active and see what happens... but not tonight ;)

ckcc wrote on Aug 17^th, 2006 at 8:13pm:

*XP starts without a hitch!!!

I couldn't resist either. Using an old computer, the first HD contained Win XP (5005 MB), a hidden Win XP (1051 MB) and a Logical drive (3475 MB). I made a Ghost 2003 image of the Win XP partition, writing the image to the second HD.

I replaced the first HD with a 20 GB HD and deleted the partitions on the new HD. It was then 20 GB of Unallocated Space. I restored the image to the Unallocated Space and chose 5020 MB for the partition size. To my surprise the OS booted normally.

I'll do a few more tests.

It's getting interesting.

I deleted the partition from the new HD, rebooted and created a 5020 MB Primary partition and didn't set it active. The remainder of the HD was Unallocated Space. I restored the Ghost 2003 image to this partition and when the computer restarted I received, "Operating System not found".

I used the PM disc and sure enough, the Primary Partition had a Status of None. I set the partition Active and Win XP booted normally.

I was surprised that my first test worked. Restoring to Unallocated Space. The message from ckcc and my subsequent tests is that if you restore to a partition then it must be set active. Either before you restore or with PM after the Restore.

Where does the MBR problem fit in?

Just to finish off, I deleted the OS partition and restored the image to Unallocated Space again. This time I used all of the Unallocated Space. No problems.

well, first, lemme say that i *do* keep an image of my c drive, even when no o/s resides there, cuz you need that if you lose your c, altho i guess you could simply copy* files elsewhere, and no actual image is necessary. but my c drive is small .. primarily for this reason.

next, the drive that contains the o/s & prgms is going to be doing most of the work, so it is more likewly to die, than say, a storage-only drive .. if that;'s what you use your pri-master for (c drive)

Brian, nice work

I'm getting the same results as you. My second test I didn't set partition active before the restore and it failed to boot. "operating system not found on any devices".

First I tried fdisk/mbr... still no boot
So then I used fdisk to set partition active and... booted right up!

So that must be where I screwed up last time. Just didn't remember having to set partition active.... was thinking fdisk/mbr fixed the problem....I wasn't sure about anything I was doing at the time anyway... I'm glad this came up so now I know for sure.

I'm glad to see that restoring to unallocated space works fine also. Could save the extra steps.

May have to dig deeper to see why it works one way and not the other.... still leaves me wondering if the original MBR is getting restored or a new one is being created.... and can that affect anything in a bad way?

I couldn't resist either. Using an old computer, the first HD contained Win XP (5005 MB), a hidden Win XP (1051 MB) and a Logical drive (3475 MB). I made a Ghost 2003 image of the Win XP partition, writing the image to the second HD.

I replaced the first HD with a 20 GB HD and deleted the partitions on the new HD. It was then 20 GB of Unallocated Space. I restored the image to the Unallocated Space and chose 5020 MB for the partition size. To my surprise the OS booted normally.

So Brian,
Did you still have the option to boot the second install of XP... if it were added back to the disk? Is it referenced in the MBR? I assume that is what NightOwl is really trying to find out...
If you restore the OS's from partition only images  then recreate the data partitions on a multi-boot system to a new HD will everything work as it should? Without having to do a whole disk image.

I have no experience with multi-boot except for the time I accidetally installed XP twice.

It looks to me like you guys haven't been controlling all variables in your tests.  Simply removing all partitions from a disk does not remove the 400-odd bytes of boot code from the MBR.  That means that when you restore a partition from a test image and it boots, it does not prove whether the MBR boot code was restored from the image or whether it's still the same old pre-existing MBR.

IME, a Ghost 2003 partition-from-image restore does not restore the MBR boot code.  However, note I almost never use any command-line switches when creating or restoring, so that could make a difference.  There might be a Ghost command-line switch to save/restore the MBR (NightOwl should know), but frankly, I wouldn't care to have the MBR in my partition images.  If I want to save the MBR, I do it separately with my mbrsaver.com utility or TeraByte's mbrwork.exe utility.  Mbrwork can save a backup of the entire first track (LBA 0-62).  Mbrsaver only saves LBA 0 (the MBR sector), but has the unique advantage of being able to restore the boot code from the backup without destroying the partition table--very handy if your restored partitions are different sizes from the originals.

The MBR is nothing more than a dumb launcher.  You need a launcher to direct the boot process to a partition, but usually there's nothing special about it.  It is not part of a partition, so strictly speaking, it does not belong in a partition image.

I suggest thinking of a partition's contents like eggs in an egg carton.  If we're talking about the egg, you don't need to know anything about the carton.  You can move the egg to any old egg carton, whether it's a 12-item carton, a 18-item carton, styrofoam, cardboard, or even the egg rack in your refrigerator.  It's still the same egg, and the carton it's in makes no difference.

Your partition, whether it's original or restored from an image, is the egg.  The disk is the carton.  You can move the partition around to a different spot on the disk or to another disk.  You do not need any information about the original disk or the MBR on that disk.

(Note that a whole-disk image is different.  There, we're talking about the whole carton, not each egg individually.  It would be appropriate for a whole-disk image to include images of each partition plus the MBR.)

Just restore your partition images, and if the disk does not already have the launcher code in the MBR, just use any of a wide variety of tools to add that.  "Fixmbr", "fdisk /mbr", and many other utilities can install generic MBR boot code.  I believe that tools like Partition Magic automatically install generic boot code when you partition a new disk.  TeraByte's mbrwork can either install generic boot code, or restore from a backup if you saved one beforehand.

If your boot code really is special or you are multibooting, you can back it up.  But boot managers are so easy to reinstall that I rarely bother to backup my MBR.  All my own computers multiboot, but when I upgrade a hard disk I often move/resize partitions, add some OS's, and remove others.  So, a backup of my previous boot manager configuration is seldom reusable anyway.

So, for users of Ghost 9/Ghost 10, is it true that the MBR information is automatically captured in the image (a.k.a. “recovery point”) and may optionally be restored during the recovery process?

Dan,
The first time I used a new drive and the second time I Used MBR wizard to delete the MBR and then did a disk wipe of the entire drive hoping there would be no trace left of a MBR. So I can't really explain how it got there.

http://mirror.href.com/thestarman/asm/mbr/FDISK98.htm

http://mirror.href.com/thestarman/asm/mbr/STDMBR.htm

http://ata-atapi.com/hiwmbr.htm

http://support.microsoft.com/kb/69013/

Thanks Dan , That's a great explanation.

To answer NightOwl's original question:

It works with 2003 for a plain single OS system (Did for me) but may not for multi-boot or systems with a specialized MBR... but as Dan said... that can be easily fixed after the image is restored.

Brian,

I had never restored to unallocated space... never realized you could do that.... so I tried it as you did. But instead of just deleting partitions, I deleted the entire MBR using MBR Wizard... which then the drive showed all unallocated space. then I restored the image to unallocated space and specified the size(5 gig of 20 total).

Reset puter and would not boot!! No error message... just a blinking cursor! tried 3 times!

So I ran fdisk /mbr and reset again.... Booted right up!

ckcc & Brian,

I have a bootable CD you might find useful.  With it, you can directly examine what's in the MBR rather than trying to guess what's there based on symptoms.

Download my dsrfix98.zip file, extract the iso file, and use it to create a bootable CD.  It includes the PTS Disk Editor (de.exe, courtesy of The Starman, whose website I see you're already familiar with) which you can use to directly examine the content of the MBR sector.

After you restore your test image, boot from the dsrfix98 CD, which will leave you at the 'A:>' prompt.  Launch de.exe and look at the MBR of your hard disk.  (I have some sample screen shots here.  These examples show partition boot records, but you'll want to choose 'Physical Devices' and open the first sector of your hard disk.)

I just ran a test in which I zeroed out the MBR and then restored a Ghost 2003 partition image.  The partition table (at the bottom of LBA-0) was adjusted, but the boot code portion remained zeroes.

Thanks Dan,

I'll give that a try. I have a program that looks similar ( sector spy xp) but have never understood how to utilize it before.

I just ran a test in which I zeroed out the MBR and then restored a Ghost 2003 partition image.  The partition table (at the bottom of LBA-0) was adjusted, but the boot code portion remained zeroes.

Thats the conclusion I've reached from my tests and research... that only the Partition table entry is restored with the image and the rest of the boot code either has to already be there or supplied afterwards. Creating a partition before restoring the image creates this code in the MBR. Is that correct?

"I have a program that looks similar ( sector spy xp) ..."

If that's a XP-based utility, it won't be that easy to use when the hard disk doesn't boot.

"Creating a partition before restoring the image creates this code in the MBR. Is that correct?"

Well, it's really two separate activities, so I suppose it depends on the utility you're using to create the partition.  All the utilities I use seem to behave that way.  I guess they assume you'll always want boot code if you've got partitions.

If that's a XP-based utility, it won't be that easy to use when the hard disk doesn't boot

It's on my Bart PE / Ultimate Boot CD... looks like several of them. already downloaded yours and will try that. Thanks.

It's all starting to make a little sense now. :-/

Dan Goodell wrote on Aug 18^th, 2006 at 2:54pm:

It looks to me like you guys haven't been controlling all variables in your tests.  Simply removing all partitions from a disk does not remove the 400-odd bytes of boot code from the MBR.

That's what concerned me with my first test. I used a HD that contained a WinXP partition and a data partition. I deleted both partitions but obviously didn't remove the MBR. When I restored the Ghost 2003 image to Unallocated Space it booted but the MBR was from the original HD and not from the HD where the image was made. I feel I don't understand the MBR well enough to generalize but the adage about not being able to restore a Ghost 2003 OS partition image to a new HD seems to be a incorrect.

ckcc, you have done some interesting tests while I've been away.

ckcc wrote on Aug 18^th, 2006 at 5:28am:

Did you still have the option to boot the second install of XP...

I don't use a special boot manager as I only occasionally use that second WinXP. I just use pqboot32.exe which is situated in a common data partition visible to both OSs.

Using Ghost 9 I've restored both partitions in the past. Easy.

ckcc, Brian and Dan

Interesting posts since I started this thread--thanks for each of your contributions--and testing!  I've been tied up with a couple other projects and did not respond for the last couple days pending doing a little more research and testing myself!

I have to say that I now have a much fuller understanding of the Master Boot Record (MBR), the partition table, the *boot tract*, and booting issues surrounding these items--but, I'm also even more confused--partly because there does not appear to be an agreed upon terminology for certain aspects of this area regarding the MBR, etc.--I'll point that out later.

First off, when I Googled *Master Boot Record*, I stumbled upon Starman's series of webpages about the MBR, Fdisk, etc. that ckcc referenced in one of the earlier posts--excellent stuff--fairly technical--but enough of it can be appreciated for its general overview--and you can ignore the highly technical stuff--worth reviewing for better understanding--I made up a list of some of the more relevant pages:

(Edit by NightOwl, 8/23/06 at 10:10 pm--fixed third link so goes to the correct page.

Also--see Dan Goodell's reply # 51--it adds great clarity to my comments below!)

An Examination of the Standard MBR

An Examination of the MBR ( Master Boot Record ) for: MS-Windows 95B, 98, 98SE and ME

An Examination of the Windows 2000 ( NT5.0 ) and Windows XP ( NT5.1 ) MBR

An Examination of the MSWIN4.1 OS Boot Record

An Examination of the NTFS Boot Record Of Microsoft® Windows 2000 (NT5.0) and Windows XP (NT5.1)

Detailed Notes on Microsoft's FDISK.EXE Program

What Does Microsoft's (Win 9x/ME) FDISK.EXE Program do to a Hard Disk?

How To Permanently Erase Data from a Hard Disk

MBR, Partition Table and Boot Record Tools


To summarize some of the main points I got out of those pages:

1.  The MBR boot code and Fdisk have changed over time from DOS 3.30 through now NT.  

a.  The Std MBR code was the same from DOS 3.30 thru Win95a that Fdisk places in the MBR:


Quote:

*NOTE: Even though we're examining the code created by Microsoft's FDISK utility, this MBR is OS-independent. Its code can be used to start the bootup process for any operating system's Boot Record on an x86-CPU based (PC) computer as long as that OS is: 1) on the Primary Master hard drive, 2) set to be the only Active partition, 3) it's Boot Sector is located at or under cylinder 1024 of the hard drive (since this MBR uses the standard INT 13 Read Function which is limited to that value) and 4) it has a boot loader in the first sector of that partition.

The above means you can boot WinXP using this Std MBR code as long as the *Boot Sector is located at or under cylinder 1024*!

b.  The MBR used in Win95b through WinME by Fdisk was changed to function under the FAT32 file system:


Quote:

Basically, this MBR was created so that Microsoft's FAT32 Boot Sectors could be located in a partition that's beyond the reach of the Standard MBR (which is limited to cylinder 1024 or less, since it does not use the Extended INT 13 Function 42h which is found in this MBR).

c.  Starting with Win2000, a new MBR code was introduced with the advent of the NTFS file system.  But, see the quote below--apparently one does not have to have this MBR code if you are installing an NT based Windows to an existing HDD that already has, say for instance, the Win98se MBR code already on that HDD from a prior Win98se install!:


Quote:

This MBR code is installed on blank hard drives when Disk Management is used by a Windows 2000, XP or 2003 OS. This code will be written to Cylinder 0, Head 0, Sector 1 of a Hard Drive by various OS routines, such as the Disk Management Console,  if  the drive does not already have an existing MBR sector (recognized by Windows) when it is installed.

And, note:


Quote:

Note: Like all other code presented in this series, this MBR code could still be used to boot any OS on an x86 PC if it meets the conditions listed here*(added by Nightowl--"here*" references essentially the same quote as above for the Std MBR code, except there is this added requirement: the CPU itself must be an 80286 or later, since some of the opcodes (see Code below) require that.

2.  Apparently, it's not the MBR code that is a critical factor in booting--it can be replaced easily with *fdisk /mbr*--and the actual code will be based on the version of *fdisk* that you are using!

If using the *Recovery Console*, the *fixmbr* command will presumably write the NT version of the MBR code to the first part of Absolute Sector 0!

I now know that *the MBR code is not critical* is a good thing, being as we have recommended using Dan Goodell's Kawecki's Trick on a WinXP system to make it forget its HDD letter assignments using a Win98se version of fdisk!

Have to wonder, though, what, if any functionality is missing when using an NT system with a Win98 MBR code loader--must not be any--being as WinXP will not replace an existing MBR code if other code is already there!

3.  But, what is probably more critical is the *Partition Table* that is the last portion of Absolute Sector 0:


Quote:

IMPORTANT: One of the first things that any PC user should do after setting up a new hard disk (or creating a new partition with a utility such as Partition Magic) is to make a copy of its MBR; especially if you have more than one partition on the disk! Why? If you accidentally overwrite this sector, or are infected by a Boot sector virus, you may never be able to access some or even all of your disk again!   Even the most expensive HD utility might not correctly restore the Partition Table of a multi-partitioned hard disk! Some advice: Save the Partition Table data on floppy disks or even on paper(!); it does no good to have the data you need to access your HD on the un-accessible HD itself! There are many ways you can do this... See the MBR Tools Page. Any good Disk Editor will allow you to manually enter data you've written down under an easy to use Partition Table View, or you can use Power Quest's excellent little utility program "MBRutil" (under any version of Windows!) and "MBRUTILD" (under DOS) to save the binary data to a file on a floppy diskette and later restore the MBR from the saved file.

For regular Ghost users, you may want to take the above advice under *advisement*--you don't want to go restoring the *partition table* to a HDD that you have made any adjustments to the partition layout.  And when you restored an image to a HDD--Ghost may do some adjustments to the partition layout using *built-in behind the scenes* partition *adjustments*--even if it's to the same HDD as the original source HDD for the image!

So, it's not a bad idea to have a back up of the MBR sector with the *partition table*, but caution in using the restore function of the MBR sector--it has to be for that exact partition layout without any changes having been made since the last MBR sector backup!

I have more--I will respond with separate posts to address individual questions and issues.

Pleonasm


Quote:

Symantec explicitly assured me that the MBR is automatically included in the image

Knowing what I've been reading so far, I would strongly doubt this applies to backing up and restoring just the OS partition of a multi-partitioned HDD!

My reasons:

1.  From the Ghost 10 User Guide you mentioned:


Quote:

Restores the master boot record. The master boot record is contained in the first sector of the first physical hard drive. The MBR consists of a master boot program and a partition table that describes the disk partitions. The master boot program looks at the partition table to see which primary partition is active. It then starts the boot program from the boot sector of the active partition. This option is recommended for advanced users and is available only when restoring a whole drive under the recovery environment.

Someone using Ghost 9 and/or 10 would have to report back if this item is selectable if you define just a single OS partition backup of a multi-partition HDD--I'm guessing not.

It's interesting--Ghost 9/10 do not have an option of imaging a *whole drive* nor restoring a *whole drive*, if I understand how they work--you have to select each partition separately until you have selected all of them in order to do a *whole drive* image and/or a restore.  Ghost must have to keep track of what you have elected to do to decide if the MBR can/will be *stored* with the image, and can/will get *restored*!

(Brian--you have mentioned deleting a *non-essential* file that allows one to restore *all the partitions* at once (?)--do I have that correct?--I wonder if that file is holding the MBR if you have selected that option?)


Quote:

So, for users of Ghost 9/Ghost 10, is it true that the MBR information is automatically captured in the image (a.k.a. “recovery point”) and may optionally be restored during the recovery process?

I'm betting not, unless it's a *whole drive* backup--whatever that means in Ghost 9/10!

Does one have to *check* a box if restoring a *whole HDD* using Ghost 9/10 to restore the MBR as well?  (Someone could set up a *pretend* whole HDD restore up to the point where you would have the option of selecting the *Restore MBR* to see if that options appears and is selectable--without having to actually carry out the deed--would have to be in the Recovery Environment if it's for the OS HDD.)

2.  Ghost (all flavors) has built-in ability to both *partition* and *format* HDD's--so it must also have built-in ability to create the MBR boot code and the partition table when you perform a restore to a new HDD that's fresh out of the box--you would not want Ghost placing that partition table (of the old HDD) on that new HDD--and Ghost usually does not--it offers to make changes in the partition sizes to *fill* the whole disk, or lets you resize partitions to your liking--so can't be restoring the *original* MBR boot sector with that *original partition table*--at least not *unmodified*!

(Having said that last statement--I wonder what version of the MBR code Ghost places on a HDD that it partitions--and for that matter--what version of the MBR code does PartitionMagic place on a HDD when you use it?)

Quote:

Knowing what I've been reading so far, I would strongly doubt this applies to backing up and restoring just the OS partition of a multi-partitioned HDD!

NightOwl,

I think the userguide is badly worded. I think "whole drive" means "partition" and they are trying to say the MBR can't be restored from a "files and folder backup". You are correct in that a "whole drive" can't be restored in the Ghost 2003 sense.

For Copy Drive the userguide actually says,


Quote:

Copy the master boot record from the source drive to the destination drive. Select this option if you are copying the C:\ drive to a new, empty hard drive. You should not select this option if you are copying a drive to another space on the same hard drive as a backup or if you are copying the drive to a hard drive with existing partitions that you will not be replacing. Additionally, if you are copying multiple drives to a new, empty hard drive, you only need to select this option once.

So the userguide is quite specific regarding copying the MBR with Copy Drive but not specific at all with restoring an image. I wonder whether the above implies that you shouldn't restore the MBR to a new HD that you have already partitioned and then intend to restore images from your old HD.



Quote:

you have mentioned deleting a *non-essential* file that allows one to restore *all the partitions* at once (?)--do I have that correct?--I wonder if that file is holding the MBR if you have selected that option?)

I think that is the .sv2i file. An index file that may save a few seconds in selecting which images to restore. It has nothing to do with the MBR. I gather it's useful with VMware as the file can be imported to create a virtual machine.


Quote:

Someone using Ghost 9 and/or 10 would have to report back if this item is selectable if you define just a single OS partition backup of a multi-partition HDD--I'm guessing not.

Yes, it is present for a single image restore although it should not be ticked when restoring an image to the same HD.

NightOwl wrote on Aug 20^th, 2006 at 3:45pm:

ckcc, Brian and Dan I have to say that I now have a much fuller understanding of the Master Boot Record (MBR), the partition table, the *boot tract*, and booting issues surrounding these items--but, I'm also even more confuseds

My thoughts exactly!

Have missed your input NightOwl, welcome back.

You have raised a few more interesting questions... which are beyond me answering. I'm gonna sit back and listen and learn.

I have Ghost 9 but have never used it.... have booted to the recovery environment just to look aroud though.

NightOwl, the phrase "whole drive" does not appear in Ghost 10 User's Guide, other than in the section describing the MBR restore option.  Therefore, I strongly suspect that the phrase is (as Brian suggests) Symantec's attempt to state that the option applies when restoring a partition as opposed to files/folders.

Remember, in the parlance of Ghost 10, the word "drive" = "partition"; therefore, the comment "whole drive" really means "whole partition".

By the way, I have looked at the XML code within the .SV2I file, and see no obvious indication that it contains anything related to the MBR.

ckcc and Brian

Thanks for your reports on using Ghost 2003 to restore a single OS partition--I have done some testing too (I wish I had read ckcc's question and Dan's statement about whether the *MBR boot code* is the same as from the original source HDD--I didn't think to look and compare that--so unfortunately that testing will have to wait for another day  ;) ).

But here's what I did, and then I have a question as to what you did:

I have a system that I wanted to add a second HDD to--so I was going to be opening it up and switching cables around--so why not do some testing  :D !?--the original HDD had two primaries, one of which had the status of *none*, the other was the *active*, and there was an extended partition with a single logical partition filling it--so three partitions.  Added the second HDD and partitioned it with an extended partition only with 3 logical partitions within it.

Then, using another HDD for testing--used Gdisk, Ghost 2003's DOS partitioning tool, I ran *gdisk 3 /diskwipe* (being very careful to get the right disk # to wipe!) which *zero'ed* out the whole drive, including the MBR Absolute Sector 0, and everything else in the boot track, and whole HDD.

Using DOS Ghost 2003, created an image of the OS partition only from Disk 0 (the primary, Master HDD that's booted from), to one of the partitions on Disk 1 (primary, Slave HDD).  (Note--disks start their numbering at 0.)

Test #1:

Then, with the 3rd HDD hooked up (Disk 2), I then tried to use:

Local > Partition > From Image.

I was able to select the image file on the second HDD as the source, and I had to select the single partition from within that image file (even though there was only 1 partition there!).  I could see the 3rd HDD listed in Ghost under the *Destination* menu, but it was *greyed out* as an option and could not be selected.  So an image of a Partition could not be sent to a HDD that did not already have a partition defined!

Test #2:

So, next tried:

Local > Disk > From Image

I was able again to select that image file on the 2nd HDD as source, but this time there was no option to select the individual partition within that image file.  Now, the unpartitioned 3rd HDD was shown as *available* to use as a destination!  Once selected, I was shown a screen that indicated that the whole HDD (60 GB), by default, would be used for the image that originally came from a 10 GB partition, but I was given the option of changing the final size.  I elected to resize to the original 10 GB.  Ghost did its thing.  Pulled the original primary, master HDD out,  and replaced it with the newly restored HDD set as master.  Booted fine!  Ghost had partitioned, formatted, and set active that restored partition image!  Ghost must have *known* it had a bootable OS on it?--or does Ghost always set the first partition on a new, unpartitioned HDD as a primary, active partition?

Test #3:  

Being as test #1 failed--I thought I'd try creating a partition first and then restoring to it to see what happens.  So, I *gdisk 1 /diskwipe* to once again zero out the whole HDD, and then using PartitionMagic (PM) created a 20 GB, unformatted primary partition--note--PM did not *automatically* make this *active*!  That requires a separate step!  So, I left its status as *None*.

I then fired up Ghost 2003 and again selected the source image file on the 2nd disk with the single OS partition and tried this procedure:

Local > Partition > From Image

This brought up the *choose the source* dialog box--selected the image on the second HDD, and was required to select that only partition from within that image again.  Now the default destination screen showed Ghost wanting to place that partition on the HDD in the *unallocated* space beginning just after the partition I had just created using PM.  It wanted to fill the remaining unallocated space and I elected to proceed.  Once done, I re-booted fully expecting a boot failure because I now had my OS partition in the second position of the Partition Table, and not on the first as the original--so I expected *boot.ini* to not find the OS correctly--and that's what happened.  But, that new partition was set as *active* by Ghost--I verified that with PM after the restore and the boot failure.  (Unfortunately, I was in a hurry and I did not attempt to alter *boot.ini* to see if that solved the problem--so I can not confirm if that would have solved the boot failure for sure--but I do this on another system where the Partition Table is *non-sequential* and I have to fix boot.ini whenever I restore to the non-sequential partition, and it works every time.)

Test #4:

So, I reset everything back to the setup in Test #3--but this time I selected the 20 GB unformatted, primary partition (status--none) that was created by PM as the destination.  This time, there was no offer by Ghost to allow for adjusting the partition size!  I then proceeded with the restore.  Rebooted and got a boot failure.  When back to PM, and now set that partition as *active* (which Ghost did not do!), and also noted that the partition image of the 10 GB original source partition was now the 20 GB partition that I had predefined--so Ghost did not re-size that restored image to match the original partition size, but left the size as indicated in the current Partition Table of the new HDD.  Re-booted and the OS came up just fine!  So, Ghost will not alter an existing partition (Partition Table) either in size or status (active) when doing a *Local > Partition > From Image* procedure!

ckcc--here's my question:

Your reply #29 test setup appears to mirror my Test #2 above--but you had a boot failure--and I booted fine--can you check over my steps and determine where we may have differed?

Brian and Pleonasm


Quote:

I think the userguide is badly worded. I think "whole drive" means "partition" and they are trying to say the MBR can't be restored from a "files and folder backup".

Quote:

Remember, in the parlance of Ghost 10, the word "drive" = "partition"; therefore, the comment "whole drive" really means "whole partition".

I have no problem with accepting that a Symantec User Guide is possibly *badly worded*  ;D !

But this should be easily tested if you have a spare HDD:

Create a single partition image of the OS that's on your boot HDD that has more than one partition, and *tick* off the backup MBR.

Put in that spare HDD and using the Recovery Environment--restore that image file and *tick* off restore the MBR (remember the User Manual say you have backed up the MBR boot code AND the Partition Table!!)--you should get a HDD with that OS partition from the image restored, but a HDD that has multiple partitions to match the original Partition Table--Yes?--is that what happens?  Presumably those other partitions would be empty until you put something in them.

ckcc--here's my question:

Your reply #29 test setup appears to mirror my Test #2 above--but you had a boot failure--and I booted fine--can you check over my steps and determine where we may have differed?

Actually your test #1 is what I did... and It allowed me to restore to unallocated space. I did not try Local > Disk > From Image. Guess I'll have to redo and try both and see what I get.

Gotta go to work tonight... so may be awhile before I get to it.

Quote:

Create a single partition image of the OS that's on your boot HDD that has more than one partition, and *tick* off the backup MBR. Put in that spare HDD and using the Recovery Environment--restore that image file and *tick* off restore the MBR

NightOwl,

Can't be done I'm afraid. There is no option to not backup the MBR. You only have an option at the restore stage of restoring the MBR or not.


Quote:

Test #1: Then, with the 3rd HDD hooked up (Disk 2), I then tried to use: Local > Partition > From Image.

I'm pretty raw with Ghost 2003 as you are aware. I may have chosen  Local > Disk > From Image, but I doubt it. I restored to the Unallocated Space.

ckcc and Brian

Based on your responses--my Ghost 2003 is not acting like your Ghost 2003--been daydreaming of what could be the difference, and suddenly Dan's comment about not knowing for sure what variables are being controlled popped into my head.

Did either of you start a disk editor in DOS and look at the MBR Sector--i.e. Absolute Sector Zero?  After using GDisk to zero out the whole HDD, I did, and sector 0 was definitely all zero's--if your HDD's had the former copy of the Partition Table--or at least some remnants of it, perhaps that explains it.  

Maybe if Ghost detects any evidence of a previous Partition Table, it will allow for using *Local > Partition > From Image* even if the Table now says all space is *unallocated*.  

Maybe an existing Partition Table that *states* that all space is unallocated is different than an all zeroed out Partition Table in the MBR!

I will have to check that option--may be a few days before I get to it however.

Brian


Quote:

Can't be done I'm afraid. There is no option to not backup the MBR. You only have an option at the restore stage of restoring the MBR or not.

Okay, I see where I didn't understand--you never have to ask Ghost to make a backup of the MBR which includes the Partition Table--but you do have to (well, actually *can*) make the choice when restoring an image.

So, don't have to do that first step in testing the results of attempting to restore a single partition along with a MBR of a multi-partitioned HDD!

NightOwl,

I think we have a cultural clash. Aussies usually regard “tick off” as “untick”. Not all of us, but I didn’t click with your intention. It reminds me of John Cleese’s, “The three differences between American and British people”

http://en.wikiquote.org/wiki/John_Cleese



Also http://www.weblink.com.au/login/login_problems.asp?GroupID=902  for Tick off.

Enough semantics. I’ll try your test.

NightOwl wrote on Aug 21^st, 2006 at 2:02am:

Did either of you start a disk editor in DOS and look at the MBR Sector--i.e. Absolute Sector Zero?  After using GDisk to zero out the whole HDD, I did,

No, I didn't zero the MBR.

NightOwl,

I used the same HDs as in Reply #19.

Using Ghost 10, I imaged the OS partition (5005 MB partition) writing the image to the second HD. I removed the HD and replaced it with the 20 GB HD. Using MBRWork I "Reset MBR to zero". I checked with Dan's de.exe and the MBR was all zeros. From the RE the image was restored using the usual settings including Restore MBR. The OS booted normally but there were no other partitions on the first HD.  Using a PM CD, on the first HD there was only a primary partition and the remainder was unallocated space.

I took the opportunity of again zeroing the MBR (and checking for all zeros). I tried to restore the Ghost 2003 image to Unallocated Space and as you found, it was greyed out. Clever.

Hi guys!

Very interesting topic which took me half an hour to read (trying to understand some of it) but I may have missed out on some details.

I use Ghost 2003 from DOS, never from the Windows GUI.

When doing a fresh installation of a system, I always create images along the way. They are created at certain stages to have an "escape route" if something should go wrong. Then I can restore the most recent image rather than starting over from square one.

In my own system, there are two hard disks:

Disk0 with C: - D: - E:
Disk1 with F: - G:

C: = boot and system partition (including program files)
D: = data partition
E: = backups of vital Ghost Images on G:
F: = backups of the data partition
G: = Ghost Images of C: ("partition to image")

If Disk0 dies, it can be restored from the contents on disk1. If Disk1 dies, it can be restored from the contents of Disk0 (except a few non-vital Ghost Images). The beauty of my "strategy" is smudged by the MBR issue but I have thought about it and came up with this simple solution:

During the installation, I only have Disk0 connected. I only create and full format C:. When the installation is finished, I shut down and connect Disk1. Next, from WinXP Disk Management, I create and full fomat the remaining partitions on both hard disks.

Now, it's time to create the first image and if that one is "disk to image", all subsequent images can be "partition to image". (The difference in size between a "partition to image" and a "disk to image" at this stage is negligible.)

With this initial image, if Disk0 should die, I would have to restore the initial "disk from image" and I have the option to adjust partition sizes (if the new hard disk is bigger or smaller or for whichever reason). Next, I would have to restore the most recent "partition from image".

I would also have to "restore" D: from the backups on F: and backup the vital Images on G: to E:.

The next time I do a fresh installation on new hardware, this small change to my strategy will be implemented and ... :-X ... I am confident that it will work.

Christer

Couple comments on NightOwl's reply #36:

(BTW, the third link in NightOwl's index erroneously links to a description of an NTFS partition boot record instead of an MBR description.)

"The MBR used in Win95b through WinME by Fdisk was changed to function under the FAT32 file system"

I think that's technically misleading.  The MBR boot code was changed to support Int13 Extensions.  Win95b did coincidentally introduce the FAT32 file system, but the thing that makes a Win95b MBR different from earlier MBRs is its Int13 Ext support.

Int13 Extensions is a patch that manufacturers began incorporating into the bios, and which supplemented the standard Int13 functions--the set of bios routines responsible for disk drive operations.  Standard routines only addressed disk sectors in CHS (cylinder-head-sector) terms.  Int13 Ext added LBA, in which sectors are addressed by absolute sector number.  Since cylinder values can only be in the range of 0-1023, CHS terms would not allow a MBR to hand the boot process off to a partition boot record if the partition began beyond the 1024th cylinder.  In contrast, a Win95b MBR could check if the bios supported Int13 Ext, and if so, it could switch from CHS to LBA in order to load the partition boot record.  This enabled the booting of partitions beyond the 8GB barrier (1024 cylinders corresponds to about 8GB).  Note the OS and particular file system on the partition being booted is not the factor here.

Aside: whatever operating system is on the partition being booted could be designed to use LBA if the bios supported Int13 Ext, but you can't even get the OS started if the MBR can't reach it.  Read between the lines here, and you'll notice this means the pre-Win95b MBR did not limit disk sizes to 8GB, it only limited the starting point of the partition being booted to the first 8GB.  IOW, if a pre-95b MBR could use CHS to pass the boot process off to the first sector of the partition, then as the OS loads it could switch to LBA to be able to access disk space beyond 8GB.  (Incidentally, this is the source of the Partition Magic warning that a partition beginning beyond Cyl 1023 might not be bootable.)  Since the Win95b MBR could itself switch to LBA, it eliminated the requirement that a boot partition had to begin below the 8GB boundary.

"Starting with Win2000, a new MBR code was introduced with the advent of the NTFS file system."

The NTFS file system was introduced with NT.

Although this statement doesn't assert there's a cause/effect relationship here, as worded I'm afraid readers might infer there is.  The new MBR wasn't due to NTFS.  Microsoft was just streamlining and compacting the code a bit, and introducing the DiskID area.  (I've seen early references to the DiskID as the "NT Serial Number".)  The DiskID is necessitated by the NT/2000/XP operating system, not by the NTFS file system.

"Have to wonder, though, what, if any functionality is missing when using an NT system with a Win98 MBR code loader"

None.

NightOwl quoted: "One of the first things that any PC user should do ... is to make a copy of its MBR; especially if you have more than one partition on the disk! Why? If you accidentally overwrite this sector, or are infected by a Boot sector virus, you may never be able to access some or even all of your disk again! Even the most expensive HD utility might not correctly restore the Partition Table of a multi-partitioned hard disk!"

FTR, any partition table can always be recontructed manually, as long as the partitions themselves are still intact.  And if the partitions are not intact, a backup of the partition table won't fix that.

Backing up the partition table is a good idea nonetheless, but it wouldn't be right to think you'd be left dead without it.

Brian wrote on Aug 21^st, 2006 at 3:23am:

using the usual settings including Restore MBR.

NightOwl,

I repeated the Ghost 10 test after zeroing the MBR with MBRWork and confirming with de.exe. But this time I didn't tick Restore MBR. The OS booted normally.

Ticked or unticked, you still get a MBR.

Brian, based upon Reply #52, the functional conclusion is that the restoration of the MBR – when recovering the PC with a Ghost 9 or Ghost 10 image/recovery point – is not a concern, with the application handling the required actions.  In other words, in the world of Ghost 9/Ghost 10, it’s all a non-issue.

Nonetheless, I wonder:  With the Restore MBR setting “Ticked or unticked, you still get a MBR” – but, is it the same MBR?  For example, in the unticked case, Ghost 9/Ghost 10 might be installing the ‘generic’ or ‘standard’ MBR; whereas in the ticked case, the application may be designed to restore the original MBR contained in the .V2I file which (depending upon the PC’s unique configuration) might not be the same as the ‘generic’ or ‘standard’ MBR.  Could this be how it works?

One way to test this hypothesis is to repeat your procedure, but first manually add a unique byte sequence ‘signature’ into an unused segment of the MBR before creating the Ghost .V2I image/recovery point.  After setting the MBR to zero, the restore can be performed (A) with the Restore MBR ticked and (B) without that option ticked.  In the former case, your new and unique signature should be present; in the latter case, it should be absent.

Pleonasm wrote:
With the Restore MBR setting “Ticked or unticked, you still get a MBR” – but, is it the same MBR? . . . One way to test this hypothesis is to repeat your procedure, but first manually add a unique byte sequence ‘signature’ into an unused segment of the MBR before creating the Ghost .V2I image/recovery point.

Right, that's part of what I meant earlier about controlling all variables.  But you have to be careful about what you decide is an "unused segment".  Just because a group of bytes are zero doesn't necessarily mean they're unused or optional.

The technique I often use in examinations of this sort is to change the text of one of the messages.  Most disk editors, including de.exe, show you ascii text on the right side of the display, so for example I might change the text of the "Missing operating system" msg to "Mixxing operating system".

Dan, a good recommendation concerning the marking of the MBR for test purposes.

Brian, the world awaits with bated breath the results of your continued investigation . . . .

Pleonasm wrote on Aug 21^st, 2006 at 9:35am:

In other words, in the world of Ghost 9/Ghost 10, it’s all a non-issue.

I agree.



Quote:

One way to test this hypothesis is to repeat your procedure,

When can I go fishing? I'll do the test today. Fishing tomorrow.

Last night I zeroed the MBR and then made a non-formatted primary partition with Partition Magic. I then checked absolute sector 0 and it was full of code. So creating partitions with PM does create a MBR. Something to remember with these tests.

Brian wrote on Aug 21^st, 2006 at 3:23am:

I took the opportunity of again zeroing the MBR (and checking for all zeros). I tried to restore the Ghost 2003 image to Unallocated Space and as you found, it was greyed out.

Dan Goodell wrote on Aug 19^th, 2006 at 3:55pm:

I just ran a test in which I zeroed out the MBR and then restored a Ghost 2003 partition image.  The partition table (at the bottom of LBA-0) was adjusted, but the boot code portion remained zeroes.

Dan, were you able to restore the image to Unallocated Space with the MBR zeroed?

I just realized that even though I had created my image with Ghost 2003 booted from DOS CD... I have been restoring it using Ghost 8 from Bart PE CD from a USB HD. So I repeated my tests restoring from a slave IDE drive and using 2003 from boot CD.

Local / Partition / From Image  restoring to unallocated space:

Ghost 2003: greyed out, only allows restore to existing partition
Ghost 8: will restore, but will not boot

Local / Drive / From Image  restoring to unallocated space:

Ghost 2003: restores and boots
Ghost 8: restores and boots

I also used de.exe to verify that the MBR was zeroed each time. Cool program by the way and easy to use.

With the original HD installed I used de.exe to edit the ascii text of the MBR. I edited "Missing" to "Mixxing".

A Ghost 10 image was taken (recovery point)
de.exe was used to confirm that the MBR was still marked
The HD's were swapped
MBRWork was used to zero the MBR and EMBR
de.exe confirmed all zeros
Ghost 10 restore with Restore MBR ticked
The OS booted normally and de.exe confirmed that the marked MBR was present
MBRWork was used to zero the MBR and EMBR
de.exe confirmed all zeros
Ghost 10 restore with Restore MBR not ticked
The OS booted normally and de.exe confirmed that the marked MBR was not present

So if you don't tick Restore MBR then you get a generic MBR. If I understand Dan correctly, this doesn't matter.

Brian wrote:
"Dan, were you able to restore the image to Unallocated Space with the MBR zeroed?"

I didn't know that was an option, so never tried it.  I've always done Partition-to-Image, and upon restore have always preferred to manually create and adjust partition sizes prior to filling the partition with contents from an image.

ckcc wrote:
"Local / Partition / From Image  restoring to unallocated space:  Ghost 2003: greyed out
Local / Drive / From Image  restoring to unallocated space:  Ghost 2003: restores and boots"

Was your image created Disk-to-Image or Partition-to-Image?  I could see where that might make a difference in whether or not it included the MBR.

ckcc wrote:
". . . de.exe . . . Cool program by the way and easy to use."

Yeah, it's a nice clone of the Norton DiskEdit program.  The DiskEdit interface was a little better because it put an entire sector on one screen (de.exe has to scroll), but my old copy of DiskEdit could only do CHS and de.exe can do LBA.  It does have some limitation, though, as I think there's some maximum sector beyond which it can't reach.

The de.exe program is actually called PTS Disk Editor.  It was originally developed by a company called PhysTechSoft.  They got out of the field long ago and switched the focus of their business, but somehow The Starman seems to have permission to continue distributing it.

Brian wrote:
"... Restore MBR ticked ... The OS booted normally and ... the marked MBR was present
... Restore MBR not ticked ... The OS booted normally and ... the marked MBR was not present"

Interesting information.


"So if you don't tick Restore MBR then you get a generic MBR. If I understand Dan correctly, this doesn't matter."

Right, it doesn't matter if it's just an ordinary bootable partition.

It would matter if you had a special MBR, such as boot managers, Disk Manager, EZ-Bios, encrypted file systems, Go-Back, or the special MBRs some manufacturers are starting to use to enable their on-disk restore or HPA access.

Dan Goodell wrote on Aug 21^st, 2006 at 8:45pm:

Brian wrote: "Dan, were you able to restore the image to Unallocated Space with the MBR zeroed?" I didn't know that was an option, so never tried it.  I've always done Partition-to-Image, and upon restore have always preferred to manually create and adjust partition sizes prior to filling the partition with contents from an image.

What confuses me is how did you create that partition and still leave the MBR zeroed. As I mentioned above, Partition Magic creates a MBR.

Christer wrote:
Now, it's time to create the first image and if that one is "disk to image", all subsequent images can be "partition to image".

With this initial image, if Disk0 should die, I would have to restore the initial "disk from image" and I have the option to adjust partition sizes. Next, I would have to restore the most recent "partition from image".

Clever approach.  Based on the experiments others are doing, that should capture the MBR boot code, and I guess it would capture the partition sizes of all the created-but-empty partitions, right?  But the disks have separate partition tables.  Can you put both disks in one image, and if so, I wonder if one image would then capture both partition tables?

Another approach is to just backup the MBR sector with mbrsaver, mbrwork, et al.  Then, at restore time you'd restore the partition tables to layout the partition boundaries, then fill them all with Partition-from-Image contents.  (In fact, you could backup your partition tables now without having to wait until you rebuild the system.)

Was your image created Disk-to-Image or Partition-to-Image?  I could see where that might make a difference in whether or not it included the MBR.

Dan,

my image was created Partition-to-Image... so does not contain the MBR. so is only bootable if restored to an existing partition or a non zeroed drive previously containing a MBR.

Brian wrote:
"What confuses me is how did you create that partition and still leave the MBR zeroed. As I mentioned above, Partition Magic creates a MBR."

For the experiment, I used an existing disk and zeroed out the boot code with de.exe and left the partition table.

But on occasion I have manually created a partition table on a blank disk with ptedit or de.exe, and that would leave the boot code area blank.  (In fact, I'm in the middle of doing some research on Host-Protected Areas, in which I'm fooling around with a blank disk and creating and destroying partitions at will.  Can't use PM, as it can't recognize an HPA.)

Dan Goodell wrote on Aug 21^st, 2006 at 9:31pm:

For the experiment, I used an existing disk and zeroed out the boot code with de.exe and left the partition table.

I understand now. I was zeroing the MBR with MBRWork which zeros the whole of Absolute sector 0. So in Ghost 2003 I just saw Unallocated Space on the HD and it was greyed out so the image couldn't be restored. I found earlier that you could restore a Ghost 2003 image to Unallocated Space if a MBR was present.

Dan Goodell wrote on Aug 21^st, 2006 at 9:21pm:

Another approach is to just backup the MBR sector with mbrsaver, mbrwork, et al.  Then, at restore time you'd restore the partition tables to layout the partition boundaries, then fill them all with Partition-from-Image contents.

That's clever too. I just backed up the First track of a multi-partitioned HD with MBRWork, then deleted the partitions and zeroed the MBR. Then used MBRWork to "Restore first track" and all the partitions are back again.

Do you have to use a floppy to "Backup first track"? Can you use a CD and write the backup to the HD?

I tried MBRSaver as well. Really nice restore menu, Dan.

Dan,


Quote:

Based on the experiments others are doing, that should capture the MBR boot code, and I guess it would capture the partition sizes of all the created-but-empty partitions, right?

Yes, that is how I understand it!


Quote:

Can you put both disks in one image, and if so, I wonder if one image would then capture both partition tables?

I have never tried this but I don't think it would be possible. In Ghost 2003, the source and target partitions can not be the same. The target partition would be included if both disks were included.

I have not been interested in an image of any other partition than the boot/system partition. F: and G: on Disk1 are both targets for backups (using Karens Replicator) of D: and images (using Ghost 2003) of C: respectively on Disk0. E: on Disk0 is a backup (copied in Windows Explorer) of G: on Disk1.

I said "have not been interested in" but as the data partition fills up, it takes longer for KR to run the different jobs (checking each folder and file for changes, adding new folders and files (and it can be set to remove deleted folders and files). Creating an image of the data partition would probably be quicker and retrieving a file or folder from the image in Ghost Explorer would not be much slower than copying the backed up file or folder from Windows Explorer.

I have downloaded the utilities you recommend but have currently not the time for experimentation.

Christer

Dan,

I forgot to mention that Disk1 is in a mobile rack which is not running under normal conditions. Only when I backup/retrieve or create/restore is it running.

I have a third hard disk which goes into the mobile rack. Disk"1b" as it might be named, contains H: and I:. WinXP keeps track of the assigned drive letters as long as I don't restore an image. After restoring an image, Disk"1b" is again unknown and will be assigned the same drive letters as Disk"1a". I will again have to reassign F: > H: and G: > I: respectively.

I think that WinXP stores the volume identities for Disk"1a" and that information is on the image of C:. After restoring an image and rebooting, Disk"1a" is not redetected.

Christer

Brian wrote:
"Do you have to use a floppy to "Backup first track"? Can you use a CD and write the backup to the HD?"

I think mbrwork merely writes to the "current DOS directory".  That's a term that means whereever you were when mbrwork was launched.  If you change the drive or directory so you're not at the prompt for the CD drive letter, that should work.

I boot from a USB thumb drive, and just let mbrwork write on that.

"I tried MBRSaver as well. Really nice restore menu, Dan."

Thanks.  I wrote that program because I couldn't find anything that would restore the MBR boot code from a saved backup without also overwriting the partition table, and vice versa.  Commands like "fixmbr" can avoid the partition table, but they only do generic boot code and can't restore from a saved backup.  All the tools that restore from backups seem to insist on overwriting the whole sector.  I think my program may still be the only one around that can selectively restore parts of the MBR sector.

Christer wrote:
"I have not been interested in an image of any other partition than the boot/system partition."

Ah, okay.  I was thinking you were trying to capture the partition layout on both disks.  That would probably require at least one Disk-to-Image for each disk.

If you're not doing images of the non-OS partitions, then I take back my earlier suggestion of just backing up the partition table.  Restoring the partition table only lays out the partition boundaries, but wouldn't properly recreate the actual partition and make it ready to be refilled with files.  Restoring just the partition table only works if you're relying on Ghost to create the actual partition structure within the boundaries the partition table is giving it.

Your idea is looking better.

Dan,


Quote:

Ah, okay. I was thinking you were trying to capture the partition layout on both disks. That would probably require at least one Disk-to-Image for each disk.

Yes, I am almost sure it would.

If Disk"1b" had (at some point in time) been connected and the drive letters changed to H: and I: prior to creating the initial Disk-to-Image, I think that WinXP would keep track of those drive letter assignments too.

I should have mentioned that a replacement Disk1 would have to be partitioned in Windows XP Disk Management prior to restoring the respective image. I don't think that formating would be necessary. Sorry for leading you astray ... :-[ ... !


Quote:

Your idea is looking better.

Well, simpler at least for a layman like myself.

Christer

Based on Brian’s Reply #59, we now know:

• Ghost 10 automatically includes the MBR when creating a recovery point of the operating system partition, as Symantec had previously indicated (see Reply #1).
  
• Ghost 10 will restore the MBR contained within the recovery point (.V2I file) if the “Restore Master Boot Record” option is enabled (see page 103 in the Norton Ghost 10.0 User’s Guide).
  
• Ghost 10 will write a ‘generic’/’standard’ MBR when (A) restoring an operating system partition and (B) when none is already present on the hard disk drive, if the “Restore Master Boot Record” option is disabled.
  
• In conclusion, when using Ghost 10, there is no need for the user to be concerned about manually backing up the MBR – the application handles the hassle.

Kudos to Brian for all of his exceptionally helpful and courteous testing!

P.S.:  Perhaps another member of the forum can summarize the learnings from this thread for Ghost 2003 users?

Dan Goodell wrote on Aug 22^nd, 2006 at 6:35am:

I boot from a USB thumb drive, and just let mbrwork write on that.

Dan, I made my first bootable USB thumb drive today and while MBRSaver and MBRWork run OK it doesn't have mouse drivers to run PTEDIT, de.exe, etc. Do you have any easy to follow instructions?

Brian wrote:
"I made my first bootable USB thumb drive today and while MBRSaver and MBRWork run OK it doesn't have mouse drivers to run PTEDIT, de.exe, etc. Do you have any easy to follow instructions?"

Just copy the mouse driver file onto the USB thumb drive and call it in autoexec.bat.  There are plenty of generic mouse drivers around, but you can just grab the one off my dsrfix98 CD, which I think you already downloaded and burned.

Insert your USB thumb drive in a USB port, insert my dsrfix98 CD, and boot from the CD.  I don't recall which mouse driver I used (mouse? ctmouse?), but I think I embedded it in the boot image, which means it should be in the A: drive after booting from the CD.  Copy it from A: to your thumb drive, and call it in your autoexec.bat file.

Thanks Dan. Done.

Quote:

P.S.:  Perhaps another member of the forum can summarize the learnings from this thread for Ghost 2003 users?

Personally, I don't have enough empirical test results to summarize all hard disk setups (number of hard disks and partitions) but based on the "test reports" in this thread:

The success/failure of restoring an image, created "Partition-to-Image" of a boot/system partition, seems to depend on whether the target hard disk is brand new or if an Operating System has previously been installed on it. If brand new > failure (needs MBR fixing), if previous OS installed > success. It may also depend on whether a third party partitioning tool has been used to prepare the new hard disk or not.

I have done a Disk-to-Disk when upgrading a system for a friend and there was no problem booting from the new hard disk as long as the old hard disk was removed and the new hard disk had taken its place on the controller. Bearing that in mind, I speculate that an image created "Disk-to-Image" contains the MBR information needed for a successful restore to a brand new hard disk and that the new hard disk would not need pre-partitioning or pre-formatting. Partition sizes will be proportional to the original sizes but can be adjusted during the restore process.

Christer

ckcc

Still tied up with those projects--I can be online briefly, intermittently--but, not enough time to play with this as much as I'd like...  :(


Quote:

You have raised a few more interesting questions... which are beyond me answering. I'm gonna sit back and listen and learn.

Oh!--don't stop now!  Your contributions have been most welcomed!

Brian


Quote:

I think we have a cultural clash. Aussies usually regard “tick off” as “untick”.

Thank you for your cross-cultural *sensitivity* training  ;D .  Especially liked the John Cleese link--lol !

I've seen you use that term, but note--I sub-consciously knew I may not be using the term correctly--I put it in quotation marks!

Around here, *tick off* means to make someone mad--like in "Are you trying to tick off the boss?"  Hmmm...I think the Aussie interpretation of that sentence would probably make the workers happier  :D !

Dan Goodell

Always glad to have your insightful comments.


Quote:

(BTW, the third link in NightOwl's index erroneously links to a description of an NTFS partition boot record instead of an MBR description.)

Fixed--thanks for letting me know.  Also added a reference/link to your reply #51 to clarify my summary points.


Quote:

"Have to wonder, though, what, if any functionality is missing when using an NT system with a Win98 MBR code loader" None.

Wonder why the coding is different--what else does that code do?


Quote:

NightOwl quoted: "One of the first things that any PC user should do ... is to make a copy of its MBR; especially if you have more than one partition on the disk! Why? If you accidentally overwrite this sector, or are infected by a Boot sector virus, you may never be able to access some or even all of your disk again! Even the most expensive HD utility might not correctly restore the Partition Table of a multi-partitioned hard disk!" FTR, any partition table can always be recontructed manually, as long as the partitions themselves are still intact.

Are you saying that Starman's statement about needing a backup is not true?  Is the statement *dated*, and are there  HDD utilities now that can correctly restore Partition Tables accurately and reliably?  Starman's site says to either have a *file* backup that can be restored--or a printed copy of the data so you can use a disk editor to *manually* enter the Partition Table data.

Are you saying there is another way to *manually* reconstruct the Partition Table?  Or, are you saying you can use a disk editor to *manually* enter the Partition Table data if you have a printed copy or you have hand-written the data down?  

Please elaborate.

Oh!--don't stop now!  Your contributions have been most welcomed!

I'm not stopping, just slowing down to absorb all this info and maybe try to summarize my findings.

NightOwl wrote on Aug 24^th, 2006 at 12:33am:

Wonder why the coding is different--what else does that code do?

It's just some minor streamlining, which makes the Win2K version of the MBR boot code slightly more compact that the Win98 version.

I just went back and took another look at The Starman's code disassembly.  The only substantive difference between the W98 and W2K versions is the portion where the boot sector of the active partition (the PBR) is actually read from the hard disk.  The W98 version defaults to CHS disk read functions but attempts to switch to LBA for certain partition types.  The W2K version defaults to LBA but if that's not supported it switches to CHS for certain partition types.



Quote:

Are you saying that Starman's statement about needing a backup is not true?  Is the statement *dated*, and are there  HDD utilities now that can correctly restore Partition Tables accurately and reliably?  Starman's site says to either have a *file* backup that can be restored--or a printed copy of the data so you can use a disk editor to *manually* enter the Partition Table data.

It's correct but needs to be understood in context.  A backup is always better than no backup.  If you do not have a backup, then the question is not whether reconstructing the partition table is possible--it is possible, but the question is how easy would it be.  My point is the quote makes it sound like partition table reconstruction might be impossible in some cases.



Quote:

Are you saying there is another way to *manually* reconstruct the Partition Table?  Or, are you saying you can use a disk editor to *manually* enter the Partition Table data if you have a printed copy or you have hand-written the data down?

Absolutely.  That's the way I always do it.  Even if you don't have a record of the contents you can still rediscover what the values should be, though of course it's going to be easier if you wrote it down beforehand.

The partition table descriptors are simply pointers to the actual partitions.  If you lose a descriptor, the partition it pointed to is still there, untouched.  To rebuild the descriptor, all you have to do is rediscover the size, location, and type of the partition.  If the partition is still intact, that's not impossible to do.  (And as I said earlier, if the partition is not intact, then a backup of the partition table won't do you much good.)

The best tool I've found to help you rediscover where the partitions are is Mikkelsen's FindPart utility.  What it does is search your entire hard disk looking for anything that looks like it might be a PBR sector or extended partition table.  If partitions are still intact, it will find them.

FindPart is a report-only tool.  It does not fix anything, it just helps find the information for you to do with what you will.  You should try downloading it and see what it does.  There are DOS and 32bit versions, so you can even run it from a XP command prompt window.

If your disk has been reformatted or repartitioned several times, you'll find there may be a lot of orphaned PBR sectors scattered around the disk.  (The data in them remains until the sector is subsequently overwritten by other data.)  FindPart will find those, too.  The trick is figuring out which of FindPart's discoveries represent your lost partitions and which are leftover detritus.  The information is in there, so it's not impossible to rebuild the table descriptors, but the more repartitioning you've done, the more difficult it will be.  This is where it comes in handy to have a keen eye, some technical knowledge, and some background knowledge of what partition layout you had before you lost it.  

And that's the part where "even the most expensive HD utility" can guess wrong.  I believe that phrase refers to automated recovery tools, and should be taken in that limited context.  If you manually rebuild the descriptors and guess wrong, you can go back and try something different--the right combination is always there somewhere.  If an automated tool guesses wrong, how do you tell it to try something different?

Dan

Thanks for the explanation--much clearer now!

NightOwl wrote on Aug 20^th, 2006 at 3:45pm:

3.  But, what is probably more critical is the *Partition Table* that is the last portion of Absolute Sector 0: For regular Ghost users, you may want to take the above advice under *advisement*--you don't want to go restoring the *partition table* to a HDD that you have made any adjustments to the partition layout.  And when you restored an image to a HDD--Ghost may do some adjustments to the partition layout using *built-in behind the scenes* partition *adjustments*--even if it's to the same HDD as the original source HDD for the image! So, it's not a bad idea to have a back up of the MBR sector with the *partition table*, but caution in using the restore function of the MBR sector--it has to be for that exact partition layout without any changes having been made since the last MBR sector backup!

I hope not too much of this thread has been forgotten. I don't think we spent any time examining NightOwl's thoughts about the Partition Table. When I restored the Ghost 10 image with the marked MBR I didn't check to see whether the Partition Table was restored identical to the original or just the boot code that was identical. These quotes from Acronis Support jogged my memory about this thread.


Quote:

I've just consulted with the respective person from our Development Team and he assured me that whatever restoration scenario you follow partition table is not being restored. Instead, the new partition table is created in accordance with the new partition layout.

Quote:

Please be aware that the actual reason why we recommend to re-create the same partition layout on the destination hard drive as it was on the "original" disk is that the restored\transferred operating system may not boot or function incorrectly (usually it "hangs" on the "logon" or "Windows logo" screens) if some partitions this particular Windows installation is "aware" of are missing. If you restore Windows to a partition of the different number than it was installed originally it will not boot until you will make the appropriate changes to the boot.ini file. Please also note that, as I have already mentioned above, under no circumstances Acronis True Image restores the "old" partition table. It would be too dangerous and cause troubles to those people who restore individual partitions to the already partitioned drives. Instead of restoring the "old" partition table, Acronis True Image creates new one in accordance with the current partition layout. The capability of backing up MBR is basically intended to preserve the ability to use boot loaders, boot managers, special service partitions and the alike after the image is restored rather than to preserve the "old" partition table, i.e. the "old" partition layout.

The Acronis thread was discussing restoring the MBR. So when you restore the MBR with Acronis TI you don't get the old Partition Table. Sounds reasonable.

Do we know the answer for Ghost?

Sorry for bumping this thread. But I was wondering if the issue NightOwl stated in his first post is also true in this case: http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1180316130/0#6

Consequently, can an OS image that was created with partition-to-image of a partition on a single disk be restored to a RAID-0 array using the same disks where the OS was installed on before.