Fun with different disk sizes

[BrickMaster]

Guys,

I work for a company that is a long time user of image for windows across 1000's of installations. It has been a excellent tool for us.

We are moving from v1.6x to 2.6x and for the most part, it has been great but we have run into an unusual situation.

If we take an image of a partition on a machine that has a small drive (100 gb) with (say) 7 gb used, and try to restore it on a larger drive (say 250gb), the world is a happy place - scale to fit works well.
If we take an image of a partition on the big drive with same 7 gb used (140 gb partition) and try and restore it on the smaller drive partition (say 45gb) it refuses saying that the minimum MIB is 71450 and that the partition isn't big enough. The drive seems to have to be a given size, say twice that of the smaller one to make the issue happen.

We are doing some extra testing to try and drag a little more information out of this, but it does seem to be a change in behavior from the older IFW 1.6x versions that we know and love.

We use it on machines of varying drive sizes and sometimes this becomes an issue for us. Any thoughts?

Thanks for a great product!

[Retrospek]

I just ran into this as well, originally using Image for DOS. So I loaded up my version of Image for Windows (2.62a) to see if it provided more information, and it did. I took a screenshot to show the problem, as outlined by the program:





The original drive is 320GB, the new drive is 90GB (trying to move to an SSD drive from a standard, much slower SATA drive).

Windows information on the drives:

Original (Source) : 298.08GB Total Size / 251.90GB Free Space (46.1GB Used, MUCH smaller than the 90GB of the new drive)
New Drive (Destination) : 83.84GB / 83.78GB Free Space (Standard space taking by just a simple partition setup)

If it matters, the OS is Windows XP (32 bit). I've tried using copy in Image for DOS, no luck. I've tried using copy in Image for Windows, no luck. I've tried making a backup, and then restoring, no luck.

For some reason, the copy and restore size needed FAR exceeds what is actually needed for the data to be saved. I even deleted a bunch of stuff of the original drive and tried again, and the restore size needed did not reduce at all.

Thanks for any help on this, I love this program, and this is the first serious problem I've run into that I can't seem to get around somehow, someway. Thanks.

[TAC109]

If you read Appendix C of the IF[D/W/L] manuals, the reason is
described there.

Basically, there has to be enough room to restore the last actual
block of the image.

If you're anticipating restoring an image to a smaller partition or
space, defrag the disk before you image it.

On Tue, 6 Sep 2011 18:21:51 PDT, Retrospek wrote:

>I just ran into this as well, originally using Image for DOS. So I loaded up my version of Image for Windows (2.62a) to see if it provided more information, and it did. I took a screenshot to show the problem, as outlined by the program:
>
>[img:2isph36w]http://www.clepstone.com/Drive_Size_Issue.png[/img:2isph36w]
>
>[img:2isph36w]http://www.clepstone.com/Drive_Size_Issue2.png[/img:2isph36w]
>
> The original drive is 320GB, the new drive is 90GB (trying to move to an SSD drive from a standard, much slower SATA drive).
>
> Windows information on the drives:
>
> Original (Source) : 298.08GB Total Size / 251.90GB Free Space (46.1GB Used, MUCH smaller than the 90GB of the new drive)
> New Drive (Destination) : 83.84GB / 83.78GB Free Space (Standard space taking by just a simple partition setup)
>
> If it matters, the OS is Windows XP (32 bit). I've tried using copy in Image for DOS, no luck. I've tried using copy in Image for Windows, no luck. I've tried making a backup, and then restoring, no luck.
>
> For some reason, the copy and restore size needed FAR exceeds what is actually needed for the data to be saved. I even deleted a bunch of stuff of the original drive and tried again, and the restore size needed did not reduce at all.
>
> Thanks for any help on this, I love this program, and this is the first serious problem I've run into that I can't seem to get around somehow, someway. Thanks.

[jaybird]

