Track 0 and MBR Partition Question
When I ran a recent single partition image operation (not a disk image) using TI 11.0 Home 8101 of WinXP's primary booting OS partition and later recovered it onto a new clean platter HDD , I was offered two partitions to recover including a Track 0 / MBR partition (which I did not Image, that I know of) plus the original WinXP C Drive OS booting Image I made during the image process. Was I required to choose both in my case during recovery? I did chose both and everthing worked out fine and the new HDD became C just like before but w/o the extra extended D drive logical partition that I did not want to transfer over to the new drive.
However, why was the Track 0 / MBR partition also imaged initially when I only chose the one primary booting OS partition and do I always choose the Track 0 / MBR during a recovery operation?
Thanks.
Steve, I have a question about the MBR sector. Here's my info:
- Win 7x64 Home Premium OEM on 2 PC's
- Acronis 2011 TI Home
- All HDD's are MBR spinner drives.
- I've cloned many times without issues on my 2 PC's and a family member's XP PC, about 165 clones to date over about 4 years. I use Cloning along with Imaging for my HDD backup plans. I always Clone from the Linux boot CD in "automatic" mode.
Regarding the Win 7 Sector one 512-byte Master Boot Record; I read elsewhere that Acronis writes its own MBR when Cloning a HDD, vs copying the MBR as is from the Source HDD.
That doesn't make sense to me but I wanted to ask you about it.
Scoop, I suspect that you have far more experience in using cloning than I do myself as I certainly have not done as many as you have.
I cannot see why Acronis would ignore the original MBR data if present, as this may not be the Microsoft default for the version of Windows OS present on the drive, for example, I have a modified MBR on several of my systems because of having dual-boot scenarios and I would not want to lose that MBR simply because of doing a clone of my main boot drive!
The scenario where Acronis may write a default MBR is where there is no MBR saved with an image and are recovering to / cloning to a blank drive. Then it would make sense because a MBR is required for legacy (BIOS/MBR) boot systems. otherwise you would need a Windows install / repair disc to be able to issue a FixMBR command.
Steve, thanks for the info.
I forgot to mention my Cloning routine as this may relate to what you mentioned about Acronis possibly creating its own MBR on a blank Target HDD.
Before I restart my PC (to boot into the Acronis CD), I attach my Target HDD while running Windows. I do this to "prep" the HDD by using the Diskpart 'clean' command to unallocate the HDD.
I do this to eliminate any possibility of cloning in reverse when running the Acronis Linux program since the Target HDD will be easily identified with no data & 'unallocated'. Acronis will also automatically select the unalocated HDD as the Target HDD as (I assume) the program detects no readable content on the Target HDD so logically that's the one that will be selected as the Target HDD.
Regarding Diskpart's 'clean' command and 'MBR' HDD's; the command does a couple of things:
- Marks all content for deletion. It doesn't overwrite with "1's & 0's" (the 'clean all' command will do that).
- Unhides hidden sectors. I'm not certain if it actually accesses those sectors & marks that content for deletion (ie, an HPA sector).
- Zero's out the Master Boot Record.
I'm almost certain that Acronis (2011 ver) doesn't create its own MBR but it's something I've been curious about for a while as I Clone every 2 weeks.
Regarding Cloning risks: The only 2 failures I've had in 4 years were interesting and were related to the 'Disk Signature', which resides in the MBR sector.
This is another reason I prep my Target HDD's before Cloning as the 'clean' command zreo's out the MBR, including the 4-byte signature value.
Here's the strange part as many people believe the Cloning process doesn't affect the Source HDD (assuming there are no abnormalities during the Cloning process such as power glitches/failures, etc & assuming the Cloning process didn't report any errors during the process.)
When the 2 Cloning failures occurred over the past 4 years, both the Source & Target HDD's were rendered unbootable. It wasn't an issue with me as I have 2 spare Cloned HDD's in addition to numerous full-HDD Images stored on my 'backup' HDD.
Anyway, these 2 failures occurred before I bagan unallocating the Target HDD before Cloning. Back then, I usually deleted the 'C' partition just to make Target HDD identification easy when booted into the Acronis Linux platform. However, the MBR sector was unchanged. This was key in identifying the 2 Cloning failures which rendered both Source & Target HDD's unbootable into Windows.
I cloned as usual, with no errors reported during the process. I removed the newly-cloned Target HDD after shutting down the PC.
When I tried to boot back into Windows on my original Source HDD, I received the Windows error 0xc000000e which usually means the MBR is either missing or corrupt. I tried booting up on the newly-cloned Target HDD and received the same Windows error.
That was surprising as I'd always believed that the Cloning process doesn't affect the Source HDD, only reads it.
I verified the problem by duplicating the 'Disk Signature collision' conditions. The same error occurred so I knew the DIsk Signature condition was rendering both HDD's unbootable.
I booted into my Windows System Repair CD & ran the CMD 'bootrec' :
bootrec /fixmbr
bootrec /rebuildbcd
Both HDD's booted into Windows ok after that.
My Disk Sig collision status occurred for this reason:
I had run an 'Image Restore' on one of my spare HDD's and was using that HDD as my Target HDD for Cloning. The Disk Sig collision within Windows (before booting up into the Acronis Linux CD) was expected as I had restored a full-HDD Image to that HDD which duplicated the original Disk Sig into the MBR of that HDD.
(I run 'test' Image Restore's about once every 3-4 months on my PC to verify a 'bare-metal' recovery path using my Acronis CD and an unallocated HDD.)
The bottom line is that I'm surprised, regarding a Windows Disk Signature collision, when cloning with Acronis 2011, (unsure if other versions would have the same results), that the Source HDD is affected during the Cloning process and reports no cloning errors but renders both Source & Target HDD's unbootable into Windows.
The fix is easy, took me about 10 min's to repair the MBR but this story taught me that the Source HDD can be affected by (at least Arconis's) a cloning process, at least when a Disk Sig collision condition is present.
I haven't verified this scenario using my other backup software (Macrium Reflect free ver) so this "Disk Sig/Source HDD unbootable" issue may be unique to how Acronis clones Windows (7) HDD's.
Anyway, it's easy to avoid the issue as I always use Diskpart 'clean' to unallocate & zero the MBR before Cloning. Those were the only 2 Cloning errors out of 165 cloning processes.
I'm still amazed at the reliability & repeatabiliy of the HDD Cloning process. I test my Target HDD once every 5 Clones or so. I used to test after each one (boot into Windows on the Target HDD, run it a while) but I've never encountered a situation, except for the 2 failures, where a Target HDD didn't boot into Windows without issue.
Scoop, thank you for sharing your experience with cloning and the issues you've encountered regarding disk signatures and potential unbootable drives after cloning. I am sure that other users will find this information very useful here in the forums - I will bookmark it for reference because it is so comprehensive!
10-4, you're welcome :). Hope it helps someone out there that may encounter the same scenario.