(SNIP)
Well, that's a bit of a pain!
Bill:
True, it is a "pain", but not so with Casper where that problem simply
doesn't exist. The problem (or potential problem) we and others have found
with disk-cloning programs in general is this...
Should the user boot with both drives connected immediately following the
disk-cloning operation, the system *will* boot to their source HDD,
presumably the C: drive. But subsequently when the user attempts to later
boot with *only* the destination HDD connected - let's say for restoration
purposes - there's a strong possibility the system will not boot with *only*
that HDD connected.
This is the more-or-less typical situation where the user clones the
contents of his/her source HDD to another *internal* HDD. Following the
disk-cloning operation the user boots to his/her source HDD with the cloned
HDD still connected. At a later date when the user desires to restore
his/her system from the cloned HDD because the source HDD has become
defective or the OS has become corrupt & dysfunctional, the user finds that
the system will not boot What happens with some frequency is that when both
HDDs are connected *immediately* following the disk-cloning operation and
the user boots the system, a drive letter other than C: is assigned to the
destination HDD. This other-than-C: drive letter remains permanently
assigned to the destination HDD. So that if later the user attempts to boot
to that HDD that is solely connected to the system, it will not boot since
the XP OS will not see it as the boot drive. (A number of commentators have
indicated a registry modification can be employed to correct this problem,
i.e., assign a C: drive letter to the HDD, but we have not found this a
workable solution).
Interestingly, if the user disconnects the source HDD immediately following
the disk-cloning operation and makes that initial boot *only* with the
destination HDD connected, there will be no subsequent problems booting to
that HDD even if later the user boots the system to their source HDD while
the destination HDD is also connected. Alternatively, the user can
disconnect the cloned HDD from the system and boot only with the source HDD
connected. I realize that the latter is probably not the most desirable way
to go since it doesn't give the user definitive infomation that the clone
"took". So all in all it would probably be better if the user disconnects
the source HDD immediately following the disk-cloning operation and boot
directly to the newly-cloned disk.
The reason I’ve stated that the above is a “potential problem” is that the
scenario I’ve described doesn't always happen. In many cases it simply
doesn't matter whether *both* source & destination HDDs are connected
immediately following the disk-cloning operation. In those cases the
destination HDD will later boot without any problem. But it's something of a
crap-shoot and that's why I generally recommend booting *only* to the
destination HDD (the recipient of the clone) immediately following the
disk-cloning operation (or disconnecting the newly-cloned HDD from the
system). Symantec & Acronis also recommended this procedure in the past. I
don't know if the Acronis v11 program has changed things.
As I've indicated, this problem or potential problem doesn't exist with the
Casper disk-cloning program. At least we've never run into it involving
hundreds of disk-cloning operations with both internal HDDs connected
following the disk-cloning operation. We've *always* found that the
"destination" (cloned) HDD will later boot without any problem. It's another
reason we prefer Casper over the other disk-cloning programs.
(Note the problem described above does not exist when using a USB or
Firewire external hard drive as the recipient of the clone since those
devices are not bootable. Using an external HDD as the destination drive
avoids the need for the disconnect/connect scenario described above. And
there is, of course, another advantage to using a USB or Firewire external
HDD as the destination drive (rather than another internal HDD) in that an
additional safety factor is provided since the external drive will
ordinarily be disconnected from the system except during disk-cloning
operations. Restoration of the system can be achieved by cloning the
contents of the system residing on the external HDD to a internal HDD
through the normal disk-cloning process.)
Anna
Somewhat relatedly....
Is it possible to use Casper (or TI) to store partition backups of the C:
system drive partition on the main hard drive *AND* have (at least read
only) access to the files there, via windows explorer?
As I recall, at least with True Image, you cannot do that (have full
access - it's stored in a special "Secure Zone" if you're storing the
system backups on the same drive, and windows explorer won't work there,
or allow you see what is in there, *unlike* if it's stored on an external
backup drive).
The reason I ask is it sure would be nice to make use of the extra space
I've got left on my HD, instead of filling up the much smaller external
one with my system backups all the time.
Bill:
I may be misunderstanding your question, but let me respond this way...
As I'm sure you know based upon our previous exchange of posts concerning
various aspects of the Casper (and Acronis) program, Casper can clone
individual partitions as well as create complete disk-to-disk clones. So, in
your example, should the user desire to clone *only* the contents of their
source drive's C: partition to this or that partition on the "destination"
HDD, and *not* clone any other partition(s) on their source HDD, he or she
can do that. Since the resulting cloned contents of that partition now
residing on the destination HDD are a precise copy of the contents of the
source drive's C: partition, then naturally those contents (files/folders,
etc.) can be accessed via Windows Explorer. But I'm reasonably sure you
already know this so that's why I'm uncertain I truly understand your
question.
Anna