Re: Re: Re: Problem Finding Hard Drive Involving Cloning



On Tue, 13 Feb 2007 12:53:15 -0500, "Anna" <myname@xxxxxxxxx> wrote:


"Jethro" <Wilson@xxxxxxxxxxxxx> wrote in message
news:itb3t25cvpemrq8rppkeqcncbhhso84d5c@xxxxxxxxxx
This sure seems strange to me.

I have two 120GB hard drives as Primary Master & Slave. I use the
latter to clone back-up the former. I found it worked fine as long as
I remembered to follow the cloning IMMEDIATELY with a boot-up from
the slave drive so it could initialize. I did this by changing the
boot sequence in the AMI BIOS V8.00.09 that I have so that I would
boot from the slave drive. Then I would reverse the booting back to
normal and both drives would be recognized properly by WXP PRO. If I
failed to do this extra step, I found that WXP would not recognize the
slave drive at all.

That has been fine, until now. I added a third 160GB hard drive as
Secondary Slave (my DVDRW drive is on Secondary Master).
It worked just fine. I decided to start cloning back-ups on that
third drive, and it went fine. Until I tried booting-up from it, as I
was doing before, that is. I am finding that I can boot-up fine from
that drive, but when I look at My Computer, the former boot-drive
(still on Primary Master) is not recognized at all! However, if I
revert back to the normal setup, and boot-up from Primary Master, all
is fine, and all three drives are recognized by My Computer. And in
fact, the clone target-drive looks okay content-wise as I guess it
should since it does boot-up okay.

So I am wondering why this is happening. I'm not sure it is hurting
me, but I think something might be wrong.

Help anyone?

Jethro


On Tue, 13 Feb 2007 10:00:41 -0500, "Anna" <myname@xxxxxxxxx> wrote:
Jethro:
Let me first address the information contained in your first paragraph re
the process you followed concerning the disk cloning of your two HDDs. You
were luckier than you thought in that you had no subsequent problems
booting
from either HDD following the disk cloning operation. You indicated that
immediately following the disk cloning operation from your source to your
destination HDD, you made the initial boot to the newly-cloned HDD by
changing the boot order of your BIOS so that the system would boot to the
cloned HDD.

While we always emphasize that the initial boot to the newly-cloned HDD
should be undertaken immediately following the disk cloning operation, we
stress that the source HDD be *disconnected* from the system, i.e., no
other
storage devices should be physically connected to the PC at the time that
initial boot to the newly-cloned HDD is undertaken. In our opinion, merely
changing the boot priority order in the BIOS (while the source HDD is
connected) is insufficient to prevent potentially future boot problems
that
could affect either the source or destination HDD.

(That is so even if the
system initially boots to the newly-cloned HDD without any problem). Note
I
said "potentially". These problems don't always arise; they obviously
didn't
in your case as you related it. But we have seen too many cases where boot
problems *did* occur in the future because the source HDD was connected at
the time the initial boot to the newly-cloned HDD was undertaken
immediately
following the disk-cloning operation.

Now as to why your PM HDD is not being recognized in the system when you
boot to your third newly-cloned HDD - I don't know (unless it's related to
the above scenario in some way). I assume that no drive letter has been
assigned to the PM under those circumstances. Have you tried Disk
Management
to see if you can manipulate things there? Assuming the PM is also not
detected in Device Manager, have you highlighted the Disk drives entry and
invoked the "Scan for hardware changes" command?

Assuming when you boot to the third HDD you have no interest in accessing
data on the PM HDD, I suppose you could live with the present situation
assuming there's no problem booting to either the PM or the PS and all
three
HDDs are accessible under those circumstances. Is that right?
Anna


"Jethro" <Wilson@xxxxxxxxxxxxx> wrote in message
news:l3m3t29j4f7nolpdakof5qq00ihk2i2n43@xxxxxxxxxx
This surprises me because it would mean that I would have to open up
my tower every time I do a backup in order to be sure that the clone
backup is valid. After all, a backup is only good if it 'works'. In
the past I have experienced cases where a clone backup made the clone
copy just fine, and it looked fine. But when I went to use it as a
new boot drive because the copied drive failed - it would not boot.
Ergo not much good. Further I don't think the IDE cabling and/or the
power connectors are intended for constant separation and
re-connecting. I find them to be very fragile.

Thanks for your response though. I fear I am working in a chancy
situation here.

Just how would you verify that a clone copy is a valid one?

Jethro


