Cloning your entire source drive

[Bill in Co.]

What happens if you *clone* your entire source drive (mine consists of
partitions C:, D:, E;, and F, over to a backup drive (in my case, to
another SATA drive in a hard disk enclosure), and then accidentally reboot,
with both powered on and connected? (i.e., both the internal source SATA
drive and the external one, each having identical partitions)? Will there
be a big issue here due to the conflicts between the two bootable drives
each having their Active Partition bits set?

I'm just guessing it may boot up to the internal source drive, and that
you'll see a bunch of new added drive letters in Windows Explorer (G, H, I,
J), but since only one drive can supposedly have its Active Partition bit
set, what really would happen? Additionally, I expect the drive letters
will be all messed up from that point onward. Like the D: partition would
NOW refer to the primary partition on the backup drive, etc (egads), since
they are enumerated first as I recall.

And if one does this, perhaps the destination backup drive magically gets
its Active Bit cleared, in which case it will no longer be a bootable clone
(at least until that bit is somehow reset first IF you replace the drives)

 

[JS]

The primary partitions on either drive will
grab the first drive letters (C, D, E, F, Etc)
followed by the logical drives but in what
order is hard to say.

As to the external may not be seen as bootable
if your BIOS doesn't support bootable external
drives.

If the bit is reset it can be made active again.

 

[Timothy Daniels]

