TBIREST.EXE failing with Errors 12 or 66 when restoring

[drodgers]

I have a Windows 7 system on a single partition that I have performed a Sysprep on and then backed up using Image For Dos. I am then attempting to use TBIREST.EXE in a script from bootable media to restore the system image to a hard drive on a different PC with identical hardware (as part of a standardised image deployment during production). I've left a 500MB buffer of free space at the end of the drive to account for hard drive size discrepancies (I've noticed a 30MB discrepancy between two drives that are the same 1TB model).

If I omit the "/clr" flag from the TBIREST.EXE command line, the program bombs with error code 12 when I don't delete existing partitions on the HDD using a tool like fdisk. Without /uy flag the error is "Target location would overlap existing partitions". What would cause this error?

In the past on the same hardware but a different .TBI when I've included the "/clr" flag the program has bombed on some machines with error code 66 - without /uy the error is something like "The MBR is corrupt or cannot be updated" (don't have exact text sorry).

My (limited) understanding of the way Image4Dos works is that regardless of whether I select Drive + Partition 01 or just Partition 01 for HD0 when doing the backup, the full MBR is stored in the .TBI (including partition table). When I do the restore is there a difference based on what option I chose? (Eg in one case does it attempt to merge partition tables and in another it clears it?)

Is there a recommended way of restoring via TBIREST.EXE in this situation where hard drives may differ in size and the drives may have existing partitions on them (that I want to overwrite)?

[TeraByte Support(PP)]

Restoring an entire drive image is generally the easiest since it will replace the contents of the destination drive. There is a difference between backing up the entire drive (drive + partition) and backup up just the partition. For what you want, backing up the entire drive is what I'd recommend. The MBR and first track is saved in both cases, but will only for sure be automatically restored when restoring an entire drive image.

In addition to /uy, you could use /x (Scale to Fit) to expand the partition to fill the drive.

If restoring just the partition you can specify /rft (Restore First Track) and /fts:0 (entire track) to force the MBR and first track to be restored.

[drodgers]

Thanks for the info.

When backing up the whole drive, will Image4Dos include the free space on the end as something it expects to be able to restore? Eg, if the new hard drive is say 50MB smaller than the source, will there be an issue? I was under the impression that Scale To Fit would only allow an expansion of the drive image and not a reduction.

[TeraByte Support]

it will go smaller even if the partition is bigger provided it can first
restore the data, see
http://www.terabyteunlimited.com/kb/article.php?id=554 for explanation. The
Linux file systems can't go much smaller because there is metadata spread
out across the partition, FAT and NTFS can. but if you're prepping for
deployment, best thing is to start with small partition and let it expand.
As far as if you always wanted 50MB free at the end, you'd use the /kf
option.


"drodgers" wrote in message news:4429@public.image...

Thanks for the info.

When backing up the whole drive, will Image4Dos include the free space on
the end as something it expects to be able to restore? Eg, if the new hard
drive is say 50MB smaller than the source, will there be an issue? I was
under the impression that Scale To Fit would only allow an expansion of the
drive image and not a reduction.