Setting up an external hard drive - partioning and sharing issues

"Bill in Co." wrote:

So my apologies to all of you for the misinformation.

Now that's better. Because (as you've said), the hand-holding was getting a
bit old. How's that sweater coming along?

Anna is the one who said "So my apologies...", not me.

I think you forgot your meds this afternoon.

Nurse Cratchett was looking for you.

Mike Torello wrote:
"Bill in Co." wrote:


I believe that when I put that to a test here a few months ago, Casper
saw EACH partition on the source drive separately and wanted to clone
EACH of those partitions to its OWN partition on the destination drive
and would NOT clone the entire multi-partitioned disk to a single
partition on the destination drive.

Obviously.

I can find that discussion if need be, but I believe that is what I
found.

You can't clone *multiple partitions* into ONE *partition*, per se. I
don't care what program you are using. Hello?

Say "Hello?" to Anna, you senile old coot. She's the one saying it
can be done.

It's actually cloned into unallocated space on the destination drive.
(Those details may be hidden from the user in some programs, but that's
what's happening).

IOW, if there was a partition over there on the destination drive, and you
told the program to "clone into that partition", it would first delete that
partition to make it "unallocated space", and THEN clone the source
partition(s) over to that space.

The only "exception" is that you can create logical partitions within an
"Extended Partition", obviously. But that's not what we're addressing
here.

"Bill in Co." wrote:

IOW, if there was a partition over there on the destination drive, and you
told the program to "clone into that partition", it would first delete that
partition to make it "unallocated space", and THEN clone the source
partition(s) over to that space

By Jove, I THINK HE'S FINALLY GOT IT!

Mike Torello wrote:
"Bill in Co." wrote:

IOW, if there was a partition over there on the destination drive, and
you
told the program to "clone into that partition", it would first delete
that
partition to make it "unallocated space", and THEN clone the source
partition(s) over to that space

By Jove, I THINK HE'S FINALLY GOT IT!

You mean you think YOU have it now. It's about time.

Anna,

Thank you for explaining in further detail how Casper accomplishes the task
of creating disk clones, how it achieves relatively quick performance, and
the rationale for using it.

Without any hands-on experience of any disk imaging or disk cloning program,
other than tools that ship with the operating system, I can see that both
approaches have advantages and disadvantages. This my assessment based on
the information provided in this thread:

A. Disc imaging approach
1. Since the disk image is a single file, we can back up multiple disks to a
single disk without having to partition the disk. The disk will simply
contain one image file for each source disk.
2, The size of the disk image file generated is approximately equal to the
volume of data on the source disk. Thus if the source disk has a capacity of
80 GB but only contains 3 GB of data, then the image file will be in the
region of 3GB in size. On the other hand, a disk clone must be created to
accommodate the full size of the source disk, in this case 80 GB.
3. The disk image file can be encrypted and/or compressed.
4. The disk image file is a file, not a bootable disk, so in the event of
the death of the source disk more work needs to be done to recover the data
from the image file to a bootable disk.
5. Multiple image files for a succession of back-ups can be accommodated in
a single disk/partition (of sufficient size).

B. Disk cloning approach
1. We need a separate disk or partition for each source disk or partition
that we wish to backup. Not suitable for maintaining a succession of
backups.
2. The disk clone, if on an external hard drive, may make private files
public, but cannot be easily encrypted.
3. The disk clone makes system restoration a breeze if on an internal HD.
4. Backup to a disk clone is very simple, because there are few choices to
be made.

I shall need to weigh up the pros and cons as they have a number of
implications! But the disk cloning approach does sound like an attractive
option!

Regards,

EM


"Anna" wrote in message
...


EM:
I was under the impression that in my previous posts re this thread I had
explained in some detail the *significant* advantage of the Casper 5
program (in my opinion, of course) over other disk-cloning (as well as
disk-imaging) programs in connection with Casper's so-called "SmartClone"
technology and how it (favorably) impacts on disk-to-disk (or
partition-to-partition) cloning speed when the program is used routinely &
frequently.

I trust you're *not* now asking me to provide you with some technical
treatise on how the program accomplishes this from a programming/design
point of view, but your question is really of the rhetorical kind, yes?

So let me try to answer this way based upon my experience with the program
involving some hundreds of disk (partition)-cloning operations...

The basic point of a disk-cloning program such as the one we highly
recommend - Casper 5 - is that by "cloning" the contents of one's
day-to-day working HDD to another HDD (internal or external), the user
creates a precise copy of his or her "source" HDD. Thus, a comprehensive
backup of one's system has been accomplished in one fell swoop, i.e., the
user has backed up his/her system including the operating system, all
programs & applications, and of course, all user-created data. In short -
*everything* that's on the "source" HDD. What better backup system can one
have?

While there are other disk-cloning programs (Acronis True Image is one)
that can perform this operation, Casper has a rather extroardinary ability
to create "incremental clones", using what Casper refers to as its
"SmartClone" technology. Understand that the "incremental clone" is a
complete clone of the source disk, not an "incremental file". 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.

As an example...

When a typical disk-cloning program undertakes its disk-to-disk cloning
process it does so without regard that the "source" and "destination" HDDs
involved in the disk-cloning operation are the *identical* drives that had
been involved when a prior disk-cloning operation had been undertaken. It
doesn't matter to the disk-cloning program whether the HDD now being
cloned was cloned an hour ago, or a day ago, or whenever. The "now"
disk-cloning operation will proceed as if the HDD recipient of the clone,
i.e., the destination HDD is bare of data, even if that same destination
HDD was the recipient of a prior clone from the same source HDD 10 minutes
ago.

As a result...

The disk-cloning operation will take a substantial amount of time to "do
its work" each time the disk-cloning operation is undertaken, without
regard to the fact that perhaps only a relatively few changes involving
the source HDD's data has changed since the last disk-cloning operation.
So, as an example, let's say it takes about 30 minutes or so to clone the
contents of a HDD containing 40 GB of data to another HDD. Two days later
the user decides to again back up his or her system by undertaking another
disk-cloning operation. Presumably the data changes over those two days
haven't been especially large. But with the typical disk-cloning program,
e.g., Acronis True Image, it will take the disk-cloning program just about
the *same* period of time to perform current the disk-cloning operation as
it did originally, i.e., 30 minutes in the preceding example. And so on
and so on in the following days.

But with the Casper 5 program, the program has the capability of
recognizing *only* the change in data that has occurred from its last
disk-cloning operation and will proceed to "do its work" on that basis.
Thus, given the example above it will probably take less than 3 or 4
minutes to complete the disk-cloning operation. And so on and so forth.

So you can see what a valuable incentive this is for users to
systematically & routinely backup their systems with the Casper 5
program - knowing that the expenditure of time to complete the
disk-cloning operation will be relatively slight. Surely this is a strong
incentive for a user to maintain his/her complete system in a reasonably
up-to-date fashion. Obviously the amount of time it will take to complete
this "incremental" disk-cloning operation with Casper will be dependent
upon the total volume of data being cloned as well as the additions,
deletions, configuration changes, etc. that had been made since the
previous disk-cloning operation. So the user is encouraged to perform
these disk-cloning operations on a relatively frequent basis since by
doing so the expenditure of time in completing the operation will be
relatively trifling. This last point is crucial. The program works best
when it is used with a fairly high degree of frequency - perhaps not less
than once a week or even on a daily or two or three times a week basis .
When it is used in that manner, the expenditure of time in completing the
disk (partition)-cloning operation comes close to being trifling.

A quick example based upon one of my PCs HDDs containing total data of
about 50 GB. Note this is *total* data - including the OS, all programs &
applications, all my user-created data - in short, *everything* that's on
that "source" HDD.

I last used the Casper 5 program to clone the contents of that drive four
days ago. Naturally, like most users, I've made changes of various kinds
over that four-day period. Added, deleted, modified some programs,
manipulated this or that configuration, etc., etc. More or less the
typical kinds of changes made by most users over a period of time. Earlier
today I again cloned the contents of that source HDD to one of my internal
HDDs. It took just about four (4) minutes. Four minutes.

And keep in mind that the recipient of that clone - the destination HDD -
will be a precise copy of the source HDD with all its data immediately
accessible in exactly the same way one would access data from their source
HDD - their day-to-day working HDD in most cases. And the destination HDD,
should it be an internal HDD or installed as a internal HDD from an
exterior enclosure will be immediately bootable without the need of any
recovery process.

So that if my source HDD becomes dysfunctional for any reason - I have at
hand a bootable HDD that will return my system to a functional state in
virtually no time at all. Had I cloned the contents of my source HDD to a
USB external HDD (instead of an internal HDD), I could restore my system
in reasonably short order by cloning the contents of the USBEHD back to an
internal HDD or, should the hard drive itself be removed from the external
enclosure it could then be installed as the system's internal HDD - fully
bootable & functional.

Again, what better backup system can one have?
Anna

"Anna" wrote in message
...
EM:
I was under the impression that in my previous posts re this thread I had
explained in some detail the *significant* advantage of the Casper 5
program (in my opinion, of course) over other disk-cloning (as well as
disk-imaging) programs in connection with Casper's so-called "SmartClone"
technology and how it (favorably) impacts on disk-to-disk (or
partition-to-partition) cloning speed when the program is used routinely
& frequently.

I trust you're *not* now asking me to provide you with some technical
treatise on how the program accomplishes this from a programming/design
point of view, but your question is really of the rhetorical kind, yes?

So let me try to answer this way based upon my experience with the
program involving some hundreds of disk (partition)-cloning operations...

The basic point of a disk-cloning program such as the one we highly
recommend - Casper 5 - is that by "cloning" the contents of one's
day-to-day working HDD to another HDD (internal or external), the user
creates a precise copy of his or her "source" HDD. Thus, a comprehensive
backup of one's system has been accomplished in one fell swoop, i.e., the
user has backed up his/her system including the operating system, all
programs & applications, and of course, all user-created data. In short -
*everything* that's on the "source" HDD. What better backup system can
one have?

While there are other disk-cloning programs (Acronis True Image is one)
that can perform this operation, Casper has a rather extroardinary
ability to create "incremental clones", using what Casper refers to as
its "SmartClone" technology. Understand that the "incremental clone" is a
complete clone of the source disk, not an "incremental file". 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.

As an example...

When a typical disk-cloning program undertakes its disk-to-disk cloning
process it does so without regard that the "source" and "destination"
HDDs involved in the disk-cloning operation are the *identical* drives
that had been involved when a prior disk-cloning operation had been
undertaken. It doesn't matter to the disk-cloning program whether the HDD
now being cloned was cloned an hour ago, or a day ago, or whenever. The
"now" disk-cloning operation will proceed as if the HDD recipient of the
clone, i.e., the destination HDD is bare of data, even if that same
destination HDD was the recipient of a prior clone from the same source
HDD 10 minutes ago.

As a result...

The disk-cloning operation will take a substantial amount of time to "do
its work" each time the disk-cloning operation is undertaken, without
regard to the fact that perhaps only a relatively few changes involving
the source HDD's data has changed since the last disk-cloning operation.
So, as an example, let's say it takes about 30 minutes or so to clone the
contents of a HDD containing 40 GB of data to another HDD. Two days later
the user decides to again back up his or her system by undertaking
another disk-cloning operation. Presumably the data changes over those
two days haven't been especially large. But with the typical disk-cloning
program, e.g., Acronis True Image, it will take the disk-cloning program
just about the *same* period of time to perform current the disk-cloning
operation as it did originally, i.e., 30 minutes in the preceding
example. And so on and so on in the following days.

But with the Casper 5 program, the program has the capability of
recognizing *only* the change in data that has occurred from its last
disk-cloning operation and will proceed to "do its work" on that basis.
Thus, given the example above it will probably take less than 3 or 4
minutes to complete the disk-cloning operation. And so on and so forth.

So you can see what a valuable incentive this is for users to
systematically & routinely backup their systems with the Casper 5
program - knowing that the expenditure of time to complete the
disk-cloning operation will be relatively slight. Surely this is a strong
incentive for a user to maintain his/her complete system in a reasonably
up-to-date fashion. Obviously the amount of time it will take to complete
this "incremental" disk-cloning operation with Casper will be dependent
upon the total volume of data being cloned as well as the additions,
deletions, configuration changes, etc. that had been made since the
previous disk-cloning operation. So the user is encouraged to perform
these disk-cloning operations on a relatively frequent basis since by
doing so the expenditure of time in completing the operation will be
relatively trifling. This last point is crucial. The program works best
when it is used with a fairly high degree of frequency - perhaps not less
than once a week or even on a daily or two or three times a week basis .
When it is used in that manner, the expenditure of time in completing the
disk (partition)-cloning operation comes close to being trifling.

A quick example based upon one of my PCs HDDs containing total data of
about 50 GB. Note this is *total* data - including the OS, all programs &
applications, all my user-created data - in short, *everything* that's on
that "source" HDD.

I last used the Casper 5 program to clone the contents of that drive four
days ago. Naturally, like most users, I've made changes of various kinds
over that four-day period. Added, deleted, modified some programs,
manipulated this or that configuration, etc., etc. More or less the
typical kinds of changes made by most users over a period of time.
Earlier today I again cloned the contents of that source HDD to one of my
internal HDDs. It took just about four (4) minutes. Four minutes.

And keep in mind that the recipient of that clone - the destination HDD -
will be a precise copy of the source HDD with all its data immediately
accessible in exactly the same way one would access data from their
source HDD - their day-to-day working HDD in most cases. And the
destination HDD, should it be an internal HDD or installed as a internal
HDD from an exterior enclosure will be immediately bootable without the
need of any recovery process.

So that if my source HDD becomes dysfunctional for any reason - I have at
hand a bootable HDD that will return my system to a functional state in
virtually no time at all. Had I cloned the contents of my source HDD to a
USB external HDD (instead of an internal HDD), I could restore my system
in reasonably short order by cloning the contents of the USBEHD back to
an internal HDD or, should the hard drive itself be removed from the
external enclosure it could then be installed as the system's internal
HDD - fully bootable & functional.

Again, what better backup system can one have?
Anna


"Enquiring Mind" wrote in message
...
Anna,

Thank you for explaining in further detail how Casper accomplishes the
task of creating disk clones, how it achieves relatively quick
performance, and the rationale for using it.

Without any hands-on experience of any disk imaging or disk cloning
program, other than tools that ship with the operating system, I can see
that both approaches have advantages and disadvantages. This my assessment
based on the information provided in this thread:

A. Disc imaging approach
1. Since the disk image is a single file, we can back up multiple disks to
a single disk without having to partition the disk. The disk will simply
contain one image file for each source disk.
2, The size of the disk image file generated is approximately equal to the
volume of data on the source disk. Thus if the source disk has a capacity
of 80 GB but only contains 3 GB of data, then the image file will be in
the region of 3GB in size. On the other hand, a disk clone must be created
to accommodate the full size of the source disk, in this case 80 GB.
3. The disk image file can be encrypted and/or compressed.
4. The disk image file is a file, not a bootable disk, so in the event of
the death of the source disk more work needs to be done to recover the
data from the image file to a bootable disk.
5. Multiple image files for a succession of back-ups can be accommodated
in a single disk/partition (of sufficient size).

B. Disk cloning approach
1. We need a separate disk or partition for each source disk or partition
that we wish to backup. Not suitable for maintaining a succession of
backups.
2. The disk clone, if on an external hard drive, may make private files
public, but cannot be easily encrypted.
3. The disk clone makes system restoration a breeze if on an internal HD.
4. Backup to a disk clone is very simple, because there are few choices to
be made.

I shall need to weigh up the pros and cons as they have a number of
implications! But the disk cloning approach does sound like an attractive
option!

Regards,

EM


EM:
By & large I think you've covered the basic differences between disk-cloning
& disk-imaging as they apply to creating a comprehensive backup system for
one's PC.

Just a few comments...

With respect to the disk-imaging approach (referring to your numbered items
above)...
1. Keep in mind that while the *original* disk-image (Acronis refers to it
as an "archive") created by the user is a single file, presumably the user
will be subsequently creating *incremental* files ("archives") necessary to
maintain up-to-date backups of one's system. Both the original file
(archive) and subsequent incremental files will ordinarily be retained until
either they're used for recovery purposes or the user decides the sheer
number of them is too unwieldy to continue and simply "starts over" by
creating a new "original" disk-image backup, deleting the existing
files/archives in the process.

While there's no need to create multiple partitions on the "destination"
drive to serve as the recipient of these disk-images, folders would
ordinarily be created to house the images from different "source" HDDs.

In any event, please do not attach too much importance to the issue of
creating partitions on the destination HDD either in terms of difficulty or
amount of time needed to do so. This is a very simple operation that can be
easily achieved through XP's Disk Management snap-in or using the Casper 5
program during its disk-cloning operation.

2. With respect to the disk-image, there will (usually) be a certain amount
of compression provided by the program so that the resultant file/archive
will be somewhat smaller than the actual size of the contents that are
imaged. In the case of the Acronis program we have generally found that this
reduction via compression is somewhat in the order of 20% - 25%. So, taking
your example, of 3 GB of contents being "imaged", the resultant file/image
would be about 2.5 GB or so.

But you've misunderstood this situation with respect to the disk-cloning
process. (Again, my comments refer specifically to the Casper 5 program)...

Again, using your example of an 80 GB HDD (or partition) that contains 3 GB
of data, as I previously explained, the user could easily create a partition
on the destination drive *equal* to the size of the data being cloned - in
this case, 3 GB. Or, he or she could create a larger size to anticipate
future increases in the size of data subsequently cloned. The choice of the
size of the partition rests with the user, the *only* limitation being that
the partition must be of sufficient size to contain the cloned contents.

And, of course, there is no compression of data using the disk-cloning
process. A clone is a clone is a clone.

It is true that in the usual scenario - where a user has a single day-to-day
working HDD (which probably represents the overwhelming number of cases) -
that user will employ the "destination" drive (internal or external) as the
dedicated recipient of the cloned contents of their source HDD and simply
create disk-to-disk clones and not be concerned in any way with partition
manipulation. In your situation where you're working with two different PCs
and apparently desire a single USBEHD to serve as the recipient of the data
from each of those two PCs, obviously the creation/manipulation of
partitions is important.

In many cases we find that where a user is working with both a
laptop/notebook and a desktop machine they simply use two separate drives to
serve as recipients of the clones from each machine. Given the dramatic
decreases in costs for these devices over the past few years it's not a
terribly expensive proposition for many users to go that route.

3. See above re the compression issue.

4. Yes, you have it right. There's a "recovery" process that is necessary,
but it's not particularly onerous or too terribly time-demanding. In any
event, what is important is that the process be *effective*, not the amount
of time it takes to return the system to a bootable, functional state. As I
have tried to point out in my previous posts, it is the routine *backup*
operation that's important from an expenditure of (user) time point-of-view.
Presumably, in the vast bulk of cases, the user will be performing scores,
if not hundreds, of backup operations before a recovery of the system will
become necessary. It's this extroardinary speed of the backup operation
(cloning) that makes the Casper 5 program so superior in my view. But as I
have emphasized the program must be used with reasonable frequency to
achieve this advantage.

5. Yes, I'm assuming you're referring to incremental disk-image files
(archives) here.

With respect to your observations re the disk-cloning process...

Yes, as I've previously indicated, should a user be primarily interested in
maintaining "generational" copies of his/her system at various
points-in-time, a disk-imaging program lends itself better to that goal.
While relatively few home PC users are interested in that objective, in that
they are exclusively interested in maintaining an up-to-date backup of their
system(s), many commercial entities require that capability for obvious
reasons.

While a disk-cloning program could be used to some extent for that purpose,
it would depend upon the volume of data to be cloned together with the size
(disk-space) of the destination drive(s). For example, we know of a number
of Casper 5 users who are interested in retaining 2, 3, or 4 previous clones
of their systems and in many cases this can be easily accommodated given the
enormous capacity of today's HDDs - both internal & external.

May I again suggest, as I've done throughout this entire thread, the only
*real* way to determine which program best meets your needs is to experiment
with them. In the final analysis, only a "hands-on" approach will determine
what's best for you. Fortunately, many of these programs have demo or trial
versions available so you can gain at least some understanding as to whether
this one or that one will best serve you. And, as you have discovered, there
are a number of freely available programs you can test out as well.

What I'm trying to impress upon you (and others) is simply this...

Don't rely on theoretical explanations (from me or anyone else) of what this
program or that program or this approach or that approach can do or not do
for you. Work with these different programs as best you can so that you -
and only you - will determine the appropriate approach/program needed in
your unique situation.
Anna

Anna,

Thanks again for your exhaustive and instructive post. Please see some
further comments embedded in the copy of your post.

"Anna" wrote in message
...



EM:
By & large I think you've covered the basic differences between
disk-cloning & disk-imaging as they apply to creating a comprehensive
backup system for one's PC.

Just a few comments...

With respect to the disk-imaging approach (referring to your numbered
items above)...
1. Keep in mind that while the *original* disk-image (Acronis refers to it
as an "archive") created by the user is a single file, presumably the user
will be subsequently creating *incremental* files ("archives") necessary
to maintain up-to-date backups of one's system. Both the original file
(archive) and subsequent incremental files will ordinarily be retained
until either they're used for recovery purposes or the user decides the
sheer number of them is too unwieldy to continue and simply "starts over"
by creating a new "original" disk-image backup, deleting the existing
files/archives in the process.

Thanks for the clear explanation. It's reassuring to know that it's not
necessary to create a new mammoth disk-image file at each back-up cycle.

While there's no need to create multiple partitions on the "destination"
drive to serve as the recipient of these disk-images, folders would
ordinarily be created to house the images from different "source" HDDs.

In any event, please do not attach too much importance to the issue of
creating partitions on the destination HDD either in terms of difficulty
or amount of time needed to do so. This is a very simple operation that
can be easily achieved through XP's Disk Management snap-in or using the
Casper 5 program during its disk-cloning operation.

It may be simple to do using XP's Disk Management snap-in , but I understand
that the data on the disk must be backed up beforehand because creating new
partitions using the snap-in deletes the files on the disk. Or is that no
longer the case?

2. With respect to the disk-image, there will (usually) be a certain
amount of compression provided by the program so that the resultant
file/archive will be somewhat smaller than the actual size of the contents
that are imaged. In the case of the Acronis program we have generally
found that this reduction via compression is somewhat in the order of
20% - 25%. So, taking your example, of 3 GB of contents being "imaged",
the resultant file/image would be about 2.5 GB or so.

But you've misunderstood this situation with respect to the disk-cloning
process. (Again, my comments refer specifically to the Casper 5
program)...

Again, using your example of an 80 GB HDD (or partition) that contains 3
GB of data, as I previously explained, the user could easily create a
partition on the destination drive *equal* to the size of the data being
cloned - in this case, 3 GB. Or, he or she could create a larger size to
anticipate future increases in the size of data subsequently cloned. The
choice of the size of the partition rests with the user, the *only*
limitation being that the partition must be of sufficient size to contain
the cloned contents.

This makes me wonder whether I have misunderstood what Casper does. I
thought that it creates a low level sector-by-sector copy of the source disk
on the destination disk without regard to the structure or meaning of the
data. But if we can clone a 80GB disk to a 3GB disk, this suggests that
Casper is not copying all raw data in the disk, but just the data in actual
files, since in the source disk the file data may be dispersed on sectors
that could be located anywhere on the disk (if the disk is highly
fragmented). So the low-level byte layout on the clone may be different to
that on the source. If Casper is backing up files only, this explains why
when Casper is doing an incremental back-up, it only needs to back up files
that have changed since the previous backup.

And, of course, there is no compression of data using the disk-cloning
process. A clone is a clone is a clone.

It is true that in the usual scenario - where a user has a single
day-to-day working HDD (which probably represents the overwhelming number
of cases) - that user will employ the "destination" drive (internal or
external) as the dedicated recipient of the cloned contents of their
source HDD and simply create disk-to-disk clones and not be concerned in
any way with partition manipulation. In your situation where you're
working with two different PCs and apparently desire a single USBEHD to
serve as the recipient of the data from each of those two PCs, obviously
the creation/manipulation of partitions is important.

In many cases we find that where a user is working with both a
laptop/notebook and a desktop machine they simply use two separate drives
to serve as recipients of the clones from each machine. Given the dramatic
decreases in costs for these devices over the past few years it's not a
terribly expensive proposition for many users to go that route.

3. See above re the compression issue.

4. Yes, you have it right. There's a "recovery" process that is necessary,
but it's not particularly onerous or too terribly time-demanding. In any
event, what is important is that the process be *effective*, not the
amount of time it takes to return the system to a bootable, functional
state. As I have tried to point out in my previous posts, it is the
routine *backup* operation that's important from an expenditure of (user)
time point-of-view. Presumably, in the vast bulk of cases, the user will
be performing scores, if not hundreds, of backup operations before a
recovery of the system will become necessary. It's this extroardinary
speed of the backup operation (cloning) that makes the Casper 5 program so
superior in my view. But as I have emphasized the program must be used
with reasonable frequency to achieve this advantage.

The rationale for backing up the whole system rather than just the user
settings and data seems to be that by so doing in the event of a disk
failure one can reboot directly from the backup disk and one is spared the
task of reinstalling all one's software and system settings. However, will
this really work? Some software programs use the serial number of the disk
as part of a license control system. So even though the restored files are
the same as on the original disk, the disk serial number has changed, so
some programs may not work without being reinstalled afresh.

5. Yes, I'm assuming you're referring to incremental disk-image files
(archives) here.

With respect to your observations re the disk-cloning process...

Yes, as I've previously indicated, should a user be primarily interested
in maintaining "generational" copies of his/her system at various
points-in-time, a disk-imaging program lends itself better to that goal.
While relatively few home PC users are interested in that objective, in
that they are exclusively interested in maintaining an up-to-date backup
of their system(s), many commercial entities require that capability for
obvious reasons.

While a disk-cloning program could be used to some extent for that
purpose, it would depend upon the volume of data to be cloned together
with the size (disk-space) of the destination drive(s). For example, we
know of a number of Casper 5 users who are interested in retaining 2, 3,
or 4 previous clones of their systems and in many cases this can be easily
accommodated given the enormous capacity of today's HDDs - both internal &
external.

May I again suggest, as I've done throughout this entire thread, the only
*real* way to determine which program best meets your needs is to
experiment with them. In the final analysis, only a "hands-on" approach
will determine what's best for you. Fortunately, many of these programs
have demo or trial versions available so you can gain at least some
understanding as to whether this one or that one will best serve you. And,
as you have discovered, there are a number of freely available programs
you can test out as well.

What I'm trying to impress upon you (and others) is simply this...

Don't rely on theoretical explanations (from me or anyone else) of what
this program or that program or this approach or that approach can do or
not do for you. Work with these different programs as best you can so that
you - and only you - will determine the appropriate approach/program
needed in your unique situation.
Anna
Good advice, but it is nevertheless prudent to understand what you are doing
before doing too much experimentation!

May I add another back up option to the disk-imaging and disk-cloning
options discussed so far? The third option is to simply maintain a parallel
copy of the source folder and file structure on the back-up disk (like
offline files between a laptop and a desktop).

This option offers the following advantages and disadvantages:
1) If the synchronization between the source and back-up folders is
performed by a specialised application, the files in the back-up folder may
be password protected and/or individually compressed, thus guaranteeing the
privacy of the content of a medium which gets no privacy protection
whatsoever from the computer, being an external device connectable to any
computer.
2) The synchronization application can minimise the number of files that
have to be copied during the backup operation by using the file's Archive
flag or Time Last Modified to determine whether or not it needs to be backed
up. This means that the time needed to complete a backup cycle may be no
longer than a couple of minutes even for a large number of files.
3) There's no need for partitioning the back-up drive. Partitions are in
principle a great aid, but limit flexibility to change source drives in the
future. The folders on the back-up device can grow in size without causing a
lot of disk activity. The same can't be said for the disk imaging option.
4) The owner of the back-up data can browse the file names in Windows
Explorer.
5) The files can be restored on folder or file basis.
6) Because the backup process never needs to delete mammoth archive files,
but only relatively small individual files, the disk should not become too
fragmented, and it may be defragmented relatively infrequently.
7) There is less wear and tear of the disk drives.
8) The disadvantage is that somebody could accidentally delete or modify
some of the files in the back-up folder, thereby rendering the back-up
folder no longer a true image of the source folder.