I had a thought on this too. It might not be right but then again it might.
If the filesystem is NTFS there's a structure called the Master File Table
or MFT. I'm pretty sure the MFT is normally stored somewhere in the middle
of the partition, and sometimes Windows likes to store files around the MFT.
So if you had a 500GB partition with just 20GB used, it could well be that
the last block of actual data was right or around the 250GB area of the
disk, thus the destination partition must be at least that large in order to
restore.

The only workaround I can think of is a bit geeky, and involves Image for
Linux. Here goes.

1. Defrag the partition with something like JKDefrag which can store all the
files at the beginning of the partition that will fit, only jumping over the
MFT when necessary.

2. Image this freshly defraged partition. This is *not* the backup you will
eventually restore, but it's a backup in case the next step fails horribly.

3. Boot into IFL and use the included ntfsresize program to resize the
applicable NTFS partition to the size of the eventual target partition for
the restore. This will move data around to accomplish this, and if the power
fails or the program crashes, you're probably gonna be very sorry if you
didn't image as in step 2 above.

4. Image the newly resized partition, preferably to a different filename.

5. Restore this image to the target partition.

Jayson

"Tom Cole" wrote in message
news:241@public.image...
> If you read Appendix C of the IF[D/W/L] manuals, the reason is
> described there.
>
> Basically, there has to be enough room to restore the last actual
> block of the image.
>
> If you're anticipating restoring an image to a smaller partition or
> space, defrag the disk before you image it.
>
> On Tue, 6 Sep 2011 18:21:51 PDT, Retrospek wrote:
>
>>I just ran into this as well, originally using Image for DOS. So I loaded
>>up my version of Image for Windows (2.62a) to see if it provided more
>>information, and it did. I took a screenshot to show the problem, as
>>outlined by the program:
>>
>>[img:2isph36w]http://www.clepstone.com/Drive_Size_Issue.png[/img:2isph36w]
>>
>>[img:2isph36w]http://www.clepstone.com/Drive_Size_Issue2.png[/img:2isph36w]
>>
>> The original drive is 320GB, the new drive is 90GB (trying to move to an
>> SSD drive from a standard, much slower SATA drive).
>>
>> Windows information on the drives:
>>
>> Original (Source) : 298.08GB Total Size / 251.90GB Free Space (46.1GB
>> Used, MUCH smaller than the 90GB of the new drive)
>> New Drive (Destination) : 83.84GB / 83.78GB Free Space (Standard space
>> taking by just a simple partition setup)
>>
>> If it matters, the OS is Windows XP (32 bit). I've tried using copy in
>> Image for DOS, no luck. I've tried using copy in Image for Windows, no
>> luck. I've tried making a backup, and then restoring, no luck.
>>
>> For some reason, the copy and restore size needed FAR exceeds what is
>> actually needed for the data to be saved. I even deleted a bunch of
>> stuff of the original drive and tried again, and the restore size needed
>> did not reduce at all.
>>
>> Thanks for any help on this, I love this program, and this is the first
>> serious problem I've run into that I can't seem to get around somehow,
>> someway. Thanks.
>

[Brian K]

BrickMaster,

You can use the Compact option prior to backup to get around this issue.

[TAC109]

If you defrag using MyDefrag (the successor to JkDefrag) in step 1,
you don't need to go past step 2. MyDefrag can move the MFT, and has
a scripting language, so you can put the MFT wherever you like.

On Tue, 6 Sep 2011 20:15:31 PDT, "Jayson Smith"
wrote:

