Question about backups with Ghost

[Timothy Daniels]

Not necessarily, particularly with those which can
clone just a partition, not the entire physical drive.

What is "not necessarily"? -

1) Any utility that will clone a drive will also copy the MBR -
either automatically or as a user-indicated option.

2) Wanting a clone that doesn't have an MBR that will boot it
is an exceptional case.

3) any utility worth its salt will [can] copy the MBR.


*TimDaniels*

 

[Timothy Daniels]

"Rod Speed" does his "mangled" dance:

Thats just plain wrong too.
Wrong again.
Utterly mangled all over again.
That last is utterly mangled all over again.

Anyone can say "mangled", but anyone can
also test to see if what I wrote is "mangled" or not.
Anyone willing to try it will see that what I wrote is true.

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

Thats wrong too, xxcopy doesnt.

What is "not necessarily"? -

That last bit of yours.

1) Any utility that will clone a drive will also copy the MBR -
either automatically or as a user-indicated option.

2) Wanting a clone that doesn't have an MBR that will boot it
is an exceptional case.

3) any utility worth its salt will [can] copy the MBR.

That one. Particularly with those which can clone
just a partition, not the entire physical drive.

 

[Timothy Daniels]

The only thing he has to do is unplug or depower
the C drive for the first boot of the D drive. He can plug
it back in again or repower it after XP has booted...

I've found that de-powering the "parent" drive to isolate
the clone doesn't always work if the drives are on the same
IDE channel - the BIOS sometimes doesn't get past POST
to find all the drives and it just hangs. But if the drives are on
*different* IDE channels (i.e. different cables), the BIOS will
always find the drives and boot-up proceeds. So if the drives
are on the same channel (same cable), the *reliable* way to
render the "parent" invisible is to disconnect both the power
and the data cables of the "parent" drive. You mileage may vary
with IDE controller and BIOS.

*TimDaniels*

 

[Rod Speed]

Timothy Daniels <[email protected]> desperately attempted to bullshit
its way out of its predicament and fooled absolutely no one at all, as
always.

Rod Speed wrote

Anyone can say "mangled",

Anyone can bullshit their way out of their
predicament better than that pathetic effort, too.

but anyone can also test to see if what I wrote is "mangled" or not.

And when they do, they'll prove that you utterly mangled what I
said you utterly mangled and got wrong what I said you got wrong.

Anyone willing to try it will see that what I wrote is true.

Only in your pathetic little pig ignorant drug crazed fantasyland, child.

Most obviously with bios that dont allow you to specify
more than just the master on the primary IDE to boot from.

 

[Timothy Daniels]

Timothy Daniels wrote

Thats wrong too, xxcopy doesnt.

So use xxClone: http://www.xxclone.com/iwhatis.htm

What is "not necessarily"? -
3) any utility worth its salt will [can] copy the MBR.

That one. Particularly with those which can clone
just a partition, not the entire physical drive.

Name a cloning utility that cannot copy the MBR.
Ghost (and its predecessor, Drive Image) can clone
a single partition and it gives the user the option of
copying the MBR. Casper XP can also clone a single
partition and it copies the MBR automatically. xxClone
can also copy a single partition and it also copies the
MBR. True Image cannot clone a single partition directly,
so what it does about the MBR is irrelevant.

*TimDaniels*

 

[Timothy Daniels]

Most obviously with bios that dont allow you to specify
more than just the master on the primary IDE to boot from.

How many major manufacturers of systems or motherboards
have a BIOS that requires the boot drive to be the Master on
IDE channel 0 and nowhere else? Even my 450MHz Dell
Dimension, built in January of 1999 can boot from any hard
drive that is connected. Where do you get your PCs -
Goodwill?

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

So use xxClone: http://www.xxclone.com/iwhatis.htm

That was a comment on your ANY UTILITY claim.

Its just plain wrong.

What is "not necessarily"? -
3) any utility worth its salt will [can] copy the MBR.

That one. Particularly with those which can clone
just a partition, not the entire physical drive.

Name a cloning utility that cannot copy the MBR.

xxcopy is one obvious example.

There are some that can just clone a partition, not a physical
drive. I havent bothered to keep track of them because they
are too crude and incapable to be of any interest to me.

Ghost (and its predecessor, Drive Image) can clone a single partition and
it gives the user the option of copying the MBR. Casper XP can also
clone a single partition and it copies the MBR automatically. xxClone
can also copy a single partition and it also copies the MBR. True Image
cannot clone a single partition directly, so what it does about the MBR
is irrelevant.

Irrelevant to whether there are some that
dont do anything about the MBR at all.

 

[Rod Speed]

Rod Speed wrote