When I recently used the Windows XP Pro Backup utility to make a copy of
"All information on the computer", I was horrified to see that not only did
it back up all the files on the internal drives of the computer, but also
all the files on the external hard drive to which I was backing up (except
the back-up file I was creating, of course)! This meant that the monolithic
back up file also contained copies of all the previous back-up files on the
EHD, making it MUCH larger and more cumbersome than necessary! I suppose
this is the sort of thing that creates a market for third party tools like
Casper and Acronis True Image.

Regards,

EM

Enquiring Mind wrote:
Anna,

Thanks again for your exhaustive and instructive post. Please see some
further comments embedded in the copy of your post.

"Anna" wrote in message
...



snip

This makes me wonder whether I have misunderstood what Casper does. I
thought that it creates a low level sector-by-sector copy of the source
disk
on the destination disk without regard to the structure or meaning of the
data. But if we can clone a 80GB disk to a 3GB disk, this suggests that
Casper is not copying all raw data in the disk, but just the data in
actual
files, since in the source disk the file data may be dispersed on sectors
that could be located anywhere on the disk (if the disk is highly
fragmented). So the low-level byte layout on the clone may be different to
that on the source. If Casper is backing up files only, this explains why
when Casper is doing an incremental back-up, it only needs to back up
files
that have changed since the previous backup.

