Re: Question about backups with Ghost

Timothy Daniels <TDaniels@xxxxxxxxxxxxx> wrote:
"Anna" wrote:>
Tim:
Let me cite some of my experiences using disk imaging
programs to directly clone the contents of one HD to
another HD and how, for the most significant part, they
parallel your experiences with one or two exceptions. And,
of course, we're speaking about PATA drives here...

1. As I think you know from our past exchanges, I primarily
use the Ghost 2003 disk imaging program to perform direct
disk-to-disk cloning operations although I have used other
DI programs as well, chiefly the Acronis True Image version 8
program. So my comments pretty much refer to the use of
those programs in this area.

2. I most certainly agree with you that it is important, if not
crucial, for the user to disconnect the source disk immediately
following the cloning operation and make that initial boot with only the
newly-cloned HD connected. Future boot problems with that
cloned drive may (but not *always*) occur if the preceding is not
adhered to. At least that has been our experience with the
Ghost & ATI programs, and from reports that I've received from
those who have used other DI programs, the same potential
problem can occur. (BTW, we have run into the same problem
with SATA drives). Incidentally, this potential problem can occur
even if the BIOS boot order priority was changed to make that
initial boot from the cloned HD while both the source & destination
drives were connected at the time of the initial boot to the cloned
HD. The important thing is to disconnect the source disk before
the initial boot to the newly-cloned HD.

3. However, we have never encountered a subsequent boot
problem with the cloned HD if it later was connected as a
secondary drive. At least I can't recall a single problem in this
area. Again, as long as the *initial* boot with that cloned HD
had been undertaken with the source drive disconnected as
indicated above, it didn't matter that the cloned drive was, at
one time or another, later used as a secondary drive. We've
always been able to boot to that cloned drive at some
subsequent time either with the source HD disconnected or
a change in the BIOS boot order should both drives be
connected at the time of that boot.

In this connection - we're assuming two bootable HDs in the
machine - our experience with modern motherboards - let's
say about the past five years - has been (with rare exceptions)
that regardless of the IDE channel (or its position on that
channel) that a bootable HD is connected to, the system will
boot to that drive if it's the only bootable HD currently present in
the system. (A BIOS item change is sometimes necessary to
facilitate this action). I'm not sure if your experience has been
different from mine in this area.

As I've posted in this and other threads in this NG, my experience has
been identical to yours. I've even posted, in detail, experiments which
I have run regarding boot order and its effect on the meaning of
"rdisk()" in boot.ini file's ARC pathname entries.

No you didnt, ALL you ever did was show that THAT PARTICULAR
BIOS does it that way and your nose was rubbed in the FACT that
that is very very uncommon to do it that way.

It isnt even clear if there is actually another bios anywhere
that is so fucked that it actually does it that way.

As for the HD boot order, the result of removal of the existing booting
HD is that some other HD in the HD boot order
(if one exists) is given control by the BIOS to do the booting.

Not necessarily. With some you just get to boot off a non HD instead.

That HD is just the next HD in the HD boot order.

There isnt necessarily any HD boot order at all.

If the currently-booting HD is Master on ch. 0, the next will be the
Slave on ch. 0. If there is no HD as Slave on ch. 0, the HD that is
Master on ch. 1 becomes the boot HD, etc.

Not necessarily again.

That HD boot order is just the default, though.

There isnt necessarily any HD boot order at all.

In BIOSes where the HD boot order can be adjusted by the user, the boot
priority follows the new boot order. My experiments have shown that the
meaning of "rdisk()" also follows the new boot order,

No you didnt, ALL you ever did was show that THAT PARTICULAR
BIOS does it that way and your nose was rubbed in the FACT that
that is very very uncommon to do it that way.

It isnt even clear if there is actually another bios anywhere
that is so fucked that it actually does it that way.

so that "rdisk(0)" refers to whatever HD is at the head of the ordered
list, and "rdisk(1)" refers to the next HD in that list, etc. For that
reason, "rdisk(x)" may thought of as "The HD at Relative Position 'x' in
the HD Boot Order", where 0 refers to the HD at the head of the list.

No you didnt, ALL you ever did was show that THAT PARTICULAR
BIOS does it that way and your nose was rubbed in the FACT that
that is very very uncommon to do it that way.

It isnt even clear if there is actually another bios anywhere
that is so fucked that it actually does it that way.

This has great impact on the meaning of the entries in the boot.ini file.

No you didnt, ALL you ever did was show that THAT PARTICULAR
BIOS does it that way and your nose was rubbed in the FACT that
that is very very uncommon to do it that way.

It isnt even clear if there is actually another bios anywhere
that is so fucked that it actually does it that way.

Reams of pig ignorant silly stuff that proves absolutely
NOTHING about bios in general flushed where it belongs.


.