How many major manufacturers of systems or motherboards have a BIOS that
requires the boot drive to be the Master on IDE channel 0 and nowhere
else?

I havent bothered to count them. And its irrelevant to the
FACT that your original is just plain wrong on that anyway.

Even my 450MHz Dell Dimension, built in January of 1999 can boot from any
hard drive that is connected.

Irrelevant to the FACT that your
original is just plain wrong on that.

Where do you get your PCs

I assemble them mostly from new parts, but then
I have been doing that since the days when you
were still loading your diapers thanks, child.

- Goodwill?

Bit hard, we dont actually have any of those.

 

[Anna]

Timothy Daniels wrote

Thats wrong too, xxcopy doesnt.

So use xxClone: http://www.xxclone.com/iwhatis.htm

What is "not necessarily"? -
3) any utility worth its salt will [can] copy the MBR.

That one. Particularly with those which can clone
just a partition, not the entire physical drive.

Name a cloning utility that cannot copy the MBR.
Ghost (and its predecessor, Drive Image) can clone
a single partition and it gives the user the option of
copying the MBR. Casper XP can also clone a single
partition and it copies the MBR automatically. xxClone
can also copy a single partition and it also copies the
MBR. True Image cannot clone a single partition directly,
so what it does about the MBR is irrelevant.

*TimDaniels*

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.
Anna

 

[Timothy Daniels]

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.
Anna

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 "risk()" in boot.ini file's ARC pathname
entries. 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.
That HD is just the next HD in the HD boot order. 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.

That HD boot order is just the default, though. 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, 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.
This has great impact on the meaning of the entries in the boot.ini
file. For a thorough description of the experiments which led to
this conclusion, see Groups.Google.com in this NG in the past
2 months for the thread titled "meaning of 'rdisk()' in boot.ini file".

Here it is again for the Googling-deprived:

---------------------------------------------------
ABSTRACT

This investigation shows that the "rdisk()" parameter
in the boot.ini file represents a hard drive in terms of
its displacement from the head of the hard drive boot order
in the BIOS. The value of n in "rdisk(n)" expresses this
displacement, where n is an integer value starting with 0,
and where "rdisk(0)" represents the hard drive which is at
the head of the hard drive boot order, i.e. the hard drive
at zero displacement from the head of the hard drive boot
order. The BIOS used in the investigation was the Phoenix
Technologies BIOS as supplied in Dell Dimension desktop PCs.


HARDWARE

Dell Dimension XPS-R450 with a Phoenix Tech BIOS,
(3) Maxtor DiamondMaxPlus 9 hard drives connected to
(1) SIIG IDE PCI controller card used in the 1st half of
the investigation, and connected to
(1) motherboard IDE controller used in the 2nd half of
the investigation.


HARD DRIVE CONFIGURATION

IDE channel 0, Master - 80GB hard drive
IDE channel 0, Slave - 40GB hard drive
IDE channel 1, Master - 120GB hard drive

Each HD had a Master Boot Record (MBR),
each HD had as its partition #1 a Primary partition
that
1) had a Boot Sector,
2) was marked "Active", and which
3) contained the boot files ntldr, boot.ini, and ntdetect.com .


SOFTWARE CONFIGURATION

Microsoft WindowsXP Pro installed in partition #1 of each HD.

boot.ini file in the 80GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 2, part 1" /fastdetect

boot.ini file in the 40GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 2, part 1" /fastdetect