Partition copying programs often give you the option of either doing a
complete sector-by-sector partition copy of ALL the sectors (useful for
making an EXACT duplicate), OR just the sectors containing data. I believe
most default to the latter.

Enquiring Mind wrote:
Anna,

Thanks again for your exhaustive and instructive post. Please see some
further comments embedded in the copy of your post.

"Anna" wrote in message
...

snip

This makes me wonder whether I have misunderstood what Casper does. I
thought that it creates a low level sector-by-sector copy of the source
disk
on the destination disk without regard to the structure or meaning of the
data. But if we can clone a 80GB disk to a 3GB disk, this suggests that
Casper is not copying all raw data in the disk, but just the data in
actual
files, since in the source disk the file data may be dispersed on sectors
that could be located anywhere on the disk (if the disk is highly
fragmented). So the low-level byte layout on the clone may be different
to
that on the source. If Casper is backing up files only, this explains why
when Casper is doing an incremental back-up, it only needs to back up
files
that have changed since the previous backup.


"Bill in Co." wrote in message
...
Partition copying programs often give you the option of either doing a
complete sector-by-sector partition copy of ALL the sectors (useful for
making an EXACT duplicate), OR just the sectors containing data. I
believe most default to the latter.


Gentlemen: (I'm assuming "EM" is of the male gender; my apologies should I
be mistaken)...

