Restoring system partition only - boots ?!
OK, simple scenario using TI 2010:
1 HDD (160gb) , XP installed on a 160gb partition. Boot into TI2010 CD and made a disk backup - so C: partition and MBR/Track 0.
Now, spare HDD. If you restore the system/C: partition only and not the MBR, is it meant to boot? The wizard automatically used the same partition type (primary, active). This destination disk is one I just quick-wiped so it has no data on it (well, at the beginning/end of the drive... wiped with WD diagnostics quick erase, so first million/last million sector wipe).
If you go into "backup" menu of the recovery CD, you can see it lists the drive with just the XP system partition, no MBR/track 0... Yet it still boots? My whole understanding of a MBR just went out the window.. :(
On that note of restoring an image, why, when selecting the target destination drive, does 2010 auto-expand the partition size to the destination drive? Is it to avoid scenarios where people are moving to new disks, but instead of cloning, they used backup image method?
Thanks Mark. I did some deeper digging and found out about the generic MBR. I sort of had a gut feeling that or something similar was the case.
Regarding the auto-expansion, that's basically the conclusion i came to, i.e. convenience. Though the logic in doing that, I figure people would probably be use cloning process for that task, so it kind of left me still wondering the reasoning.
Thanks for the response.
edit #1: just to correct my first post... I forgot that when you back up, if you select the 'disk' method, it includes the MBR, it just doesn't show it and that's why it wasn't visible. my mistake
edit #2: Just a follow-up query.. say you wanted to restore a backup image to a blank (larger) disk, but wanted to keep the same partition size as in the original backup, as well as keep the disk signature. would you restore the MBR in the first restore operation, then go back and restore the partition (ie. tick just the MBR first round... then tick just the system/primary partition the second time)? essentially does it matter which order you do it in?
This is probably the worst service I have ever found and I am not where I hoped to be, even now.
I upgraded to True Image Home 2010 from 2009. I was attempting to cancel 2010 and restore 2009.
With 2010 I could not clone my disk, a problem which I had not had previously.
During the process when the reboot was to take place, I received the following message;
"Cannot reboot windows. You probably do not have enough privileges to perform the operation."
I am the administrator and had no problem with 2009.
I would really prefer my trusted 2009
edit #2: Just a follow-up query.. say you wanted to restore a backup image to a blank (larger) disk, but wanted to keep the same partition size as in the original backup, as well as keep the disk signature. would you restore the MBR in the first restore operation, then go back and restore the partition (ie. tick just the MBR first round... then tick just the system/primary partition the second time)? essentially does it matter which order you do it in?
Ozzy:
You would just restore the image. While setting up the restore, resize the partition to the desired size. It isn't necessary to restore the MBR.
In the newer versions of TI (I'm still using TI 10), if you set up a bunch of partitions to restore and you also include the MBR, then TI will override your choices and restore the full disk image with the exact same layout and partition sizes as on the source disk. If you want different sizes, do not include the MBR choice in the restore.
To keep the same disk signature, after you have restored in the first step, then go back and restore the MBR only in a second restore operation. There is a checkbox in the latest TI versions that lets you also restore the disk signature from the source disk.
Hey Mark,
Did some more testing to kill some time today. My findings (although this is nothing spectacular). Used gparted to look at the raw MBR in hex.
In ATI 2010 at least:
--- If you restore a backed up MBR to a blank disk, but nothing else, it will be modified in the sense that the partition table is cleared. Can also clearly see the disk signature being tranferred too, so that's all good.
---- If you restore a partition at a latter stage, the partition table (at least one 16 byte field, since I'm only testing with one partition) is modfied.
>> end result is an identical disk MBR when you restore partitions. byte for byte, it's the same as the original drive.
---- If you restore a partition only, you get Acronis' own MBR written, which does the job, though a new signature. The only thing that is the same as the original MBR is the partition table.
---- If you restore a partition, then later restore the backed up MBR, it will overwrite the Acronis MBR, as expected, but maintains the partition table contents from the Acronis MBR, so everything runs smoothly.
Nothing ground breaking, but it appears as though it doesn't matter which way you do it; if you want to achieve an identical MBR & retain disk signature, both ways end up with the same byte-for-byte MBR. Probably preferable the first way, so it doesn't have to re-write the MBR; rather, just modify the partition table when restoring partitions.
At least, that's my thinking...
Ozzy:
Good work. This is all consistent with my understanding of what a Restore MBR and Track 0 operation means in TI. A rough translation is "to restore everything in the first 63 sectors of the disk except for the 64-byte partition table".
This point is confusing to a lot of people. When they hear MBR they think of the first sector on the disk, and incorrectly assume that restoring the MBR will restore every byte in the first sector of the disk, including the partition table. Of course this is incorrect. To do this would be suicide on Acronis's part. Restoring an old partition table would result in data loss if the user had added or moved or resized any of the partitions between the time of the backup and the time of the restoration.
I agree that your first method looks to be the most efficient. Thanks for the additional info.