>I had a thought on this too. It might not be right but then again it might.
>If the filesystem is NTFS there's a structure called the Master File Table
>or MFT. I'm pretty sure the MFT is normally stored somewhere in the middle
>of the partition, and sometimes Windows likes to store files around the MFT.
>So if you had a 500GB partition with just 20GB used, it could well be that
>the last block of actual data was right or around the 250GB area of the
>disk, thus the destination partition must be at least that large in order to
>restore.
>
>The only workaround I can think of is a bit geeky, and involves Image for
>Linux. Here goes.
>
>1. Defrag the partition with something like JKDefrag which can store all the
>files at the beginning of the partition that will fit, only jumping over the
>MFT when necessary.
>
>2. Image this freshly defraged partition. This is *not* the backup you will
>eventually restore, but it's a backup in case the next step fails horribly.
>
>3. Boot into IFL and use the included ntfsresize program to resize the
>applicable NTFS partition to the size of the eventual target partition for
>the restore. This will move data around to accomplish this, and if the power
>fails or the program crashes, you're probably gonna be very sorry if you
>didn't image as in step 2 above.
>
>4. Image the newly resized partition, preferably to a different filename.
>
>5. Restore this image to the target partition.
>
>Jayson
>
>"Tom Cole" wrote in message
>news:241@public.image...
>> If you read Appendix C of the IF[D/W/L] manuals, the reason is
>> described there.
>>
>> Basically, there has to be enough room to restore the last actual
>> block of the image.
>>
>> If you're anticipating restoring an image to a smaller partition or
>> space, defrag the disk before you image it.
>>
>> On Tue, 6 Sep 2011 18:21:51 PDT, Retrospek wrote:
>>
>>>I just ran into this as well, originally using Image for DOS. So I loaded
>>>up my version of Image for Windows (2.62a) to see if it provided more
>>>information, and it did. I took a screenshot to show the problem, as
>>>outlined by the program:
>>>
>>>[img:2isph36w]http://www.clepstone.com/Drive_Size_Issue.png[/img:2isph36w]
>>>
>>>[img:2isph36w]http://www.clepstone.com/Drive_Size_Issue2.png[/img:2isph36w]
>>>
>>> The original drive is 320GB, the new drive is 90GB (trying to move to an
>>> SSD drive from a standard, much slower SATA drive).
>>>
>>> Windows information on the drives:
>>>
>>> Original (Source) : 298.08GB Total Size / 251.90GB Free Space (46.1GB
>>> Used, MUCH smaller than the 90GB of the new drive)
>>> New Drive (Destination) : 83.84GB / 83.78GB Free Space (Standard space
>>> taking by just a simple partition setup)
>>>
>>> If it matters, the OS is Windows XP (32 bit). I've tried using copy in
>>> Image for DOS, no luck. I've tried using copy in Image for Windows, no
>>> luck. I've tried making a backup, and then restoring, no luck.
>>>
>>> For some reason, the copy and restore size needed FAR exceeds what is
>>> actually needed for the data to be saved. I even deleted a bunch of
>>> stuff of the original drive and tried again, and the restore size needed
>>> did not reduce at all.
>>>
>>> Thanks for any help on this, I love this program, and this is the first
>>> serious problem I've run into that I can't seem to get around somehow,
>>> someway. Thanks.
>>
>
>

[TeraByte Support]

You can use the "compact" option to reduce the restore requirements (as
shown when you use the "information" button or "F1 Details"). Some
defraggers won't move some of the data and you'll need to compact anyway.

[Retrospek]

Well, sadly, I was in a bit of hurry to get the data copied over earlier, and found a solution, I resized the partition. This of course, forced the data to be moved under the 90GB range, and fixed the problem.

I can definitely see where the defrag would have accomplished the same results now. Provided I have some time tomorrow, I'll restore from my last backup, and give that a shot, and post the results.

Thanks for the quick responses from everyone, again, I cannot brag about this program enough.

[Brian K]

I can definitely see where the defrag would have accomplished the same results now.

Maybe. There are files that aren't moved in a standard defrag. Pagefile, hibernation file, MFT. These can be moved in a boot time defrag but you don't have any control over where they go. Resizing (or Compact) is the best option.

[DrTeeth]

On Tue, 6 Sep 2011 23:16:53 PDT, just as I was about to take a herb,
Brian K disturbed my reverie and wrote:

>Resizing (or Compact) is the best option.

Sounds such a useful option, the question arises "is there a downside
to having it permanently enabled?"
--

Cheers

DrT
______________________________
We may not be able to prevent the stormy times in
our lives; but we can always choose to dance
in the puddles (Jewish proverb).