As that trite saying goes, "with all due respect", but nevertheless, with
all due respect...

I really think it clouds the issue when phrases are bandied about such as
"low level sector-by-sector copy...", or "low-level byte layout", or
"sectors containing data", or "copying all raw data in the disk" and the
like.

First of all, with specific reference to the Casper 5 disk-cloning
program...

We are *not* cloning "a 80GB disk to a 3GB disk". What I explained, (or
tried to explain) was that if the source drive's 80 GB partition contained 3
GB of data, the user could, should he or she desire, set the partition on
the destination drive to be equal in size to the contents being cloned - in
this case 3 GB. Using Casper 5, there is no *requirement* that this be done,
nor is it the default. The user could establish a partition of 10 GB, or 30
GB or 50 GB or the precise size of the source drive's partition, i.e., 80 GB
(or even larger should the user desire such for one reason or another). I
was making the point (or trying to make the point) that the only size
requirement re the destination partition is that, at the *minimum*, it be
sufficient in size to contain the cloned data contents.

Bill,
Emphasizing that my remarks pertain to the Casper 5 program...

With the understanding that I am substituting "partition(s)" for
"sector(s)"...

I trust you understand that a partition on the source drive containing *no*
data can be cloned to the destination drive. There is *no* requirement that
the source partition contain data; it can be completely void of data and
still be cloned.

