Re: second HD with drive image
- From: "Anna" <myname@xxxxxxxxx>
- Date: Thu, 17 May 2007 18:09:38 -0400
"Anna" wrote:
We've been working with the Casper 4.0 disk cloning program
for about three months now and by & large we've been quite
impressed with this program. First of all, potential users should
note that this is a *disk cloning* program - not a disk imaging
program -
"Timothy Daniels" writes...
Has Casper changed? Casper XP could do either. - imaging
and cloning. I happily recently found out, though, that the
clone can be incrementally updated, as you have found with
Casper 4.0 ..
Anna's response...
As I've indicated, the Casper 4.0 program is a disk cloning program. Our
experience with Casper XP had been less than salutory since we ran into a
number of issues with that program in an XP environment and we stopped using
it some time ago, preferring to continue to use the Norton Ghost 2003
program and subsequently the Acronis True Image program.
"Anna" wrote:
Another positive feature we've discovered with the Casper 4.0
program - at least based on our experience to date - is that unlike
other disk cloning programs such as the Acronis & Ghost programs,
when the recipient of the clone - the destination HDD - is an
*internal* HDD, the user need not disconnect the source HDD
from the system and make an *initial* boot following the disk cloning
operation with only the destination HDD connected. Again, >> we're
referring here to a disk cloning operation where the recipient of >> the
clone (the "destination" drive) has been an *internal* HDD.
"Timothy Daniels" writes...
I think you're equating "internal" with IDE PATA/SATA, and
"external" with USB. Remember that SATA HDs can be put
into an external enclosure and run as if it were "internal" in every
way. And since very few BIOSes can boot from a USB HD,
can you really call a USB-resident copy of an OS a "clone"?
Anna responds...
I fully understand that a SATA HDD installed in a SATA-designed external
enclosure and using SATA-to-SATA connectivity between the enclosure & the
computer's motherboard's SATA (or eSATA) connector is considered an
*internal* HDD in that it retains all the capability of a "true" internal
HDD. It is, of course, one of the great advantages of using a SATA HDD in
that kind of hardware environment.
When a disk-cloning program, be it Casper, or Acronis, or Ghost, "clones"
the contents of the source disk to a destination disk such as a USB external
HDD, we consider the contents of the data now residing on the USBEHD a
"clone", albeit in an unbootable device to be sure. Whether the semantics
are right in this situation I don't know. We do know that cloning those
aforementioned contents residing on the USBEHD to an internal HDD will
create a bootable, functional internal HDD. As I believe you know, we prefer
(and encourage others as well) to equip our desktop PCs with removable HDDs
so that we get (in our opinion) the best of all worlds.
"Anna" wrote: As many of us know, there has been a problem with disk
cloning
programs in general with this situation in that if immediately following
the disk cloning operation both the (internal) source & destination HDDs
are connected and an *initial* boot is made to the >> source drive, there
can be a subsequent problem with the destination >> drive in that it will
fail to boot if at a later time when it is the only HDD connected.
"Timothy Daniels" writes...
The problem is with an initial boot to the *destination* drive - the
one containing the clone. It seems to randomly set some of its
file table entries to point to files in the "parent's" file structure
if it
can "see" its "parent". Editing the clone's files then end up as edits
to the "parent's" files. And when the "parent" partition is removed,
suddenly the clone can't find the files. But you can boot the "parent"
as much as you want with the clone visible to it, and no such
confusion of pointers occurs. That means that immediately after
the cloning operation, you can use the "parent" OS to edit files in
the clone - such as the clone's boot.ini file - with no problem. But
when it comes time to test the clone for the 1st time, hide the
"parent" OS in some way.
Anna responds...
Tim, as I thought I explained in my "treatise" - based on our experience to
date with the Casper 4.0 program (about three months now), we have yet to
run into that problem as we did with every disk cloning program we've used
in the past. We've probably performed more than one hundred disk cloning
operations over this time in a variety of systems using a variety of PATA -
SATA HDDs in various configurations. In every case immediately following the
disk-cloning operation, we booted the system with *both* drives (source &
destination) connected - something we ordinarily would not do with the other
disk cloning programs because of the (potential) problem I detailed and with
which you're familiar. In every case where we later booted to the
newly-cloned drive we did not encounter a boot problem as we sometimes
experienced with other disk cloning programs when both the source &
destination drives were still connected immediately following the
disk-cloning operation and a boot was made to the source HDD. I'm hopeful
that this unbroken string of successes will continue since this is a real
advantage to this program as compared with other disk-cloning programs.
Anna
.
- Follow-Ups:
- Re: second HD with drive image
- From: Timothy Daniels
- Re: second HD with drive image
- References:
- second HD with drive image
- From: Jud McCranie
- Re: second HD with drive image
- From: Timothy Daniels
- Re: second HD with drive image
- From: Anna
- Re: second HD with drive image
- From: Timothy Daniels
- second HD with drive image
- Prev by Date: Re: Making backups by just copying files
- Next by Date: Re: System Restore causes loss of data files.
- Previous by thread: Re: second HD with drive image
- Next by thread: Re: second HD with drive image
- Index(es):
Relevant Pages
|
