Cannot Restore to new partition

I reported a problem with TI v 10: that I was unable to restore a backup image of my boot partition to another drive (it all appears to work, but the system will not boot). Acronis replied that it is Windows XP that prevents this. If this is so, then this largely negates the usefulness of TI to me.

If this is true, then it is a severe limitation of TI in a windows scenario. I wonder how many TI users falsely believe that they can restore from a backup of their Windows environment in the event of a HD failure ?

For the record, this is what I did:
1. Backup (image) the entire boot partition.
2. Restored this using the recovery CD to another HD.
All verification checks were successful
3. Tried to boot from the replaced HD (simulating a HD failure).
Windows hangs part-way through the boot process.

Any comments or suggestions would be gratefully received ?

Pete K

 

Hi, Pete.

You haven't reported where on another HD you restored the image.

- Was the other drive empty (brand new) ?
- Have you restored to the beginning (first partition)? And is it activated?
- Have you restored the mbr (master boot record)?
- Is the other HD an IDE type and connected to the first IDE Port and jumpered as master?

If it is the first partition and activated you may have to restore the mbr too. You can also use [fdisk -mbr] to get an working mbr.

good luck. aggronix.

 

Pete, just a few questions.

What brand computer? How many partitions on the original HD? Did you image the C: drive or the whole disk? Was the new HD empty or partitioned? Are both HDs IDE or SATA? Were both HDs in the computer when you first tried to boot the new HD?

Could you describe in detail what you see when the new HD tries to boot?

 

Aggronix,

Thanks for responding. Yes, I could have been a bit more informative. Let's see if I can do better this time:

The "new" HD was not actually new. Originally, it contained two partitions, the first of which was a working windows boot partition (in fact it was a old clone of my live boot partition, so it was exactly the same size). I restored to this partition.

When I did the restore, I did NOT also restore the MBR as I wanted to preserve the 2nd partition on the "new" drive. Also, the "new" drive was a different capacity to the old (live) one.

The cloned (I wish!) partition was marked as "active". When I booted the system, the "new" drive was the only HD present, and it did start to boot OK. Windows stopped after displaying the desktop. It was not hung, but was not usable. The drive was jumpered as MASTER and connected to the same physical location as the old HD.

What I was trying to do here was to test my ability to recover from a HD failure using a TI backup and the TI recovery CD. Acronis have informed me that this strategy does not work as windows prevents you from booting up from an OS that has been restored to a different partition. They did no say so, but it looks to me like this is a Windows copy-protection mechanism in play. Acronis also said that the process would have worked if I had restored to the ORIGINAL HD, but I'm not going to put that to the test and in any case, that is no good when the old HD is dead.

What DOES work, is cloning the entire partition (partition record too). I have done this using Acronis Disk Director (DD), but that is not the same as restoring to a NEW partition from a TI backup (of the entire partition contents).

It seems to me, that the ONLY way that you can recover successfully from a boot drive failure with TI, is to clone the whole drive, which is a real pain.

Pete K

 

Brian,