This situation happens from time-to-time with many users in my experience.
Again, in my experience, the overwhelming number of Casper 5 users (and I
daresay users of other disk-cloning programs) simply dedicate another HDD -
either an internal HDD or a USB external HDD - to serve as the recipient of
their day-to-day internal HDD.

Putting it simply - they clone the entire contents of their source HDD to a
destination HDD without regard to partition-to-partition cloning. Simple,
direct, effective. All they require is that the destination HDD - the
recipient of the clone - be a precise duplicate of their source HDD.

Naturally as I'm sure you know, many users' source drives contain multiple
partitions. Some users prefer a single partition for the OS, another for
programs, another for personal data of one kind or another, for games, etc.,
etc.

So let's say the user's source 300 GB HDD contains four partitions, C, D, E,
& F. He or she routinely clones the contents of the source HDD to a 500 GB
USBEHD.

In most cases the user will simply undertake a disk-to-disk cloning
operation without giving any consideration to sizing the partitions on the
destination HDD. Again, all that the user is interested in is that he/she
has a precise copy of the *total* contents of their source HDD so that
restoration of their systems can be achieved easily & effectively.

Without user intervention Casper 5 will simply automatically proportion the
size of the destination partitions based upon corresponding size of the
source HDD's partitions. So that if, for example, the size of the source
drive's C: partition represents
10% of the total disk space of the source drive, then the destination
partition will similarly be set at 10% of the total disk space of the
destination drive. And so on & so on. But again, should a user desire to
manipulate the size of the destination partitions, that option is open to
him/her during the cloning process.