boot.ini file in the 120GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(120GB part 1 boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(120GB part 1 boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(120GB part 1 boot.ini) rdisk 2, part 1" /fastdetect


Each of the above boot.ini file entries under the line
"[operating systems]" specified an OS in partition #1 of one
of the HDs, i.e. from "rdisk(0)", "rdisk(1)", or "rdisk(2)".
The character string between the quotes in each OS entry
became a line in the on-screen menu displayed by ntldr at
boot time, and it was to aid in identifying which HD got
control from the BIOS (i.e 80GB, 40GB, or 120GB) and which
"rdisk()" value each line corresponded to.

A file with a name identifying the HD which contained it
was put on the Desktop of each OS. This was to aid in identi-
fying the HD of the OS that was loaded.


EXPERIMENT

Each HD was in turn put at the head of the BIOS's hard drive
boot order and the PC was started. Each of the three entries in
the on-screen boot menu was selected in turn, and the OS that
loaded was recorded. Since the boot.ini files contained entries
only for the partition #1 on each HD, the experiment was a specific
test for the meaning of the "rdisk()" parameter.

Then the order of the 2nd and 3rd HD in the hard drive boot order
was reversed in the BIOS, and the above experiment was repeated.

Then, the hard drives were disconnected from the IDE PCI controller
card and connected to the IDE controller on the motherboard, and the
entire experimental sequence detailed above was repeated. A total of
36 boot-ups were executed.


RESULTS

The following results were identical for both the PCI IDE controller
case and for the motherboard IDE controller case:

HD boot order: 80GB, 40GB, 120GB
boot menu entry selected: HD the OS booted from:
(80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1
(80GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1
(80GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1

HD boot order: 80GB, 120GB, 40GB
boot menu entry selected: HD the OS booted from:
(80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1
(80GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1
(80GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1

HD boot order: 40GB, 80GB, 120GB
boot menu entry selected: HD the OS booted from:
(40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1
(40GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1
(40GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1

HD boot order: 40GB, 120GB, 80GB
boot menu entry selected: HD the OS booted from:
(40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1
(40GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1
(40GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1

HD boot order: 120GB, 40GB, 80GB
boot menu entry selected: HD the OS booted from:
(120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1
(120GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1
(120GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1

HD boot order: 120GB, 80GB, 40GB
boot menu entry selected: HD the OS booted from:
(120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1
(120GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1
(120GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1


DISCUSSION

The OS always booted from the hard drive having a position in
the hard drive boot order expressed as the n in "rdisk(n)" parameter
of the boot.ini file entry. This correspondence persisted throughout
all all permutations of the hard drive boot order and despite which
IDE controller the HDs were connected to. Whether this is the case
in other less common BIOSes is unknown by this investigator. But
since the Phoenix Technologies' BIOSes are used by many large
PC manufacturers, it is probably a very common meaning of "rdisk()"
among modern PCs running a Microsoft Windows operating system.


*TimDaniels*

 

[Rod Speed]

"Anna" wrote:>

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 ****ed 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 ****ed 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 ****ed 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 ****ed 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.

 

[Timothy Daniels]

"Rod Speed" got stuck in a groove:

ALL you ever did was show that THAT PARTICULAR
BIOS does it that way...

All WindowsNT/2K/XP OSes do it that way - it's
built into ntldr, the WinNT/2K/XP boot loader. ntldr
doesn't care what BIOS placed the information in the
set location - it's defined for the PC architecture - ntldr
just accesses that information where that information
is supposed to be, and the definition of "rdisk()" follows
from that. If your PC is to run a modern version of
Windows, it had better work that way, and you'd better
learn to set "rdisk()" that way if you expect to do any
multi-booting or anything else that involves editing
the boot.ini file.

*TimDaniels*

 

[Andy]

Interesting. How do you do that?

MBRWizard - The MBR utility you've been looking for!
http://mirror.href.com/thestarman/asm/mbr/MBRWiz.html

An Examination of the
Windows 2000 ( NT5.0 )
and
Windows XP ( NT5.1 )
MBR ( Master Boot Record )
http://mirror.href.com/thestarman/asm/mbr/Win2kmbr.htm

 

[Rod Speed]

Rod Speed wrote

All WindowsNT/2K/XP OSes do it that way

Wrong, as always. Its got absolutely NOTHING to do
with the OS at all, just what the rdisk() param means.

- it's built into ntldr, the WinNT/2K/XP boot loader.

Not what the rdisk() parameter means it isnt.

ntldr doesn't care what BIOS placed the information in the set location -
it's defined for the PC architecture

Not what the rdisk() parameter means it isnt.

- ntldr just accesses that information where that information is supposed
to be, and the definition of "rdisk()" follows from that.

No it doesnt. The rdisk() parameter is NOT
the number in the HD boot order list.

And MS nor anyone else has ever said that the rdisk()
parameter is the order in the HD boot order list.

I've seen no evidence what so ever that anything other
than that particularly ****ed bios you have does it that way.

And its a terminally stupid way to do it too because
if you change the HD boot order list order, you have
to manually edit the boot.ini. Which is why it aint done
that way on any other bios except your completely
****ed one and I bet its just a bug in that one.

If your PC is to run a modern version of Windows, it had better work that
way, and you'd better learn to set "rdisk()" that way if you expect to do
any multi-booting or anything else that involves editing the boot.ini
file.

Thanks for that completely superfluous proof that you have
never ever had a ****ing clue about anything at all, ever.

When the rdisk() parameter is the order of the physical
drives on the controllers, it works fine and you dont have
to manually edit the boot.ini when you change the HD
boot order list order either deliberately or when there
has been a failure of one of the drives in that list.

 

[Timothy Daniels]

When the rdisk() parameter is the order of the physical
drives on the controllers, it works fine and you dont have
to manually edit the boot.ini when you change the HD
boot order list order either deliberately or when there
has been a failure of one of the drives in that list.

Those fixed-order BIOSes are from the Old World, Roddles.
Give up that Altos or Amiga PC that you found at a landfill, and
move up into the light of Modern Day.

*TimDaniels*

 

[Bob Davis]

Mindlessly silly.

It seems that way to me too, but Timothy says he's seen it happen.

Maybe they were suggesting that the USER might get confused.

I don't think that's what they were suggesting.

That is a bit safer if you want to protect yourself
against the very unlikely possibility of the power
supply dying and frying both drives at once.

Very good point.

Quite a few do, basically to try the clone after
creating it to be sure that it can be booted.

Makes sense, but I've restored a clone enough that I feel confident in its
integrity.

Yep, if you boot the clone without the original being visible,
it will claim to have found new hardware and will ask to be
allowed to reboot. Once you have rebooted, you can make
the original visible to the system again and you will be able
to boot either of the copys with impunity.

Actually, I just get the "found new hardware" and usually another cryptic
message, then it goes on about its business with no prompt to reboot. It's
been a while since I did it, but that's my recollection.

Its significantly crippled in capability.


It is significantly crippled in capability.

It works, and I don't ask to to do much, just clone the drive.

Your problems with OCD are your problem.

I don't have any problems with cloning and have no reason to change. This
procedure has worked for many years, through earlier versions of Ghost.

Wrong.

That one sounded a bit over the top to me too.

Just plain wrong. The ONLY thing that you should
avoid is booting the clone with the original visible.

And its completely trivial to test this and prove it.

For me, a red flag always goes up when the software manufacturer issues a
warning this dire. If it makes no sense, I figure I'm missing something.
Thus, in this case I don't do it, and have adapted. That said, I have no
problem inserting the clone to retreive a file, but I just don't leave it in
like I did with Win9x. And like you said, it's safer that way anyway.

 

[Bob Davis]

The clone only has to be isolated from its "parent" OS
when it's started for its first time.

I can't imagine a scenario when I would boot from the clone with the parent
present. But what about keeping D: as a clone of C: in the machine at all
times? IOW, a clone of C: is made to D:, then you restart XP from C: as
usual and keep D: installed?

I know you can do this with Win9x, as I did it for years--but the caveats
I've seen apparently refer to NT-based OS's (NT, 2K, and XP).

 

[Rod Speed]

It seems that way to me too, but Timothy says he's seen it happen.

ONLY if you boot the clone with the original visible.

He said that too.

I don't think that's what they were suggesting.

Bet it was if you dont boot the clone with the
original visible for the first boot of the clone.

Or they never did understand that you cant
let the first boot of the clone see the original.

Very good point.

But only with internal drives and those in removable
bay kits or eSATA powered from that power supply etc.

Makes sense, but I've restored a clone enough that I feel confident in
its integrity.

Restoring a clone is much more dangerous
when you are testing the backup approach.

Actually, I just get the "found new hardware" and usually another
cryptic message, then it goes on about its business with no prompt to
reboot. It's been a while since I did it, but that's my recollection.

Bet you're remembering it wrong.

It works, and I don't ask to to do much, just clone the drive.

You get a lot more capability with True Image, being able to
image over the lan effortlessly, incremental images, full file
level backups, etc etc etc. Those last two are much better
for your second level backups than your current approach.

I don't have any problems with cloning

OCD is obsessive compulsive disorder
and is a problem between your ears.

and have no reason to change.

Yes you do, True Image would be a much cleaner
approach with the secondary backups you do too.

This procedure has worked for many years, through earlier versions of
Ghost.

And is way past its useby date now for the secondary
backups you do that Ghost cant even do.

That one sounded a bit over the top to me too.

Yeah, Radified has always been riddled
with over the top pig ignorant crap.

They cant even manage the basics, compare
the two drives and see what actually got
changed. The registry never did get corrupted.

For me, a red flag always goes up when the software manufacturer issues a
warning this dire. If it makes no sense, I figure I'm missing something.

You arent, that claim is just plain wrong.

The only thing the active flag does is allow the bios
which partition to boot on a particular physical drive.

The fool that wrote that is just mindlessly repeating the drivel
thats been pig ignorantly spouted on the net for decades now.

Thus, in this case I don't do it, and have adapted.

Makes more sense to test the claim instead and prove its wrong.

That said, I have no problem inserting the clone to retreive a file, but
I just don't leave it in like I did with Win9x. And like you said, it's
safer that way anyway.

The risk of the power supply failing and killing both drives is very low.

 

[Rod Speed]

Rod Speed wrote

Those fixed-order BIOSes are from the Old World

I wasnt talking about any fixed order bios, child.

I was talking about drives that do have a HD boot
order list but dont use that for the rdisk() parameter.
The rdisk() parameter is the physical order of the
drives on the controllers, not the HD boot order list.

<reams of your puerile shit flushed where it belongs>