Brian, very interesting - I am unaware of any other image backup product that can do an unattended restore.  Have you tested this?  It works well?

By the way, have you seen Reply #110 in this thread?  It is an admission by TeraByte Unlimited that their PHYLock product can’t necessarily guarantee a consistent “hot image” snapshot.  That is very worrisome, since the quality of the restore is dependent upon the integrity of the backup image.

Brian

Quote:

Interesting...but lacking in *details*   !

Quote:

I have *created* a method for Ghost 2003 that is also *automated*.  I've not *scheduled* it, but it's a *click one button* batch file that takes the system through whatever Ghost process you want to perform without further intervention.  If a call to the batch file was placed in the Windows Scheduler--you could then have it run at a particular time!

It requires an imaging program that can be controlled by command lines (such as DOS Ghost).  It uses a hidden partition with the *automated* Ghost command lines that are carried out in a re-boot to the DOS OS, and then it returns you to the Windows OS.  I'm using Master Boot Record programs to switch which primary partition is active and/or hidden + commands to re-boot the system.

NightOwl,

My post disappeared in the changeover. I'm delighted that we both used basically the same technique. I didn't think it could be done from DOS as I thought you would have had to click OK somewhere along the line. I've used the same technique with Drive Snapshot and there is an OK that I can't get around, immediately before the restore.

As mentioned I have two WinXP OS and I knew I could restore an OS image from one OS to the hidden OS. This can be done with any of the hot imaging apps.

IFW can be run from a command line and has an array of switches. I used two batch files. One to reboot WinXP1 to WinXP2 and the other to run the IFW restore and to reboot to WinXP1. It even works if the second OS is Win98.

Running it as a scheduled task is interesting but practically I just double click the first batch file to start it off. It is the method I now use for my restores.

Brian

It's a small DOS primary partition on my primary HDD--I do not store the images there--those go to the secondary HDD--but, I could have made the partition larger and stored images there--but if my primary HDD fails (that's the one I'm backing up!), then my backup images would go with it!

Also, I prefer *whole HDD* backups--so I couldn't store the image there unless I did *partition* only backups.

It could probably be as small as 10 MBs, but I usually make it 100 MBs and place a number of other DOS utilities on it as well.

I use PartitionMagic to shrink my last partition on an existing HDD, and create the primary at the end of the HDD--I'm not needing HDD access speed for a small DOS imaging program like Ghost--it's loaded into RAM instantly.

Brain

Quote:

I've put the primary DOS partition at the very end of the HDD--at least on older systems, it has to be the HDD on the Primary Controller, and the master HDD--I have not worked with newer systems that allow you to choose which HDD to boot from.

I've done it now on three different systems--being at the end has not been a problem--has to be a primary partition--and not inside an extended partition--although, I think you can get around that if you use some of the third party boot loader programs that Dan Goodell has discussed at his website.

Quote:

I have done this on two systems so far!  I have created an image of the primary DOS partition with the boot files and utility programs--and simply restored it to the available space created for it on the destination HDD.  If you have created automation command lines, then you have to be sure the partitions are laid out the same as the command lines point to on the source on the new destination system--or you have to adjust the command lines to match the new system.  

Brian

Quote:

Interesting!  As long as you are experimenting--you might want to determine if that statement is *outdated*--it might be!

The PartitionMagic User Guide also talks about 2 and 8 GB limits for booting depending on what DOS dependent OS is being used.  Some time after the release of Win98se (DOS based OS), there was an update so the system was no longer bound by that requirement that the boot files had to be within that 8 GB limit.

Before I started using WinXP, all my primary partitions were 2 GB each--so they stayed well below the 8GB limit (Win98se's footprint was small!).  When I started dual booting and experimenting with WinXP, I expanded the size of the primaries to 4 GB each--so the second and third primary extended past that 8 GB limit--and I couldn't boot my Win98se if it was in the second or third primary--I wanted to leave the first two primaries for WinXP experimenting.  So, I could restore the Win98se to that first primary and it booted fine--second or third primary--no boot!  If I adjusted the partition size of the second primary so it stayed below the 8 GB limit--then Win98se booted fine from the 2nd partition also.  And WinXP also showed the same behavior!!!

At the same time, I was trying to find out why when I restored my WinXP image using Ghost 2003 to my physical 2nd primary (when I had adjusted it below the 8 GB limit), I could not boot successfully--but if I used PartitionMagic's copy function to place my working, booting WinXP onto that 2nd partition from the first partition, it booted fine (you may recall, I have a Master Partition Table that has the sequence of partitions listed out of order vs how the partitions are laid out physically on the HDD--and Ghost, without documentation or warning--makes changes to the *boot.ini* file based on what it thinks is the correct boot partition for WinXP images--and it's got a bug and chooses the wrong partition to point to in the *boot.ini* file!)!  So, I was attempting to use TeraByte's *editbini.exe* to access and view the *boot.in* file--but that program would also fail--I could not access the *boot.ini* if WinXP was on the second or third partition (  TeraByte Unlimited Freeware--See *EditBini* ).

Well, sorry for that long intro--the long and short of it is:  It's the Master Boot Record that's installed in sector 0!!!

I inadvertently stumbled on the fix for the above issue with non-booting if the partition extended beyond the 8 GB limit by running the WinXP Recovery Console command:  fixmbr

XP: Repair or fix master boot record using recovery console

This replaces the MBR that you originally placed on the HDD from whatever source with the WinXP's version of the MBR (it does not change or corrupt the Master Partition Table)--and now there was no limit on where I place the primary boot partition--even at the end of a 120 GB HDD--and TeraByte's *editbini.exe* began working just fine!  And Win98se could boot from a primary partition that was well beyond the 8 GB limit too!!!

I had used the Fdisk program from the original Win95 recovery disk, and apparently it has that 8 GB limitation--I think it might be the Fdisk from WinME that resolved that problem--I've never gone back to work out which version fixes the issue--and I don't know what MBR is created by other partitioning tools like PartitionMagic, etc.

But, if you use Dan Goodell's trick to clear up the drive letter assignments for WinXP--your MBR will be based on whatever version of Fdisk you are using--and it may not be up to the task of allowing booting beyond the 8 GB limit if it's an earlier version!!!

Dan Goodell has made the comment in earlier threads on the forum that the version of the MBR isn't really *critical*--any version of Windows will boot regardless--well, that's a partially correct statement until you try to boot from a partition that's beyond the 8 GB limit--and you are still using the original software programming for the MBR--if you never put a boot partition beyond the 8 GB limit--or you are using a *boot loader* that is by a third party--then maybe the MBR doesn't matter--but I wonder if the *boot loader* may have similar issues if it's an older version of the MBR that was originally used--I don't know.

There's something in the programming of the MBR that determines if the system will be able to boot from a primary partition beyond the 8 GB limit--I'm sure it has to do with *seeing* and being able to access boot files on a *large HDD*--but, I don't understand the details!

Brian

Quote:

Oh, but that's what makes *messin* with computers fun!!!

I don't have those system any longer--they are friend's systems and they are at their respective owner's places.

I will see if I can re-configure my system to see if I find any problems.

How did you create a DOS boot partition--what steps and software did you use--that might suggest what we may be doing different?