And should one of the partitions on the source HDD be vacant of data -
perhaps the user has deleted all previous data but still desires the
existence of that partition for some future use - that empty source drive's
partition will be cloned along with the other partitions on the source
drive. Again, it will be sized proportionally unless the user desires
otherwise.

I recognize the preceding scenario does not apply to all users; the OP's
situation where he/she has two PC's and desires to use a single destination
drive to house the contents of those two machines is a case in point. And
obviously there are other situations involving a need for
partition-to-partition cloning.
Anna

Anna wrote:
Enquiring Mind wrote:
Anna,

Thanks again for your exhaustive and instructive post. Please see some
further comments embedded in the copy of your post.

"Anna" wrote in message
...

snip

This makes me wonder whether I have misunderstood what Casper does. I
thought that it creates a low level sector-by-sector copy of the source
disk
on the destination disk without regard to the structure or meaning of
the
data. But if we can clone a 80GB disk to a 3GB disk, this suggests that
Casper is not copying all raw data in the disk, but just the data in
actual
files, since in the source disk the file data may be dispersed on
sectors
that could be located anywhere on the disk (if the disk is highly
fragmented). So the low-level byte layout on the clone may be different
to
that on the source. If Casper is backing up files only, this explains
why
when Casper is doing an incremental back-up, it only needs to back up
files that have changed since the previous backup.


