Richard,

It has been some time since I've used version 6.5, but I do recall testing resizing scenarios in lab setups with sucess.  I believe I used a bootable disk with the GHOST utility GDISK, to create the partitions first.  I would always have GDISK quick format the system partition and mark it as bootable (Active).  The second partition was not formated because GDISK was formating in FAT32, and thus the limitations of that file system came into play.  The LiveState recovery process would overwrite and format the sytem partiton to NTFS.  I don't remember if it would write data to the empty data partition, but the worst case scenario was that the newly recovered system could format the partiton at next boot.  Data could then be recovered afterward.

If you need to free up some space in order to backup, I have a suggestion.  You could use junction points with the second drive you were intending to install anyway.  Junction Points are supported in Widows 2000 and above.  Essentially, you create a data folder on the new drive and move the data in the old data folder to the new one.  Then you create a junction point between the old empty folder and the newly populated folder.  As far as the OS is concerned, the data still resides where it always did.  There are some drawbacks, but there is a nice little article here that outlines the pros and cons.

http://www.shell-shocked.org/article.php?id=284

Download links to the utilities mention in the article are at the bottom of the page.  I personally use Junction Link Magic, despite its annoying tendency to scan for junction points every time the program starts.

Now for my standard disclaimer......test this in a lab setup before going live with it.  Yes, you may have programs linked to the serial number of the drive, but at least you can gain some confidence on the resizing scenario.  Hopefully the programs are detecting the hardware serial number and not the volume serial number created when the partition was formatted.

Best of Luck

Marco

I only have Backup Exec System Restore 6.5x, I don't have GHOST

one problem I ran into with the "Junction Point"
(which is the NT version of the old DOS Join command)
is repeated backup failures, which would always come back with "cannot find data at offset ????????, ????????..." and would result in a corrupted v2i file, and failed backup.

my main concern with the backup and reason I purchased it, is to backup only the OS & Programs, I have a specific solution for my "User Data"

the extra drive I will be installing is for temporary use only to remove the user data from the C: drive because both my 500GB D: and E: are already full of user data, so I will be removing one of them temporarily and installing an empty new drive and moving all the user data off of C: it's at this point I would like to take an image and restore after shrinking the partion to 30 - 40GB,

The programs that I have read the actual HDD hardware serial number, and  the restore when I tested it before gave the same volume serial number back to the new disk, but I wasn't trying to change the volume size.

I know the check box for expand to fill unused space is available for restoring to larger drives,
I may do some experimentation with an old recovery point to restore to smaller empty unformatted partitions to see if a restore is possible before I completely bomb the current C:
 

Thanks for the reply.  I think I see your situation more clearly now.  Unfortunately, not all backup solutions can handle junction points properly, thus the source of the errors.  Cold imaging the drive would probably alleviate that issue, but version 6.5 can't do that.

A free alternative for partitioning would be SwissKnife:

http://www.compuapps.com/download/Swissknife/swiss...

It has to be run from a disk other than the drive to be partitioned.  Examples being the hard drive of another computer with the target drive attached, or a BartPE disk.  The BartPE version has the safety lock disabled which prevents accidently deleting data on a drive with an OS installed.  Not a concern for you since you will have a image of the drive.  I use Benjamin Burrows adaptation of BartPE,  (UBCD for Windows) and it comes with SwissKnife in the distro.  If you have a NFR copy of Windows XP, this is worth the effort to build.:

http://ubcd4win.com/

Hopefully your testing will go well, and you'll have a solid plan for proceding.  In the worst case scenario, you can always use the recovery image to get back to the one partition state.  If in your shoes, I would get two images of the partition  to be resized, just in case one goes bad.   

I confirmed that what you wish to do is possible.  I tested it with version 6.0, but the recovery environment is the same as version 6.5.  I could not get SwissKnife to work with my current build of UBCD for Windows, so I used Disk Management from the CD to delete the partition and create the smaller partition.  I did not create any other partitions at this point.  I also skipped formatting the new partition.  After booting into the version 6.0 recovery environment, I was able to sucesfully restore to the new empty partition and have it boot.  For recovery options I used, Set Drive Active, Restore MBR, and Restore original disk signature.  After booting to the restored system, I used Disk Management from the restored system to create and format a data partition.

Whatever you use to create the smaller partition, it won't be necessary to format it.  The recovery process will take care of that for you.  Near the end of the process, there is a point were it is moving data from an unused area and takes a while to do so.  I'm guessing this is how the process resolves the difference in partition sizes.

