Problem restoring Image

I am trying to restore an image that I know is good to a drive that is quite bit smaller for a test I need to run. The image is quite a bit smaller than the destination drive but ATI identifies the original image as coming from a partition that is much larger. Anyway, that shouldn't be an issue since I know for certain that the image is 1/3 the size of the destination drive.

At the completion of the restore, the destination drive begins to boot normally but after the windows opening screen, the boot process freezes.

I am restoring from the ATI boot CD with destination drive connected as the main boot device. XP PRO

Please give me some insight as to what I can try to make this work.


Thanks a bunch..

 

Sleepless,

Success depends on the extent of data spread in the source partition.

How large is the source partition that you imaged?
How much data is in that partition?
Was the partition defragged before the image was taken?
How large is the target partition?

 

Brian,

The windows reported size of the partition is 36 Gb which is about the same size of the total of the three part image. The drive from which the image was made was not defragmented before the last part of the image. I see your point, or at least I think I do. If some of the files are spread beyond the contiguous sections up to 35 to 36 Gb, then ATI would try to write them in the same location on the new drive but that space does not exist. Is that what you are thinking?

I just felt that ATI would take care of this and place these files inside the space of the smaller drive even though it is smaller than the original drive, the new drive is still so much larger than the image.

The target partition is 298 Gb. The original image was taken from a drive that contained two partitions the first of which being the main boot partition which is 488 Gb.

Please let me know if this confirms your thoughts or input for a fix.

Again, thanks so much!!

 

Sleepless,

http://www.goodells.net/multiboot/notes.htm#15

See "Why won't 5GB of data clone to a 10GB partition?" I know you are imaging and not cloning but the data spread concept applies.

If you want it to work easily, resize your source partitions smaller before creating the images.

 

Thanks Brian.

It seems that the data spread is the issue. I am surprised that this has not been encountered more frequently by other users. This is a really big issue,

I my case, I move to larger drives that to now partition smaller would be a bit going backwards--sorta. I did notice on the fragment report that there was still files residing quite far from the main file grouping and they are not unmovable files either. Why in the world would the defrag program leave these so far beyond a tighter grouping?

 

Defragging doesn't always work and those unmovable files are the problem. If you are familiar with partitioning software you can easily resize down, take the image and then resize up. That image will restore to an equal size or larger partition.

 

I have paragon 9. Can I do this without affecting the system image in resizing the partition to fit the smaller drive?

 

I'm not sure I understand your question.

I only image system partitions. I use simple data backups for data partitions. I was proposing shrinking the system partition to a size to match the partition on the new HD. Image this shrunk partition and then return this partition to its original size. The image just created can be kept as a backup for the first and the second HD OS partition.

 

see this post below, more than likely that's your problem.

When backing up and restoring, as long as the "use space" of your image backup fits on your new drive, it should work everytime.

For instance if your image backup is 488gb partition and it only has 100gb of use data. That image can be restored on a 110gb partition and quite easily in a 298gb partition. True image only restores the "use data" it doesn't restore empty space. I always restore larger partitions to smaller partitions with no problems.

Since your restored drive starts to bootup, it means you did most of it correct, you just need to check your drive letters an easy fix.

xp hangs during bootup
https://www.wilderssecurity.com/showthread.php?t=210322

 

Exactly, my reply was poorly worded. I meant to say that if I change the size of the partition in paragon would that allow me to do this without loosing data and make the new image one that would be more transportable to slightly smaller drives.

After a successful resizing of the partition, I am hopeful that I can boot back to windows without loosing anything then re image the new partition.

This is something I have never done before for obvious reasons but I will give it a shot to see if it works. I wonder how the partitioning tool will handle the files that were separated on the larger partition after it is resized so that I can still boot.

 

jonyjoe81,

That is not correct unless the data was compacted to within the first 110 GB of the partition prior to the image being created. Possible, but unlikely in actual practice.

 

Sleepless,

You already have an image of that partition so it takes some of the worry out of resizing. The OS will still boot after the resizing. Keep us informed.

