Re: Replacing hard drive
- From: "Anna" <myname@xxxxxxxxx>
- Date: Fri, 11 Jul 2008 10:36:44 -0400
Anna wrote:
(SNIP)
Anna wrote: (SLIGHTLY EDITED)...
However, if you use the Acronis disk-cloning program for routine backup
operations so that the 180 GB HDD (as the recipient of the clone) is
potentially bootable following the disk-cloning operation, it's a wise
precaution to disconnect the newly-cloned drive following the
disk-cloning
operation and boot directly to your usual boot drive, i.e., the 500 GB
HDD, i.e., the "source" drive - the one being cloned. Then reconnect
the 180 GB HDD, i.e., the "destination" drive - the recipient of the
clone,
when next you undertake a disk-cloning operation.
Anna
"Bill in Co." wrote
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 information
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
Anna wrote:
The preceding is unnecessary if the secondary HDD is being used
as a USB external HDD or if you're using the Casper disk-cloning
program; it's one of Casper's other advantages over Acronis in our
view.
Anna
"Bill in Co." wrote
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
"Bill in Co." <not_really_here@xxxxxxxxxxxxx> wrote in message
No, I was talking about the case of just having one internal hard drive
AND trying to use it to store some additional backups of the C: partition,
but tucked away somewhere (within another partition on the main drive).
The advantage being: IF you wanted to test out some programs and found
you didn't like what it did, you could simply restore a backup *from the
same drive*, and yet STILL have some access to the files in those backups
(at least being able to see them in Windows Explorer).
As I mentioned, if you use Acronis True Image to do this (i.e., store
image backups on the same drive as your system drive), you HAVE to use a
hidden "Secure Zone" partition to store them, and then apparently you can
NOT have any access to their contents using windows explorer, nor can you
view all the files within it (unlike if you use an external hard drive)
This does NOT apply, of course, if you use an external backup drive, as I
have been doing. But I sure have a LOT of wasted empty space on my
main drive that could be put to better use by doing this, by "off loading"
some of the burden of using my external drive backups for tests (but of
course, having an external backup drive is best).
Bill:
Yes, now I understand your question. Yes, Casper does have the capability
you're seeking. It can clone the contents of a partition on the "source"
HDD to another partition on the *same* source HDD. Obviously the "recipient"
partition would need to be large enough to contain those cloned contents.
And
those cloned contents would be accessible via Windows Explorer, etc. just
like
any other contents residing on the HDD.
Like you, we test out many different programs, however we prefer to install
these programs on a separate HDD, not on our day-to-day working HDD. The
problem (as we see it) in installing these new, untested programs on one's
boot HDD is that more often than not we find these programs unsatisfactory
for one reason or another (as I'm reasonably sure you've experienced the
same thing), and even when they're subsequently uninstalled they frequently
leave behind unwanted "debris" cluttering up the registry as well as other
areas of one's PC. Then too, some of these programs cause mischief of one
kind or another while they're in use even to the point of creating a
dysfunctional HDD. So one of the significant advantages of using a
disk-cloning program is that one can "play around" with another (cloned)
HDD, secure in the knowledge that their day-to-day HDD will not be adversely
affected by any problem brought about by installing & using this or that new
program. The recent problems many users have experienced re installing SP3
is an illustration of the advantage of installing a major program on one's
cloned (physically separated) HDD. (It's also another major reason why we
promote
the use of removable hard drives for desktop PCs whenever possible).
Anna
"Bill in Co." <not_really_here@xxxxxxxxxxxxx> wrote in message
news:OPNbAwv4IHA.3484@xxxxxxxxxxxxxxxxxxxxxxx
Anna wrote:
(SNIP)
Anna wrote: (SLIGHTLY EDITED)...
However, if you use the Acronis disk-cloning program for routine backup
operations so that the 180 GB HDD (as the recipient of the clone) is
potentially bootable following the disk-cloning operation, it's a wise
precaution to disconnect the newly-cloned drive following the
disk-cloning
operation and boot directly to your usual boot drive, i.e., the 500 GB
HDD, i.e., the "source" drive - the one being cloned. Then reconnect
the
180 GB HDD, i.e., the "destination" drive - the recipient of the clone,
when next you undertake a disk-cloning operation.
Anna
"Bill in Co." wrote
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
Anna wrote:
The preceding is unnecessary if the secondary HDD is being used
as a USB external HDD or if you're using the Casper disk-cloning
program;
it's one of Casper's other advantages over Acronis in our view.
Anna
"Bill in Co." wrote
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
No, I was talking about the case of just having one internal hard drive
AND trying to use it to store some additional backups of the C: partition,
but tucked away somewhere (within another partition on the main drive).
The advantage being: IF you wanted to test out some programs and found
you didn't like what it did, you could simply restore a backup *from the
same drive*, and yet STILL have some access to the files in those backups
(at least being able to see them in Windows Explorer).
As I mentioned, if you use Acronis True Image to do this (i.e., store
image backups on the same drive as your system drive), you HAVE to use a
hidden "Secure Zone" partition to store them, and then apparently you can
NOT have any access to their contents using windows explorer, nor can you
view all the files within it (unlike if you use an external hard drive)
This does NOT apply, of course, if you use an external backup drive, as I
have been doing. But I sure have a LOT of wasted empty space on my
main drive that could be put to better use by doing this, by "off loading"
some of the burden of using my external drive backups for tests (but of
course, having an external backup drive is best).
.
- Follow-Ups:
- Re: Replacing hard drive
- From: Bill in Co.
- Re: Replacing hard drive
- References:
- Replacing hard drive
- From: m32
- Re: Replacing hard drive
- From: Big_Al
- Re: Replacing hard drive
- From: m32
- Re: Replacing hard drive
- From: Big_Al
- Re: Replacing hard drive
- From: Anna
- Re: Replacing hard drive
- From: m32
- Re: Replacing hard drive
- From: Anna
- Re: Replacing hard drive
- From: Bill in Co.
- Re: Replacing hard drive
- From: Anna
- Re: Replacing hard drive
- From: Bill in Co.
- Replacing hard drive
- Prev by Date: Re: SATA drive not recognized
- Next by Date: All my folder in my harddisk change to folder.exe
- Previous by thread: Re: Replacing hard drive
- Next by thread: Re: Replacing hard drive
- Index(es):
Relevant Pages
|