The PC is an Evesham Micros (Vale) AMD Athlon 1Mhz box. The Original HD has 4 partitions; the "new" HD always had two (it wasn't really new). The first partition on both HDs was a boot partition of exactly the same size. The drives are IDE.

The backup was created to a folder in the 2nd partition of the "new" drive. All of my drives are in removeable caddies, so the "new" HD drive & caddy was actually inserted into a removeable USB2 enclosure when the backup was created. i.e. this was a backup of the entire C: partition to a file on a removeable HD.

Prior to the restore, I removed the old HD and replaced it with the "new". I booted to the TI recovery CD and did the restore from there. So I restored from the backup file on the 2nd partition, overwriting the contents of the 1st partition. Incidentally, the obliterated 1st partition on the "new" HD originally had a bootable copy of windows; I could boot to this, so there was nothing wrong with the physical setup.

The problem appears to be that windows detects that the partition DATA is now in a different location (presumably it peeks into the partition record) and then refuses work.

What happens is this:
The BIOS detects the "new" drive correctly.
Windows boots up.
Windows displays the desktop.
The mouse works, but I can't run any programs.
Every now and then, there is a bit of disk activity.

I thought it might just (just!) be a corrupt registry, but when I reported the problem to Acronis, they said that the revovery worked as far as TI was concerned, but windows does not allow you to do what I attempted to do (restore an image of the OS to a DIFFERENT partition).

Thanks for your help.

Pete K

 

Pete, thanks for the detailed replies. You did exactly the same as I would have done. I use this scenario frequently in testing. It should have worked and it does sound like WinXP corruption.

It's nothing to do with the MBR. An error here won't let you find the Windows partition. It makes no difference to booting whether you tick Restore MBR or not. Similarly if you restore to the wrong partition (boot.ini problem) you won't see the Windows partition and there is an immediate hal.dll error.

I can't recall seeing your problem described in this forum. Anyone else?

 

Seems weird in the fact that Windows actually does (somewhat?)load and execute rather than going off to neverland during the boot.
I setup my new HDs using the XP install CD to partition and format the new drive (for confidence, not because you have to) before restoring an image of my C drive. I kill the setup process when it wants to start copying files and it works just fine. This would seem to rule out a partition signature problem.

 

Thanks Brian,

I think I will explore the corrupt registry possibility, but I am concerned that Acronis support have told me that this procedure just won't work, because Windows XP does not allow you to restore the "partition contents" to another partition, even if that partition satisfies the usual requrements for a bootable partition. I would have thought that many if not most people would expect to be able to use TI backups in this way. I have queried this with them, but am still awaiting a response.

Pete K

 

Hmm, I'll have to think about that. I might try the windows recovery console, but first, I want to peek into the MBR and see just what changes when I copy the complete partition (rather than its contents) using Disk Director. I know that a partition copy does work, but since a backup/restore of the partition CONTENTS should produce identical results so far as the DATA in the partition is concerned, I'm intrigued to know just what is preventing me from doing a successful backup/restore. The most obvious explanations are :

1. The backup or restore corrupts something in the process.

2. Windows does indeed (as Acronis said) check the partition record to make sure that it matches the partition contents. What concerns me most about this case is that it imples that you cannot recover from a TI backup to a new HD without some additional (unknown) steps. In your case, you used the Windows CD to create a new MBR, so maybe that is one option. I'd just like to understand why.

Thanks for your help.

Pete K

 

Pete, I'm not sure what Acronis are discussing.

You just need a "new" HD, partitioned or unpartitioned. Restore your image and it should boot. You actually did this. Windows booted but it didn't "work". Sounds corrupted to me.

You don't need a special MBR. TI creates a MBR if there isn't one already on the HD. Your problem is unique and I'd send this thread to Acronis.

You mentioned that you have Ghost 9. Does this work in the above situation?

 

Brian,

I've given up the ghost (sorry) with GHOST. It ate too much resources, even when idle, I had to resort to disabling its windows services until I wanted to use it for a backup. Ghost did enable me to clone an entire partition. This is something that TI can't do, but Disk Director can. When I clone the partition using DD it works and I can boot from the new partition. Having read the TI documentation a dozen times, I believe that a partion backup/restore should also work (this is my problem). If I could get this to work, it would be more convenient than working with partitions directly, and as a consequence I'd take more backups. As it stands, DD does the job and TI doesn't.

My inital conclusion was the same as yours, but I was gobsmacked when Acronis Support said "no, you can't do that". I have asked Acronis to expand upon their reply and I'll report back here.

Meanwhile, I'll play around with a few suggestions I've picked up here.

Cheers,

Pete K

 

Pete, your procedure is absolutely what I have done very often. As your windows is booting your MBR is also ok.

Is your windows configured to use only c: ? It sounds as if your OS stops while searching any resource(s) otherwise.

aggronix.

 

Billy, have you tried a Repair Install of Windows? You have to choose the correct Repair option though as there are several that come up in a Windows Install. The one you want is the one that appears right after you agree to the EULA. So ignore any screens that have Recovery or Repair options until after the EULA screen.

Another thought, have you run chkdsk /r on that "new" drive?

 

Good question. I'm 99% sure, that the answer is "yes". All of the boot stuff and Windows stuff and programs are on the C: drive. At one time I did run with the swap file on another partition, but I THINK that I moved it back. I will need to check, but I'm at work at the moment, so I can't do that until this evening. I'm wondering now whether the drive letter was changed somewhere along the line. Again, I'll have to check.

Thanks for the comments.

 

No, I haven't tried that yet. I suspect that this may well work, but I want to find out what I did that was wrong (or at least save off some info to help work it out afterwoods) before I unleash the might of Windows Repair on the drive.

Thanks, Ralphie.

 

Before trying some of the suggestions relating to the use of various Windows repair cababilities, I thought I would try the whole process again, but this time I would use the Recovery CD to create the initial backup, rather than running the backup under Windows. At least this should eliminate any question of corruption due to open files etc.

Guess what ? It didn't work.

I have also had another response from Acronis, who are being rather coy about the issue to say the least. They said that YES, YOU CAN restore to a different HD, and pointed out that I had done so. They went on to say that any problems that I was having were due to the OS. Well, this is great news. I hope that all of you people who rely up TI backups do practice the restore process regularly, because you might be in for a surprise.

So, what do I think is going on here ? My guess is that Windows XP puts some identifier in the partition record iteself (or somewhere else on the HD) and since TI backups do not include the partition record itself (just the data) you are forced to either recover the MBR or timage the whole drive (which includes the MBR). Alternatively, you can try your luck with the Windows recovery console etc. However, do not expect to be able to recover your failed HD from a TI backup alone.

I hope that Acronis will finally come clean about this issue, but as it stands, I can't find a use for TrueImage. What I will do, is to try out the suggestions that I have received and report back to you.

Thanks again to all who contributed, your comments really have been very helpful to me.

Pete K

 

From TI9 onward, an image of the active partition, typically C, also images the MBR which can be restored later. Apparently, the number of partitions (not the sizes) must match the number of partitions on the disk the MBR was taken from.

 

ENLIGHTENMENT !

The last response I received from Acronis has enlightened me - well partially.

Firstly, if you want (need!) to restore a Windows XP boot partition backup to another drive, you must backup the WHOLE drive, not just the boot partition. Alternatively, if you do just restore the boot partition (as I did), you must carry out some additional (unspecified) steps. Ignore this at your peril !

Note that if you are lucky enough to have the original drive, you should be able to restore just the boot partition and even if that fails, you can always restore the MBR providing your partitioning hasn't changed since you did the dump.

I hope to pursue those "unspecified steps" to try to find the easiest detour to this limitation. If I do, I will pulish the results on this forum.

Thanks again to all who helped me.

Pete K

 

Interesting ! Thanks for that.

Pete K

 

Pete,

I had what sounds like the same problem you're having and a TI image restore wasn't even involved in creating the problem.

This is what I did that caused the problem: I wanted to test a senario to help someone else who was trying to install WinME on a small partition at the end of a 160GB HD. Before starting I created a complete disk backup with TI. Then I used DDS to resize the partition smaller and created an 11GB FAT32 partiton at the end. Windows would still boot and run okay at this point. After messing around with WinME, I deleted the FAT32 partition and resized the XP partition to the whole disk.

This is where it gets weird. I'm not sure if DDS didn't resize it back exactly to where it had been or what. Anyway, upon booting into Windows, it got to the desktop and then just sat there. I could move the mouse and some thing seemed to "sort-of" work, but the system wasn't responsive. It was really, really slow.

I assumed this was casued the by partition resize (since nothing else had been done) and since I had created a TI image prior, I just restored it as that was faster than trying to figure out what was screwed up.

You say the partition you're restoring to is exactly the same size as the original. Have you tried resizing during the restore to make the partition a little smaller or a little larger?

XP seems to be very picky about partition beginning and ending points, and I think that's what happened in my case.

 

Mud,

No, I haven't tried resizing the partitions. I think that there are at few factors in play here, thought I don't pretend ti understand them fully. I have read that XP uses information in the MBR (the drive signature) in some way. It also uses the drive letter to index into the registry. Finally (for now), I think it uses some stuff at the end of the MBR to support its antipiracy measures. I'm really not clear as to which of these factors is making life difficult for me at the moment, but I suspect the latter.

Originally, I thought that the problem was simpler: TI was unable to clone my boot drive properly. The reason I thought that was that I have been doing this sort of thing for years now, using other products and it always worked. I no longer think that TI is to blame; that the problem is to do with the way MS use the MBR. I do think that Acronis should document this issue so that people don't waste hours and hours trying to achieve something that just isn't going to work. I've read and re-read the user's guide several times and although it does not explicitly state that you CAN do what I tried, it certainly gives the impression that you can. That said, it isn't Acronis that is causing the problems.

Now that I understand a bit of the picture I can try to find a detour.
My first plan was to use DDS to fix-up the MBR, using the edit disk feature, but after a while I realised that DDS won't allow you to mess around with the MBR, just the partition data. Shame.

An alternative approach, is to configure all my HDs (off-line ones too) with the same number of partitions and restore the the MBR when I restore the boot partition. I'm not convinced that this won't trash the other existing partitions on the target ("new") HD, but I'll give it a go and see. Even if it does, at least that gives me a way to get up and running after a HD failure. I can always restore the other partitions afterwards if necessary.

I don't know if the scenario that you described has the same cause as mine, though the symptoms sound similar, but I do think that this whole area is far more difficult that it ought to be. Surely we should expect to be able to backup Boot and data partitions in a safe and robust way, without faulling foul of poorly-documented OS "features" and copy-protection mechanisms.


Cheers,

Pete K

 

I don't think Windows copy protections have anything to do with it; more like making sure Windows is running in a valid environment for its linkages. Normally changing a HD by itself does not trigger a reactivation request.

 

You might be right. I obviously undertand this even less than I thought.

I just tried the recovery again - for the fourth time - but this time, after choosing to restore the boot partition (to the same location as the first three attempts, i.e. a not the source HD), I then chose to restore thye MBR. To my surprise, not only did this restore the boot partition (in working order), but it left the other two partitions on the target disk unsullied.

To recap, these are the significant steps:

1. Orig HD (HD-old) has five partitions.
2. Using recovery CD, backup partition C: from old to a second HD (HD-2).
3. Remove HD-Old and replace it with HD-new. HD-new has three partitions, the first of which is identical in size to the boot partition on HD-old.
4. Using the recovery CD, Restore from the backup on HD-2:
- First recover HD-old-C to HD-new-C.
- Say "Yes" to "Do you want to recover more partitions ?".
- Choose to recover HD-old-MBR to HN-new-C.
5. 14 minutes later, the process completed normally, the system rebooted to HD-new-C, and the original partitions 2 and 3 on HD-new were still intact.
6. Fall off chair.

OK, I omitted step 2.3: faff around for a week or so, but it all works and my confidence in TI has been restored (not to mention my HD).

Brill !

Thanks for all who helped. I don't think I would have tried this last successful attempt if it wasn't for your help. beer tokens all round.

Pete K

 

Congratulations! Glad you persevered and got it working. We are all a bit wiser for the experience.

 

Your old HD, the Volume Label, did you leave it with the HD serial-ID which is default?

Hint - give volume labels that are consistently the same, example my C: volume label is "System" every HD I've always had. My D: = "Applications" (on Disk 0, partitioned C: & D; E: = "Games1", F: = "Games2" (Disk 1, partitioned), etc.