Thanks for the info,
I will be doing a few tests of my own in the near future involving the same,
since HDD's are sooo cheap in price/GB I will get a couple and do some testing while my original C: sits in the tray disconnected and w/o power,
if I can "restore down" I'll return and supply the info.

Cheers

I had to do it sooner than planned because of a failed program install
so I did it the partition bomb way;

for a new or used disk:
» start a fresh XP install and if necessary, remove any existing partition(s)
» create the new desired partition size, with enough free space for the restore (in my case a 40GB partition to restore 13GB)
» quit the install without formatting the new partition or partitioning the remainder of the disk
» remove the XP disk and insert the BESR SRD and allow the system to boot from it
» select restore/recover my computer
» locate the new partition and the backup image and begin the restore
» select:  Set Drive Active, Restore MBR, and Restore original disk signature.
» I also selected  "verify image" so I wasn't restoring from a possibly damaged/corrupt backup image

there was one wierd thing that happened though and that was a new hardware found popup and had to restart
even though there was no new hardware added during or in between image and the restore, I took the backup before
attempting the program install, and I used the same HDD I didn't change it out I only resized the partition, and I couldn't
find any "New Hardware" in the device manager before or after the restart.

Just sitting a bit easier now that  I know that I can dump just about any size disk in and do a restore so long as there's enough room for the existing data.

Cheers

The new hardware added prompt is quite common when resizing partitons, even on the original hardware.  I think it is a way for the OS to resolve the change in partition sizes on the logical drives.

There is a limit to how small you can resize the partitions.  A Symantec employee posted the formula once in this forum, but I'll be darned if I can find the post again.  Anyway, I think you need around 1.6  times the used space of the old drive/partition  in order for the restore process to complete without throwing an insufficient drive space error.

The approximate calculation for the minimum disk size is as follows;

<source partition>/6 + <data on partition>

So if you have a 100GB hard disk with 40GB of data on it, the calculation would look like this;

100/6 + 40 = 66.7GB minimum partition size (approximate)

thanks for the replies;

the calculation 320/6 + 13.5 = 66.8

I took my disk from 320GB down to 40GB (Actual sizes 298GB down to 39.4GB)

I only had around 10GB data (OS, Programs, User Settings...), a bloated MFT of about 1.5GB and a 2GB pagefile
> the properties dialog on the drive showed 13.5GB used
> the properties dialog on the drive contents showed 12GB

all future backup images will now be based on the 40GB drive size
so I hope never to run into the "can't restore to ..." because of disk size.

I almost went with 20GB but I figured 40GB would be a reasonable size with plenty of slack for updates etc.

Cheers

Thanks Jon_R for posting the calculation here.  If I remember correctly, the original post with this calculation was along the lines of:  "More recent version of BESR that has the capability to resize target partitions at restore time, and the restoration failed to a slightly larger hard drive."  The original partition was nearly full, so the calculation would allow for some breathing room for the resized partition.  I'm guessing that was the intent of the development team.

Of course Richard FDisk is using an older version of the product that does not have the capability to resize partitions dynamically or on the fly, so the calculation was probably not built into the product at that build. As long as the data had a reasonably good chance of fitting into the existing partition, the manual resizing would work..  Of course the onus is on the person doing the manual resizing to allow for data expansion and the needs of the OS.

I came up with the figure of 1.6 times through a test restore of a 100GB partition with 10GB of data using version 8.5.3   I set the resize parameter to 5GB and the program automatically adjusted the parameter to a shade under 16GB.  The calculation says that  26.6 GB is needed.  My guess is that the development team took the actual percentage of the partition used into account when writing the routines that handle the partition resizing.  if the partition has low space utilization, then a lower calculation for minimum space is all that is needed.  Cases where there is high space utilization is present would definitely call for a higher calculation.  Any OS requires a certain amount of free space on the drive in order for it to perform its maintenance routines.  If a partition is being overstuffed with data, chances are it will continue to be populated with data.  Since the customer is moving the data to a larger drive/partition, it makes sense to "gently persuade" them to resize the partition to a size that allows for data expansion and offer the OS some more room for maintenance routines.

Richard, I think you'll be good to go for a while.  It looks like you have a good grasp of your data storage.  Even at 1.6 times the used space, your 40 GB partition is nearly double the space requirement.

Best of Regards to all