After you confirm that the old OS boots after the resize, delete the empty target partition from the second HD before creating your image of the old HD OS. Then re-create the partition on the second HD. Boot from the TI CD and restore the image to the second HD. Remove the old HD from the computer before the first boot from the new HD.

 

Brian,

Thanks for hanging in there with me on this one. Here is the latest:

I used Paragon 9 to reduce the original partiton of the boot drive to "fit" all the data on the drive into a smaller space since that drive was only 15% full.

That worked and left me with a resized partiton on the working boot drive that is 5% larger than the target drive. I defragged the working drive after the resize to make sure that the data was indeed not spread to the far end of the drive. That looked normal. Then I made a new image of this partition.

I attempted to restore that image to the single partition of the target drive that I have been using through all of these experiments and it failed again at the same place--at the splash screen.

I noticed that you mentioned "compressing" the data to fit contiguously in one block. How is this done as I have not attempted that.

While I have successfully resized the partition that I wish to keep for smaller drives, and made an image of that partition, it still will not allow a boot into Windows when the target drive is connected as the boot drive. The main drive that was resized is not connected in the sytem when the reboot takes place to avoid drive letter assignment issues.

Attached is a screen shot showing the fragmentation visually from XP's disk manger after the partition was resized.

 

Like you I have been under the impression for some time that TI would be able to squeeze the larger image down into the smaller partition, as long as the target partition is large enough to hold the actual used data volume on the image. But I've never actually tried to do it, so I'm interested in the outcome of this thread.

If I understand you, the partition shown in the screenshot is only 5% larger than your target partition, so it would seem those few files to the right are still within the address range of the target partition.

Could you try to further reduce the source partition size so those files out to the right on your screenshot would be outside of the new partition size, forcing the partitioning tool to relocate those files? Not sure why it would be any better, but might be worth a try.

 

Sleepless,

Looks good but did you do this?

You must not let the OS on the old HD see the target partition before the image is created. Seeing unallocated space as the target is fine or never having seen the target HD at all is fine. Letting the old OS see the target partition prior to image creation is not fine.

 

Everytime I have restored a larger partition into a smaller partition it has worked. Usually I restore a 50gb partition into a 20gb partition (without defragging), true image only cares about the "use data" when restoring. If there isn't enough space to do it, you will get a warning and you won't be allowed to proceed with the restoration. I've done this enough times that it is a "law of physics" that it will work everytime.

In this situation sleepless has been successfully restoring the hard drive with no warnings. It's when he tries to boot the restored drive that windows xp hangs at the splashscreen. It's a problem I have seen numerous times, but not related to partition size or defragging.

More than likely the source windows xp has previously been exposed to the "hard drive" that it was going to be restored on. Windows xp remembers hard drives ID's and logs them in the registry. When windows xp is restored and hard drive ID's don't match up, you get windows hanging at the splashcreen. This problem can be fixed in 5 minutes with a bartpe and the proper plugin.

 

It turns out that what actually fixed this issue--I am using the newly imaged drive now, are the tips from another savy user, jonyjoe81.

His suggestion that described the classical problem of a new image hanging at the windows splash screen is right on the money. While I have never owned Bartpe,(the software he references) I have Paragon 9 which can produce a bootable CD necessary for these repairs.

With the original HD, from which the image was made, REMOVE from the system and only newly imaged disk connected as the boot disk, I used the boot corrector routine of the Paragon 9 emergency CD to FIRST find the OS on the disk (even though it was not booting, it was there) then allowed the program to reveal the assigned drive letter. The drive was assigned F and not C. This was assigned by the registry and is part of the problem for hanging at the splash screen. Then from the drive mapping tab, I saw that the drive was NOT mounted to the OS and was showing up as unassigned, the other problem jonyjoe81 describes.

I then fixed the drive letter and check the mapping to see if the drive was mapped/assigned properly, then rebooted--it worked.

For anyone new to this, and I am no pro by any means, the particular drive utility that one may use handles or describes these fixable issue in differnt ways but regardless of the software, the mapping of the drive to the OS and the proper drive letter assignment (C) must be checked and fixed if necessary.