What happens if you *clone* your entire source drive (mine consists of partitions C:, D:, E;, and F, over to a
backup drive (in my case, to another SATA drive in a hard disk enclosure), and then accidentally reboot, with both
powered on and connected? (i.e., both the internal source SATA drive and the external one, each having identical
partitions)? Will there be a big issue here due to the conflicts between the two bootable drives each having their
Active Partition bits set?

I'm just guessing it may boot up to the internal source drive, and that you'll see a bunch of new added drive letters
in Windows Explorer (G, H, I, J), but since only one drive can supposedly have its Active Partition bit set, what
really would happen? Additionally, I expect the drive letters will be all messed up from that point onward. Like
the D: partition would NOW refer to the primary partition on the backup drive, etc (egads), since they are enumerated
first as I recall.

And if one does this, perhaps the destination backup drive magically gets its Active Bit cleared, in which case it
will no longer be a bootable clone (at least until that bit is somehow reset first IF you replace the drives)

As long as the BIOS's Hard Drive Boot Priority isn't reset and you
haven't inter-changed the positions of the 2 HDs, the original OS will
boot up. It will not be a problem for the "parent" OS to see its clone,
and it will merely assign partition letters within its own tables for the
partitions on the clone HD. It will know those partitions by the letters
it assigns them, but the partitions in the clone HD aren't actually affected.

Be careful, though, not to let the clone OS boot up for its 1st run with
the "parent" OS still in view. For the clone OS's 1st run, have the "parent"
HD disconnected. You don't have to play with the BIOS's Hard Drive
Boot Order, as the absence of the "parent" HD will merely cause the
BIOS to select the clone HD as the boot drive. The clone OS's "active"
flag will have been copied (for some utilities this is a user option) and
the same partition in the clone HD will act as the "System (i.e. boot)
Partition". The clone OS will act as if it were the "parent", and it will refer
to its own partitions by the same letters as did the "parent" OS. After the
1st run of the clone OS, you can reconnect the "parent" HD, and either
OS can be started with the other OS visible to it. When the clone OS
starts up with its "parent" HD visible to it, it will assign drive letters to the
"parent" HD's partitions, but those will be for its own reference and won't
affect the "parent" partitions themselves. If you'd rather not get into
adding an entry in the System Partition's boot.ini file for the dual-boot
option, you can control which HD gets boot control by setting the Hard
Drive Boot Priority in the BIOS.

*TimDaniels*

 

[Tim Meddick]

Bill,
No matter how many 'cloned' drives you have there can be only ONE
ACTIVE (bootable) partition on any physical hard-drive. Due to the way
Windows recognises physical drives makes it impossible to boot to anything
but the original physical disk and the original partition. Look in the
"boot.ini" file in the root of your system dive and you will see the drives
listed NOT by drive letter but like this:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
Professional"
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Microsoft Windows XP
Professional (Backup)"

....so you can see for yourself - Windows is using absolutes to know which
physical drive is which. Also, JS is right when he says that the external
drive may well not be seen as bootable even if you did create an entry for
it (as above.).
The clone will just appear as a set of drives with subsequent letters
assigned i.e. G:, H:, I: and J: (assuming you have no other fixed disks
installed)

==


Cheers, Tim Meddick, Peckham, London.


*NB I have my own reasons for listing MY cloned drive in the boot.ini file
but rest assured - it is NOT advisable to boot into it as it will be seen by
Windows as a different installation and assign the next logical drive letter
to it after C: that is D: !! Unless EVERY reference to C: drive on your
system (and therefore, the cloned active partition) is replaced with the
replaceable parameters %SystemRoot% or %HOMEDRIVE% the cloned OS will not
load properly.

 

[Bill in Co.]

As long as the BIOS's Hard Drive Boot Priority isn't reset and you
haven't inter-changed the positions of the 2 HDs, the original OS will
boot up. It will not be a problem for the "parent" OS to see its clone,
and it will merely assign partition letters within its own tables for the
partitions on the clone HD. It will know those partitions by the letters
it assigns them, but the partitions in the clone HD aren't actually
affected.

Meaning if you later disconnect the clone HD and reboot, everything will be
exactly as it used to be, I expect.

BUT if you leave it connected, what used to be my small D: partition on the
source drive will no longer be designated as D:,.since the clone drive has a
primary partition, and THAT will now be D:, etc, etc. (since primary
partitions are all assigned first priority in the drive letter assignments).
And that will stay that way as long as both drives are connected. BUT if
I disconnect the clone drive, everything returns to normal. I presume. ??

Be careful, though, not to let the clone OS boot up for its 1st run
with
the "parent" OS still in view. For the clone OS's 1st run, have the
"parent"
HD disconnected.

OK, Tim, I'm trying to understand this. Like what happens if you don't?
Would it permanently change the parent drive's system partition designation
in windows to D:, which obviously would really screw things up if I wanted
to use that as the system drive again, or what would be the problem?

 

[John John - MVP]

Meaning if you later disconnect the clone HD and reboot, everything will be
exactly as it used to be, I expect.

BUT if you leave it connected, what used to be my small D: partition on the
source drive will no longer be designated as D:,.since the clone drive has a
primary partition, and THAT will now be D:, etc, etc. (since primary
partitions are all assigned first priority in the drive letter assignments).
And that will stay that way as long as both drives are connected. BUT if
I disconnect the clone drive, everything returns to normal. I presume. ??

You are right in that active partitions are assigned drive letters
before the others but they will not be assigned already assigned drive
letters. The I/O Manager's IoAssignDriveLetters function will honour
previously assigned drive letter assignments, drive letter assignments
are persistent on Windows NT system so the newly discovered drive will
be assigned another (unused) drive letter, your existing D drive will
keep its drive letter and the new drive will be assigned the next
available drive letter. The Mount Manager will store this information
in its database at HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices and the
next time the computer is booted the same drive letters will be
reassigned to the drives.

OK, Tim, I'm trying to understand this. Like what happens if you don't?
Would it permanently change the parent drive's system partition designation
in windows to D:, which obviously would really screw things up if I wanted
to use that as the system drive again, or what would be the problem?

No, because of the persistent nature of drive letter assignments the C
letter will be assigned to the already existing 'parent' drive and the
clone will be assigned the next available drive letter, the clone could
very well end up on drive G, it all depends on which letter is the next
one available. This in turn (having the clone on G will cause havoc
with the Windows installation because when Windows is installed many
entries pointing to the installation drive letter are written in the
registry, everything will point to C: and now the clone will find itself
on G: and before long the whole installation will crumble. Remember
that the clone is an *exact* copy so the clone has the same Mount
Manager database as the original installation, so the
IoAssignDriveLetters function will honour previously assigned drive
letters. If the 'parent' drive is not connected when the clone is
booted for the fist time it will interpret the Mount Manager database as
being invalid and it will assign drive letters following a present set
of rules and the first active partition (that used to boot the clone)
will be assigned drive letter C. On subsequent reboots any other
attached drives will be given letters other than C.

John

 

[Anna]

What happens if you *clone* your entire source drive (mine consists of
partitions C:, D:, E;, and F, over to a backup drive (in my case, to
another SATA drive in a hard disk enclosure), and then accidentally
reboot, with both powered on and connected? (i.e., both the internal
source SATA drive and the external one, each having identical partitions)?
Will there be a big issue here due to the conflicts between the two
bootable drives each having their Active Partition bits set?

I'm just guessing it may boot up to the internal source drive, and that
you'll see a bunch of new added drive letters in Windows Explorer (G, H,
I, J), but since only one drive can supposedly have its Active Partition
bit set, what really would happen? Additionally, I expect the drive
letters will be all messed up from that point onward. Like the D:
partition would NOW refer to the primary partition on the backup drive,
etc (egads), since they are enumerated first as I recall.

And if one does this, perhaps the destination backup drive magically gets
its Active Bit cleared, in which case it will no longer be a bootable
clone (at least until that bit is somehow reset first IF you replace the
drives)

Bill:
As I recall you & I have discussed this issue at some length in the past but
obviously the issue hasn't been clarified to your satisfaction. So let me
add my comments to the ones you've already received.

As I'm sure you'll surmise from our previous exchange of posts on this
subject my comments will be in the context of the Casper 5 disk-cloning
program. While by & large my comments should apply to any disk-cloning
program, there is one particular area where the Casper program deviates from
other disk-cloning programs that I'm familiar with (in an advantageous way I
might add) and which I'll get to by & by.

Let's proceed on the following basis...

1. As you've indicated, your "source" HDD (your day-to-day working HDD) is
multi-partitioned with four partitions - C:, D:, E:, & F:. Presumably you're
working with an optical drive so let's assign that component with the G:
drive letter, OK?

2. You've indicated that your "destination" HDD, i.e., the recipient of the
cloned contents of your source HDD is a SATA HDD contained in an external
enclosure. However you have not indicated whether that external device is
connected as a USB device or has SATA-to-SATA connectivity. So we'll cover
both configurations, OK?

3. Obviously your BIOS boot priority order or boot precedence indicates a
first HDD boot to your C: partition.

4. When you clone the entire contents of your source HDD to your destination
HDD, the four partitions thus created on the destination drive will be H:,
I:, J:, & K:, (obviously coinciding with the C:, D:, E:, & F: partitions on
your source HDD. Thus the contents of your source drive's C: partition will
be contained in the destination drive's H: partition, the source D:
partition in the I: partition, etc., etc.

5. Following the disk-cloning operation, with both the source & destination
drives connected, (and regardless whether your destination HDD is
USB-connected or has SATA-to-SATA connectivity with your system), nothing
will change re the drive letter assignments. Your system will boot to your
source drive's C: partition and that will be that.

The fact that your externally-connected SATA HDD may have SATA-to-SATA
connectivity (thus being treated as an *internal* HDD by the system) is
irrelevant (using the Casper program) insofar as any later potential (boot)
problem with boot/drive letter assignments affecting the destination HDD as
may occur with other disk-cloning programs.

As you have heard from one or more responders, and as I believe you're
aware, it is generally recommended that immediately following the
disk-cloning operation where the destination HDD is *internally* connected
(thus potentially bootable), that drive be disconnected from the system and
the boot made only with the source HDD connected. Or, the source HDD be
disconnected from the system and the boot made to the destination HDD (if
for no other reason than to determine that the clone "took" and the user
obviously has a bootable, functional drive). The point here is that *both"
drives (the source & destination HDDs) should not be both connected on the
first boot following the disk-cloning operation.

But with the Casper program the preceding practice is unnecessary, another
significant advantage of Casper. We have undertaken or witnessed hundreds of
disk-cloning operations and have never run into a single instance of any
problem in this area when both internally-connected source & destination
HDDs are connected following a disk-cloning operation and the boot is made
to either the source or destination HDD. The destination HDD will later boot
without any problem, its H: partition (in this example) will receive the C:
drive letter assignment.

If the destination HDD is an externally-connected USB device there's really
no problem (re this particular issue) to begin with since the USBEHD is not
a bootable device.

6. So now we come into the situation where for one reason or another, e.g.,
the source HDD becomes defective or the system becomes so corrupt that it is
unbootable & dysfunctional, etc., etc., so that it becomes necessary for the
user to use his/her cloned external (destination) HDD to restore their
system.

7. Again, if the destination HDD has SATA-to-SATA connectivity the user
could then boot directly to that drive and the system would assign drive
letters C:, D:, E:, & F: to the four partitions, regardless of the drive
letter assignments on that drive prior to the boot. The same would be true
should the user be employing another *internal* HDD as the destination HDD,
i.e., the recipient of the cloned contents of the source HDD.

8. If, on the other hand, the destination HDD was a USB-connected device and
thus non-bootable, the user would clone the contents of that drive to an
internally-connected HDD and again, the drive letter assignments would be
C:, D:, E:, & F: on the newly-cloned internal boot drive.

So when all is said & done is it not clear that the drive letter assignments
affecting the destination drive are irrelevant (in the context of this
disk-cloning process)? So that in your example it's of no consequence what
drive letters are assigned to each of the four partitions on the destination
drive. This destination drive is simply serving as a repository of the
cloned contents of the source disk, right? All we're really concerned with
is that (notwithstanding drive letter assignments) the contents of the
destination HDD are a precise copy of the source drive's contents. Is that
not so?

If & when the time comes that we will be using the destination HDD to
restore the system either by cloning the contents of that drive back to
another HDD, or should the destination HDD had been another internal HDD (or
an external HDD having SATA-to-SATA connectivity) so that we would be able
(should we desire) to employ any of those drives as the boot drive, the
drive letter assignments on the multi-partitioned boot drive would reflect
the original source drive's letter assignments.
Anna

 

[Mike Torello]

Bill:
As I recall you & I have discussed this issue at some length in the past but
obviously the issue hasn't been clarified to your satisfaction. So let me
add my comments to the ones you've already received.

Bill's skull is thicker than a nuclear-hardened shelter's walls.

 

[Bill in Co.]

Bill's skull is thicker than a nuclear-hardened shelter's walls.

School must be out early today. Did you clear this with the hall monitor?

 

[Bill in Co.]

Thanks, John.

So if I now understand this correctly, the BEST and safest thing to do is to
one time just boot up the clone w/o the other internal boot drive connected
(which will also verify it), and that one time action will permanently
rebuild and set its registry entries in the MountedDevices key correctly for
that drive. Then after doing that, I'm safe no matter what I do with my
normal internal system drive (meaning, having the other drive connected or
disconnected.

Interestingly enough, I find I have two registry keys in there:
"MountedDevices", and "MountedDevices1", which are somewhat different.

In addition to my main internal SATA system drive, I have another internal
SATA drive which is used for copies of image backups in a single partition.

I just recently made a clone of my entire source drive to an external SATA
HD enclosure drive using ATI. It uses an eSATA interface between the
computer and that external hard drive), and is normally disconnected.

So hopefully I have this part down. If I missed something, pse advise.
Thanks.

 

[Bill in Co.]

Thanks, Anna.

I'm going to repeat most of what I said to John, and see if I have this
correct now, from your point of view.

But to answer your question, I used ATI to make the clone to a SATA external
HD enclosure, which uses an eSATA interface to the computer.

And that I also have a secondary *internal* SATA drive which I use for
several generational image backups (in its single partition), and that SATA
drive is of course always connected, just like my main internal SATA drive.
But the external drive in which I made my clone is not normally connected,
and I only did this just to have a full clone of my main drive in case it
ever died (and image backups would be more trouble to deal with in that
case).

So if I now understand this correctly, the BEST and safest thing to do (for
any case, and any cloning programs that were used) is to ONE time just boot
up the clone *w/o the other internal boot drive connected* (which will also
verify it), and that one time action will permanently rebuild and set its
registry entries in the MountedDevices key correctly for that drive. Then,
after doing that, I'm safe no matter what I do with my normal internal
system drive (meaning, having the other drive connected or disconnected.

Interestingly enough, I find I have two registry keys in there:
"MountedDevices", and "MountedDevice1", which are somewhat different.

In addition to my main internal SATA system drive, I have another internal
SATA drive which is used for copies of image backups in a single partition.

I just recently made a clone of my entire source drive to an external SATA
HD enclosure drive using ATI. It uses an eSATA interface between the
computer and that external hard drive), and is normally disconnected.

So hopefully I have this part down. If I missed something, pse advise.
Thanks again.

It seems the moral to the story is: if you're going to make a clone of your
main drive (using any clone program, in general), it's best to ONE time set
it up without the other drive connected, and then put it away on the shelf.
And if you forget to do this once, there will be hell to pay (the clone will
be worthless w/o some registry patching).

 

[John John - MVP]

Yep, that is the thing to do, that is what Tim was telling you when he
said "...not to let the clone OS boot up for its 1st run with the
"parent" OS still in view." After the first boot and after the
MountedDevices entries for the drive hosting the operating system have
been written you can connect the drive and things should be fine.

Re: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices1

Have you by any chance been playing with Partition Magic? I don't know
Partition Magic very well but from information on the web it appears
that this key might have been created by Partition Magic. This is
another way to get the system to rebuild the MountManager database,
delete all the entries in the HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
key or delete the key itself, when Windows is rebooted the key and
MountedDevices database is rebuilt. The MountedDevices1 key is simply
the old MountedDevice key renamed, gives the same results as deleting
the key yet saves a copy in case you need to later restore it.

John

 

[Timothy Daniels]

So if I now understand this correctly, the BEST and safest thing to do (for any case, and any cloning programs that
were used) is to ONE time just boot up the clone *w/o the other internal boot drive connected* (which will also verify
it), and that one time action will permanently rebuild and set its registry entries in the MountedDevices key
correctly for that drive. Then, after doing that, I'm safe no matter what I do with my normal internal system drive
(meaning, having the other drive connected or disconnected.

That is correct. What I do is to use a toggle switch to switch off the
1st HD's power, but that is another thread entirely.

It seems the moral to the story is: if you're going to make a clone of your main drive (using any clone program, in
general), it's best to ONE time set it up without the other drive connected, [.....]

That is correct if by "ONE time set it up" you mean "start up the clone OS
for its first run". As Anna pointed out, the recent version(s) of Casper doesn't
require this, but it has heretofore been necessary to keep the clone from
getting "confused" when it sees its "parent" and can't differentiate itself from
its "parent". After that initial run without its "parent" OS visible to it, the clone
can be started up OK even if its "parent" OS is visible to it. There are no
such cautions necessary for the start up of the "parent" OS, i.e. the original OS.

*TimDaniels*

 

[Anna]

Thanks, Anna.

I'm going to repeat most of what I said to John, and see if I have this
correct now, from your point of view.

But to answer your question, I used ATI to make the clone to a SATA
external HD enclosure, which uses an eSATA interface to the computer.

And that I also have a secondary *internal* SATA drive which I use for
several generational image backups (in its single partition), and that
SATA drive is of course always connected, just like my main internal SATA
drive. But the external drive in which I made my clone is not normally
connected, and I only did this just to have a full clone of my main drive
in case it ever died (and image backups would be more trouble to deal with
in that case).

So if I now understand this correctly, the BEST and safest thing to do
(for any case, and any cloning programs that were used) is to ONE time
just boot up the clone *w/o the other internal boot drive connected*
(which will also verify it), and that one time action will permanently
rebuild and set its registry entries in the MountedDevices key correctly
for that drive. Then, after doing that, I'm safe no matter what I do
with my normal internal system drive (meaning, having the other drive
connected or disconnected.

Interestingly enough, I find I have two registry keys in there:
"MountedDevices", and "MountedDevice1", which are somewhat different.

In addition to my main internal SATA system drive, I have another internal
SATA drive which is used for copies of image backups in a single
partition.

I just recently made a clone of my entire source drive to an external SATA
HD enclosure drive using ATI. It uses an eSATA interface between the
computer and that external hard drive), and is normally disconnected.

So hopefully I have this part down. If I missed something, pse advise.
Thanks again.

It seems the moral to the story is: if you're going to make a clone of
your main drive (using any clone program, in general), it's best to ONE
time set it up without the other drive connected, and then put it away on
the shelf. And if you forget to do this once, there will be hell to pay
(the clone will be worthless w/o some registry patching).

Bill:
Yes, you have it right, at least based upon my experience with every
disk-cloning program I've ever used with the *exception* of the Casper 5
program.

As I previously indicated, using the Casper 5 program we have *never* run
into a problem along the lines we've been discussing. With Casper 5, in
terms of the initial boot following the disk-cloning operation, where the
"destination" HDD, i.e., the recipient of the "source" drive's contents, is
another *internal* HDD (or an external HDD having SATA-to-SATA
connectivity), it simply does not matter whether or not that initial boot is
made to the destination HDD with the source HDD disconnected. Under *all*
circumstances (assuming, of course, a valid disk-cloning operation has been
effected), the destination HDD will be a bootable device.

The user could boot to his/her source HDD with the cloned HDD connected and
the clone will be a bootable device at any subsequent time.

Naturally a user may wish to verify that the disk-cloning operation has been
successful so he/she might want to boot to the cloned HDD to determine such.
There would be *no* need to disconnect the source HDD in that situation.
With the source HDD still connected the user would presumably temporarily
change the BIOS boot priority order so that the boot goes to the cloned HDD
and then change the boot priority again after determining the cloned HDD is
a bootable device. Again, no problem. The cloned HDD will always be a
bootable device even under those circumstances.

So while the "moral to the story" as you put it may have relevance to other
disk-cloning programs, it's of no consequence insofar as the Casper 5
program is concerned as I have described above. It's another reason why we
have a strong preference for this program.
Anna

 

[Bill in Co.]

Yes, I had used Partition Magic at some points in time, so I guess it was
responsible for that secondary key "MountedDevice1", as you said, John.
(It was "MountedDevice1", not "MountedDevices1" - my mistake).

Anyways, I temporarily disconnected the internal source SATA-0 drive, and
then booted up on the SATA enclosure clone (connected as an eSATA to port
SATA-5, apparently designated as such in BIOS), and it booted up just fine.

Then I powered off and disconnected the clone, and reconnected the main
drive, and got a boot up problem "No OS Found" or whatever, and had to go
into BIOS and change the boot order back again, for some reason. It had
moved up my other internal SATA drive storing the image backups (SATA-4) to
the top of the list. (I have two internal SATA drives - the system drive
and a backup drive storing several generational images of the C: partition)

Well, on second thought, maybe that's to be expected, as when I had the
clone in, it was connected to SATA-5, and there was no SATA-0 anymore at
that point in time (since I had removed it). So I assume the BIOS CMOS
must have remembered that and reset the BIOS boot priority list. Is that
what happened here?

Thanks again John, Tim, Anna, JC, and all the others too!

 

[Bill in Co.]

That is correct. What I do is to use a toggle switch to switch off the
1st HD's power, but that is another thread entirely.

I see.

It seems the moral to the story is: if you're going to make a clone of
your
main drive (using any clone program, in general), it's best to ONE time
set
it up without the other drive connected, [.....]

That is correct if by "ONE time set it up" you mean "start up the clone
OS
for its first run".

Right - that's what I meant.

As Anna pointed out, the recent version(s) of Casper
doesn't require this, but it has heretofore been necessary to keep the
clone
from getting "confused" when it sees its "parent" and can't differentiate
itself
from its "parent". After that initial run without its "parent" OS visible
to it,
the clone can be started up OK even if its "parent" OS is visible to it.
There are no such cautions necessary for the start up of the "parent" OS,
i.e. the
original OS.

Well, I was using ATI, not Casper, to make the clone, so I had to pay
attention to this.

 

[Bill in Co.]

Bill:
Yes, you have it right, at least based upon my experience with every
disk-cloning program I've ever used with the *exception* of the Casper 5
program.

As I previously indicated, using the Casper 5 program we have *never* run
into a problem along the lines we've been discussing. With Casper 5, in
terms of the initial boot following the disk-cloning operation, where the
"destination" HDD, i.e., the recipient of the "source" drive's contents,
is
another *internal* HDD (or an external HDD having SATA-to-SATA
connectivity), it simply does not matter whether or not that initial boot
is
made to the destination HDD with the source HDD disconnected. Under *all*
circumstances (assuming, of course, a valid disk-cloning operation has
been
effected), the destination HDD will be a bootable device.

The user could boot to his/her source HDD with the cloned HDD connected
and the clone will be a bootable device at any subsequent time.

Naturally a user may wish to verify that the disk-cloning operation has
been
successful so he/she might want to boot to the cloned HDD to determine
such.
There would be *no* need to disconnect the source HDD in that situation.
With the source HDD still connected the user would presumably temporarily
change the BIOS boot priority order so that the boot goes to the cloned
HDD
and then change the boot priority again after determining the cloned HDD
is
a bootable device. Again, no problem. The cloned HDD will always be a
bootable device even under those circumstances.

So while the "moral to the story" as you put it may have relevance to
other
disk-cloning programs, it's of no consequence insofar as the Casper 5
program is concerned as I have described above. It's another reason why we
have a strong preference for this program.
Anna

Right. But at this point I'm only using ATI, so I had to be careful!!

Just as an aside to this discussion, I know we have discussed the advantages
of Smart Cloning, but I (just for me) still prefer writing out an entirely
new and fresh image (or clone), and NOT using incrementals or differentials,
or what have you (which includes Smart Cloning).

Why? Because only then will you get an absolutely 100% accurate backup of
your system at that point in time. Because in the former case, indeed the
changes are being recorded and saved as time goes on, but with a FULL backup
(not Smart or incremental), what is being saved is exactly what the entire
system is at that point in time, down to the last details).

So what do I mean by that? Well, supposed you decided to change something,
and then later decided to change it again, and/or to erase or unerase
certain files, or what have you. If you use Smart Cloning or Incremental
or Differential Imaging, granted, all the important changes will be taken
care of, but the disk will still never be 100% identical to the case of
writing out a completely new clone or image.

In my case, it takes me only 10 minutes to create a full image backup of
about 20 GB of data (I'm using SATA-II), so the time is insignificant.

 

[Anna]

Just as an aside to this discussion, I know we have discussed the
advantages of Smart Cloning, but I (just for me) still prefer writing out
an entirely new and fresh image (or clone), and NOT using incrementals or
differentials, or what have you (which includes Smart Cloning).

Why? Because only then will you get an absolutely 100% accurate backup
of your system at that point in time. Because in the former case, indeed
the changes are being recorded and saved as time goes on, but with a FULL
backup (not Smart or incremental), what is being saved is exactly what the
entire system is at that point in time, down to the last details).

So what do I mean by that? Well, supposed you decided to change
something, and then later decided to change it again, and/or to erase or
unerase certain files, or what have you. If you use Smart Cloning or
Incremental or Differential Imaging, granted, all the important changes
will be taken care of, but the disk will still never be 100% identical to
the case of writing out a completely new clone or image.

In my case, it takes me only 10 minutes to create a full image backup of
about 20 GB of data (I'm using SATA-II), so the time is insignificant.

Bill...
Please understand - as I have continually tried to emphasize in all my posts
describing the Casper 5 program - that Casper's "incremental" cloning
capability (what Casper terms its "SmartClone technology") produces a
*complete* clone in every sense of the word. It is *not* an incremental
file; it is *not* a separate "incremental" clone along with the "original"
clone. It is a complete clone of the contents of the source HDD. The
resultant clone *will* be (for all practical purposes) "100% identical" to
the source HDD, in effect, a precise copy of the latter. What else could a
user desire?

It's just that the program has the capability of detecting whatever changes
have been made to the data contents since the previous disk or partition
cloning operation. By so doing, i.e., taking only those changes into account
during the current disk or partition cloning operation, the backup process
proceeds with extroardinary speed (compared with other disk-cloning or
disk-imaging programs that I'm familiar with).

It is primarily because of this "SmartClone technology" why we greatly
prefer the Casper 5 program over all other disk-cloning/disk-imaging
comprehensive backup programs. The result of this incremental clone process
is that it takes the user only a fraction of the time to create subsequent
clones of the source HDD than it would otherwise take using the typical
disk-cloning methodology. Thus the user has a strong & ongoing incentive to
backup his/her system on a routine frequent basis so as to maintain
reasonably up-to-date complete system backups, secure in the knowledge that
by doing so it will take them only a fraction of the time it would otherwise
take with other disk-cloning/disk-imaging programs with the end result being
a *complete* clone of their system at that point-in-time.

Using your own example...

You say, using the Acronis program, it takes you 10 minutes to create a full
image backup of about 20 GB of data. Using the Casper 5 program say once or
twice a week, I could practically guarantee it would take you about two (2)
minutes to produce a complete clone of your source HDD with that amount of
data. Two minutes.

And what would you have? Not a disk image. But a complete clone of your
source HDD. All data immediately accessible (since the clone would be a
precise copy of your source HDD). No "restore" process would be necessary
since your cloned SATA HDD
would be *immediately* bootable & functional. I truly believe that for a
vast majority of PC users using a disk-cloning program such as Casper 5 is
the preferred way to establish & maintain a comprehensive backup program.
Anna

 

[Timothy Daniels]

Please understand - as I have continually tried to emphasize in all my posts describing the Casper 5 program - that
Casper's "incremental" cloning capability (what Casper terms its "SmartClone technology") produces a *complete* clone
in every sense of the word. It is *not* an incremental file; it is *not* a separate "incremental" clone along with the
"original" clone. It is a complete clone of the contents of the source HDD. The resultant clone *will* be (for all
practical purposes) "100% identical" to the source HDD, in effect, a precise copy of the latter. What else could a
user desire?

It's just that the program has the capability of detecting whatever changes have been made to the data contents since
the previous disk or partition cloning operation. By so doing, i.e., taking only those changes into account during the
current disk or partition cloning operation, the backup process proceeds with extroardinary speed (compared with other
disk-cloning or disk-imaging programs that I'm familiar with).

I think Bill likes the idea that his clone is a snapshot of the system taken
all at the same time, whereas a clone which includes incremental changes
along the way is a clone of the system at the time of the last backup - which
could have been 2 minutes ago. If Bill discovers that a file was corrupted
or lost last week sometime, he knows that a clone made earlier than that
would contain the file as it was at that earlier time. So Bill is simply "archiving"
rather than backing up for a hard drive crash.

*TimDaniels*

 

[Mike Torello]

Why? Because only then will you get an absolutely 100% accurate backup of
your system at that point in time. Because in the former case, indeed the
changes are being recorded and saved as time goes on, but with a FULL backup
(not Smart or incremental), what is being saved is exactly what the entire
system is at that point in time, down to the last details).

So what do I mean by that? Well, supposed you decided to change something,
and then later decided to change it again, and/or to erase or unerase
certain files, or what have you. If you use Smart Cloning or Incremental
or Differential Imaging, granted, all the important changes will be taken
care of, but the disk will still never be 100% identical to the case of
writing out a completely new clone or image.

You still don't get it, do you old boy!?

Casper's "Smart Clone" results in a full, identical clone of the
original disk - just as if you had done a complete clone from scratch.
It is not like an incremental backup image.

Read the above 100 times until is finally sinks in.