Jethro:
Well, the obvious way to determine that the cloned HDD is a true clone,
i.e., it will boot straightaway if it is the sole bootable HDD present in
the system and then functions without problems following that boot is to
simply try it. If there *is* a problem along the lines I've described above
it will usually manifest itself when the cloned HDD will not boot *unless*
the source (bootable) HDD is present (connected) in the system. What happens
in that situation is that the system will boot to the cloned HDD but that
drive will be assigned a drive letter other than C: (assuming that was the
source HDD's drive letter assignment). Thus you will not be able to boot
directly to the cloned HDD unless the original source HDD is connected in
the system.

Yes, you're right. It's usually an onerous situation where one would be
required in every case following the disk cloning operation to physically
disconnect the source HDD before undertaking that initial boot to the cloned
HDD to ensure no future boot problems. But as I previously inferred, the
problem does not *always* occur. (That is why I referred to this as a
"potential" problem). In many (perhaps even most) instances it simply
doesn't matter if the source HDD is connected at the time of the initial
boot to the cloned HDD. There will be no future problems. But in a
significant number of instances the problem we've discussed will occur. And
we've found that when there is no original boot problem along the lines
we've described and where there are no basic hardware changes made to the
system in the future, there should be no problems in subsequent disk cloning
operations.

BTW, we generally work with removable HDDs in our desktop systems and
encourage our customers and others to install that type of hardware
configuration. So it's no problem for the user whatsoever disconnecting one
or the other HDDs when the need arises (for any reason).

I might also mention that the boot problem we've been discussing seems to
affect PATA and not SATA HDDs, i.e., as long as the BIOS will allow you to
select one or the other bootable SATA drives to boot to, it's unnecessary to
disconnect the source SATA HDD before undertaking the initial boot to the
destination SATA HDD.

It will be interesting to learn if you've been able to overcome the
non-recognition problem with your PM HDD when you boot to your third HDD,
and if so, just what caused that problem. So keep us informed.
Anna


Thanks again Anna.

A couple of things hit me real quick. First - you must be reading my
mind - I was thinking of replacing my two PATAs with SATAs. If this
problem does not exist with the SATAs, then that is even more
motivation for me to buy the SATAs. I am hoping Geo Wash will have
his usual sales.

On the other hand, I am thinking now that I should NOT be using
cloning for back-ups. I maybe should use imaging instead - that is
maybe I should back up to images of my source HDD. At least I would
not have to worry about booting the target. Of course, the main
reason I chose cloning was because I thought I then could always
validate the correctness of a backup on the spot, and the backup would
be complete, including the OS, all applications, and all data as of
the backup date, minimizing what I would have to do to get going again
on a current basis. All I would have to is 'plug in the drive'. It's
like having a second car in the garage, all gassed up, ready to go in
an emergency. With an image, all I could do is hope that if I ever
have to restore, the result will work (boot that is). Consecutive,
round-robin image-backups would help in that area. Say, weekly backups
- restarting every month.

Jethro
.



Relevant Pages

  • Re: 160 Gb drive in a removable caddy give "disk error press ctrl alt del" on boot
    ... But the 120Gb does boot. ... so, you're working with only a single mobile rack, right? ... GB HDD it boots & functions just fine, ... The full capacity has always been seen of all drives it is just a boot ...
    (microsoft.public.windowsxp.hardware)
  • Re: 160 Gb drive in a removable caddy give "disk error press ctrl alt del" on boot
    ... if so, you're working with only a single mobile rack, right? ... it will boot in that configuration... ... 120 GB HDD it boots & functions just fine, ... The full capacity has always been seen of all drives it is just a boot ...
    (microsoft.public.windowsxp.hardware)
  • Re: Re: Re: Re: Problem Finding Hard Drive Involving Cloning
    ... I have two 120GB hard drives as Primary Master & Slave. ... I remembered to follow the cloning IMMEDIATELY with a boot-up from ... boot from the slave drive. ... from either HDD following the disk cloning operation. ...
    (microsoft.public.windowsxp.hardware)
  • Re: Re: Re: Problem Finding Hard Drive Involving Cloning
    ... I have two 120GB hard drives as Primary Master & Slave. ... I remembered to follow the cloning IMMEDIATELY with a boot-up from ... boot from the slave drive. ... from either HDD following the disk cloning operation. ...
    (microsoft.public.windowsxp.hardware)
  • Re: MBR fix - how? (2 drives)
    ... I have 2 hard drives installed on my system. ... for my system to boot. ... disk-cloning program to clone the contents of your "source" HDD to your ... disk-cloning operation you should *disconnect* the source HDD and boot ...
    (microsoft.public.windowsxp.general)