"Bill in Co." wrote in message
...
Partition copying programs often give you the option of either doing a
complete sector-by-sector partition copy of ALL the sectors (useful for
making an EXACT duplicate), OR just the sectors containing data. I
believe most default to the latter.


Gentlemen: (I'm assuming "EM" is of the male gender; my apologies should I
be mistaken)...

As that trite saying goes, "with all due respect", but nevertheless, with
all due respect...

I really think it clouds the issue when phrases are bandied about such as
"low level sector-by-sector copy...", or "low-level byte layout", or
"sectors containing data", or "copying all raw data in the disk" and the
like.

Well, I agree some of it can perhaps sometimes be overstated.
But I think using the phrase "sector-by-sector copy" is usefully definitive
(at least to me), as in stark contrast to, say, folder and file copying, for
example; there is a truly SIGNIFICANT difference there, and I think it's
useful at to understand it at that level. More on that below.

First of all, with specific reference to the Casper 5 disk-cloning
program...

We are *not* cloning "a 80GB disk to a 3GB disk". What I explained, (or
tried to explain) was that if the source drive's 80 GB partition contained
3
GB of data, the user could, should he or she desire, set the partition on
the destination drive to be equal in size to the contents being cloned -
in
this case 3 GB. Using Casper 5, there is no *requirement* that this be
done,
nor is it the default. The user could establish a partition of 10 GB, or
30
GB or 50 GB or the precise size of the source drive's partition, i.e., 80
GB
(or even larger should the user desire such for one reason or another). I
was making the point (or trying to make the point) that the only size
requirement re the destination partition is that, at the *minimum*, it be
sufficient in size to contain the cloned data contents.