In my case, possibly the initial partition size being >400Gb (with data only using about 50 Gb) any files that are not contiguous and that may lie beyond the size of the new smaller disk partition (298Gb, in my case) could indeed have been an isssue once in Windows, maybe not booting, but we'll never know on this for sure. The fact remains that to avoid this, the suggestion made by Brian K to first defrag the drive BEFORE imaging to be sure that all files are at least within the size of the new partition on which the image is to be placed is a good suggestion.


Again, as previously reported by jonyjoe81, the newly imaged drive has to be correctly assigned and mapped to the OS which unfortunately is not a rare occurence after imaging with ATI, THE NEW DRIVE IMAGE WILL HANG as exactly as desicribed.

Thanks to jonyjoe81 and Brian K for all the input and assitance and hopefuly this experience will assist others.

 

This thread has been most helpful to me in understanding a similar problem (creating a new C-drive with O/S from an old C-Drive with O/S). Thanks to dwalby for directing me to this thread. Many thanks to all who posted on this thread!

 

Could someone give us the version of Bartpe used and the particular option used to accomplish what seems like a good thing?
Thanks
Harold

 

follow-up question

So now that I've seen it explained in action, the cause of the problem makes sense to me, but I've still got one question about the boot sequence.

Once the OS image is restored to the target partition, I assume that partition is also marked as 'active' during the restore. I'm also assuming the original hard drive with the original OS has been removed from the system at this point as well. So only one copy of the OS is visible during the boot sequence.

If that is the case, won't the boot sequence normally assign C: to the partition it finds marked as active? I thought that was how it worked, but I really don't have much experience with this at all (that's why I lurk on this forum, I learn a lot here).

It appears from the discussion that the fact that the target partition was seen previously by the original OS, and assigned the letter F:, that it will not re-assign it to C:, thus the boot problem encountered.

So it appears that the way the boot process works is not how I originally thought, but just slightly different. If the OS has never seen the partition before, thus never assigned it a drive letter, and it is marked as active, then the boot sequence will assign it to C: and proceed booting the OS from that partition. Did I state that correctly?? Or does it work some other way entirely??

The part that surprises me is with all the multiple disk setups being used by the members of this forum that this issue isn't reported more frequently. A lot of people move the OS from one disk to another, I did it myself. But I restored it to a new disk from an external HD, so my target partition was never seen by the OS prior to the restore and that's why I never saw this issue myself.

 

Doug:

That's pretty much the idea. When Windows boots it will start scanning the attached disks and partitions to find any that are formatted with a supported file system (NTFS, FAT). From the disk ID and the starting sector of each partition, Windows creates a partition ID, a 12-byte binary number.

Each of these partition ID numbers is then checked against the registry key HKLM\System\MountedDevices to see if the partition has a "reservation" for a particular drive letter. If one is found, it is kept and the process moves on to the next partition. If there is no reservation for one of the partition IDs, Windows assigns the partition a new drive letter and stores this assignment in the registry. Here is an example of four partitions from my disk as seen by regedit:



You can see from this picture that all four partitions are on the same disk because the Disk ID (the first 4 bytes) is the same for each. Two times the starting sector of the partition is coded in the next 8 bytes. To decode, "7e" for the C: drive is (7x16+14)/2 = 63, so this partition starts at sector 63 on the disk.

The problem described here originates in the partition being imaged. When you create an image of a Windows partition it will include the registry information in the image. If that registry contains an entry with a drive letter reservation for the target partition that you are going to restore to, then when you boot Windows from the newly-restored partition there will already be a reservation in the registry for that partition for some other drive letter (F: in your example). That is not the desired outcome since the original Windows system that the image was created from probably had C: for the system partition. So even though you restore to the active partition on a new drive that does not guarantee that you will get the C: drive letter if the registry has stored some other letter for your new partition. The solution is to make sure that there is no drive letter reservation for the intended target partition when you create the image file.

In the words of Dan Goodell,

This can be accomplished in several ways; for example by deleting the target partition first, creating the image file second, then restoring the image file to uncommitted free space instead of to a partition.