View Single Post
  #180  
Old January 29th 09, 11:49 PM posted to microsoft.public.windowsxp.basics,microsoft.public.windowsxp.help_and_support
Twayne[_2_]
external usenet poster
 
Posts: 4,276
Default Using Casper 5 disk-cloning program to clone multi-partitioned HDD

"Anna" wrote:
In any event, to avoid complications arising
out of
partition-to-partition type cloning
operations, it's
usually best to clone the *entire* contents of
one's source HDD to the destination HDD. So
that when
the need arises to restore the system a simple
disk-to-disk reverse cloning operation is all
that's
needed.



"Mike Torello" wrote in
message
news
So... what was all that about how to clone a
drive/disk
to a single partition, and then doing it again
later to
another partition... so that one could keep
"generational copies"??



As I've indicated, for a variety of reasons, not
the
least of which impacts on the disk-cloning
process, we
generally encourage users to create a
single-partitioned
source HDD rather than a multi-partitioned disk
and
organize their contents on a folder-by-folder
basis
rather than on a partition-by-partition basis.
Having a single-partitioned source HDD does
facilitate
the disk-cloning process when the user is
particularly
interested in maintaining "generational" copies
of his or
her system. So that the user can clone the
contents of
his/her source HDD at different points-in-time
to their
destination HDD (the recipient of the clones)
and each
created partition on the destination drive will
mirror
their source drive's contents at that particular
point-in-time.
Remember that as long as the destination HDD has
sufficient unallocated disk space the user can
create as
many generational clones as the destination
drive can
accommodate.
Where the user has a multi-partitioned source
HDD the
cloning process becomes a bit more complicated
since now
the user must clone each partition on the source
HDD
(assuming that's what he or she wants to do,
i.e.,
include *all* the partitions on their source
HDD) to the
destination HDD. While there's little problem in
doing
that, it does mean that the destination HDD will
contain
a multitude of partitions and depending upon the
sheer
number of generational copies of the user's
system he or
she wants to retain, this can be a bit unwieldy.
But as long as the user properly labels each
destination
partition so that he or she can later easily
identify the
date each partition was created there should be
no
problem in later determining which partition(s)
the user
needs to restore his/her system as of a
particular date.
So, for example, if the user's source HDD had
three
partitions - C:, E: & F:, and the user cloned
those
partitions to their destination HDD today -
1-29, the
user might want to label those three cloned
partitions on
the destination drive "C: 1-29", "E: 1-29", "F:
1-29" and
so on & so on. Not particularly difficult, nor
terribly
time-consuming but some sort of identification
label for
each partition would be called for.
Again, as I've previously indicated, the
*actual* drive
letter assignments on the destination HDD are of
no
consequence here. When, for example, the user
needs to
restore his/her system with the three
partition-clones
created on 2-5 because the user's source HDD has
become
defective and is no longer usable, he or she
will simply
clone those three partitions on the destination
HDD
(ensuring of course, that they're the correct
three 2-5
clones) to a new HDD. The appropriate source
drive
letters will be properly assigned by the system
regardless of how the destination HDD had
assigned drive
letters to those partitions. Anna


Wow; Anna, you're just 'amazing'. You should go
away and attempt to make some of your rhetoric
work so you can quit contradicting yourself and
mixing up your terminology. Take notes and make
them clear and concise. Or find something better
to spend your time on.
I'm a closet sociologist at heart and this has
been a great case sampling. No, I'm not imparting
a label to it; just watching the revisions and
related talents.



Ads