Bill,
Emphasizing that my remarks pertain to the Casper 5 program...

With the understanding that I am substituting "partition(s)" for
"sector(s)"...

I trust you understand that a partition on the source drive containing
*no*
data can be cloned to the destination drive. There is *no* requirement
that
the source partition contain data; it can be completely void of data and
still be cloned.

I absolutely understand. :-)

But as I said, regardless of the specific program being used, IF it allows
for partition-to-partition copying, there is often the choice of only
copying those sectors with data, OR copying the entire partition structure
literally and faithfully to a destination drive (which can be required in
certain cases, as in forensic work, as someone else mentioned). And as an
EE, it's just kinda natural for me to try to see and understand it from that
level.

This situation happens from time-to-time with many users in my experience.
Again, in my experience, the overwhelming number of Casper 5 users (and I
daresay users of other disk-cloning programs) simply dedicate another
HDD -
either an internal HDD or a USB external HDD - to serve as the recipient
of
their day-to-day internal HDD.

Putting it simply - they clone the entire contents of their source HDD to
a
destination HDD without regard to partition-to-partition cloning. Simple,
direct, effective. All they require is that the destination HDD - the
recipient of the clone - be a precise duplicate of their source HDD.

Naturally as I'm sure you know, many users' source drives contain multiple
partitions. Some users prefer a single partition for the OS, another for
programs, another for personal data of one kind or another, for games,
etc.,
etc.

So let's say the user's source 300 GB HDD contains four partitions, C, D,
E,
& F. He or she routinely clones the contents of the source HDD to a 500 GB
USBEHD.

In most cases the user will simply undertake a disk-to-disk cloning
operation without giving any consideration to sizing the partitions on the
destination HDD. Again, all that the user is interested in is that he/she
has a precise copy of the *total* contents of their source HDD so that
restoration of their systems can be achieved easily & effectively.

Without user intervention Casper 5 will simply automatically proportion
the
size of the destination partitions based upon corresponding size of the
source HDD's partitions. So that if, for example, the size of the source
drive's C: partition represents
10% of the total disk space of the source drive, then the destination
partition will similarly be set at 10% of the total disk space of the
destination drive. And so on & so on. But again, should a user desire to
manipulate the size of the destination partitions, that option is open to
him/her during the cloning process.

And should one of the partitions on the source HDD be vacant of data -
perhaps the user has deleted all previous data but still desires the
existence of that partition for some future use - that empty source
drive's
partition will be cloned along with the other partitions on the source
drive. Again, it will be sized proportionally unless the user desires
otherwise.

I recognize the preceding scenario does not apply to all users; the OP's
situation where he/she has two PC's and desires to use a single
destination
drive to house the contents of those two machines is a case in point. And
obviously there are other situations involving a need for
partition-to-partition cloning.
Anna

I dont know if this will help, but I bought a Seagate 80GB external device
specificaly to download a mmorpg game onto because pc didnt have enough
memory to to it straight to pc. I think the security would be excelent
because I couldn't access game without the device turned on, or even
connected. as for encripted files, I have no Idea. The game is still
on the device altho it has been upplugged from the pc and all. yu could
put stuff on it then put the thing in a vault or something. thing is it
can be accessed from other pc if yu know how to do it. I dont. my son
does.

yours A true Newb

"Enquiring Mind" wrote:

Hi,

I recently purchased an external hard drive with a view to storing back up
copies of the files on the 3 hard drives on my 2 computers, one computer
having 2 internal hard drives (1 FAT32, 1 NTFS), and the other 1 NTFS
internal hard drive. I would appreciate any guidance on how best to set up
the external hard drive for this purpose, whilst maintaining the security
attributes of the source files. My first thought was to create 5 separate 80
GB logical partitions on the external hard drive, and utilise 3 of these as
destinations for the back-up copies of the 3 source hard drives on my
computers. There are a few questions that I am uncertain about, though:

1) Given that the external hard drive has a capacity of 500 GB, is there
anything to be gained by subdividing it into multiple partitions?

2) The external hard drive came preformatted as a single NTFS drive. When I
right click on it the Windows XP Disk Management window with a view to
creating new logical drives the context menu that pops up contains "Delete
partition ...", not "New logical drive". Does this mean that in order to
create the logical partitions that I require I must first delete the
existing partition, then create the logical partitions starting from
scratch?

2) I would like to make the back up copy of the folder "Documents and
Settings/User A" private to user A of computer C1, so that even though it's
on the external hard drive it can only be opened when the hard drive is
connected to computer C1 and the user logged in to computer C1 is user A.
However when calling up the Sharing property sheet for any folder on the
external hard drive the "Make this folder private" check box is greyed out.
Does this mean that it's not possible to make a folder on an external hard
drive private to a specific user of a specific computer?

3) The files that I wish to back up include files encrypted using NTFS file
encryption. I have previously discovered that it's not possible to transfer
encrypted files between a private folder and a shared folder and then back
again without the files being decrypted along the way, and the "Last
Modified" timestamp being updated. Can this problem be avoided when backing
up files on a file by file basis?

Thanks for any guidance on these issues.

EM