My primary harddisk (250GB Samsung) got corrupted and I bought a new one (750GB Samsung). My secondary harddisk had the image of the primary partition (C: drive, where Windows XP resided, 33 GB; with two more partitions) and I wanted to restore that image to the new drive using the Recovery CD environment.

On the first attempt, I pointed the 750GB drive as the destination but it refused, because the new drive did not have any partitions at all. It required a partition to restore into. At that stage, I did not have the exact size of the original drive, I made a wild guess, and created a 50 GB partition on the 750GB drive. And it worked, but I ended with the weird situation of having allocated 50 GB for the partition, but being able to see only 33GB under Windows.

I think it would have been very helpful if the Recovery environment made an educated guess, realized that I was trying to restore to a different harddrive and offered to create a partition with the exact size as the original one.

On the second attempt, I created a partition with the correct size on the 750 GB. As in the first attempt, the restore operation completed successfully, however, when I want to view the partition info with Partition Magic, it gives me an error and I am concerned with data safety. During the restore, I checked "Restore MBR" option, but now I realize that this was a bad idea, because I think this created an MBR on the 750GB which was appropriate for the 250 GB hard drive. The only similarity between the old and the new drive partition arrangement will be the primary partition. Apart from that, other partitions won't be the same.

So, my understanding is that in my case, while restoring, I shouldn't have checked "Restore MBR" option.

All in all, I have found the documentation to be very poor. The helpfile says: "You can restore the MBR from the image file that was saved
with the backup image or you can restore an original Windows XP MBR." What does "an original Windows XP MBR" mean? It is rubbish, because Windows XP is an operating system and an MBR is something specific to a particular hard drive. I need further explanation here.

Let's work backwards on this and see where we get to.

Firstly, the MBR that most backup software products talk about is nearly always a reference to the MBR boot code. This is just one part of what is called the MBR. This code is normally the first 300 bytes or so of the MBR. It is a very basic piece of software that reads the partition data (also in the MBR) and then loads the boot sector on the active partiton.

When you install Windows XP, or earlier, a *standard* version of the MBR boot code is written to the disk. When SP backups up a volume it also makes a copy of the full MBR, including this MBR boot code. If you restore back to the same HDD and select "restore MBR from backup", SP will simply overwrite the existing MBR boot code with the one from the backup image. If you select "restore an original Windows XP MBR", SP will just load the *standard* MBR boot code used during a Windows installation.  Equally, if you boot into the Windows rescue environment and type "fixmbr", the utility will simply overwrite the existing MBR boot code with the Microsoft *standard* version. In other words there is no difference between the *standard* MBR boot code (original Windows XP MBR) and the one in you backup image.

So you may ask why SP, and other backup products, ask if you want to restore the MBR? The reason for this is that there are some applications actually change the *standard* MBR boot code with a modified one. Such applications/utilities include: Full disk encyption; snapshot applications; pre-boot menus and PCs that have a pre-installed "rescue" partition. Depending on your circumstances, you may or may not want this modified version, you may just want the old *standard* version. In your case, it doesn't make any difference. In fact, if you restored to the same HDD it would already have the MBR boot code on the disk.

One thing to keep in mind is that the MBR is not disk specific. In some cases it is, in fact, OS specific. Non-Windows OSs can add any MBR boot code they want, as long as it fits in to the allowed space. With the introduction of Vista even Microsoft changed the MBR boot code (they made it a few bytes longer to help support their bitlocker program).

Ok, so hopefully that answered the queston about the MBR.

Let's try and answer the question about Partition Magic. My guess is that there is nothing wrong with the restore. Partition Magic looks for partitions to start and end on sectors, rather than on cylinder. If it does not see this, it flags a disk error. Unfortunately there are no standards on this. SP just happens to use a default setting of "start/end on cylinder". Both options are valid. If you want to avoid Partition Magic saying there is a disk error you can change the SP restore option to "start on sector" and "end on sector".

Now on to the partition size. When you restore a backup image the image will normally include information about the original partition size.   

 @FTTester

I'll confirm your answer concerning Partition Magic. I also use PM8 (original Powerquest version) and am only able to get it to see a disk properly after a SP restore operation by making sure during the restore that I select "start on sector" and "end on sector" in the "edit policy" option after right-clicking on the target space. You do have to change from the defaults in that respect. If you don't do that and accept the defaults, PM will read the entire disk as "bad" and you won't be able to perform any operations with it, at least I couldn't. I don't know if the same situation exists with the current Symantec version of PM. I don't believe this particular detail is in the manual either but I'm not throwing stones at StorageCraft because of it. I think Nate either hinted at the possibility or covered it in this forum some time back. That's how I learned about it. It's what forums like this are for.

You are also right that the default "start on cylinder" and "end on cylinder" policy in the VistaPE recovery environment is a valid one. Using the default policy, Disk Director 10 from Acronis will see the resulting disk partitioning correctly after a restore, so the situation with PM8 may be the exception rather than the rule. After all, PM8 from Powerquest is rather old at this time. In fact, using DD10 to slightly change a partition size after restore will then permit PM8 to see the same disk correctly afterwards - something I discovered by trail and error.

@sevketzaim

I always restore using the "exact size" option after right clicking the target space. In fact, it's all I can do when restoring fat32 since SP will not permit on-the-fly resizing, either up or down with that format. I then resize as desired after restoration, using either PM8 or DD10. Of course I can't go with a smaller disk that way using SP and pre-existing images but that's life.

Rod