Can't boot. Trying recovery console. How long to 'examine disk'?

Bill in Co.

Anna wrote:
> (The issue here is Bill's questioning as to the effectiveness of a
> disk-cloning program vs. a disk-imaging program for the purpose of
> restoring
> a system, presumably because of a defective HDD or a corrupted or
> otherwise
> dysfunctional HDD).

Right. More below...

> "Bill in Co." <> wrote in message
> news:%.gbl...
>> Well, not so relatively rare for me, as I often try things out, and then
>> find I want to go back to a clean system. THAT is my main use. So
>> maybe that's the point that was overlooked here (my apologies for the
>> misunderstanding). I mess around with my system quite a bit, trying out
>> various software programs, and sometimes find I want to go back to a
>> clean
>> system, and use the image restore capability of TI to do that, and not
>> all
>> that infrequently! THAT was my point.
>>
>> And, if I understand this right, using a disk *cloning* program just to
>> do
>> that (i.e., NOT with the primary intent of *making a bootable backup
>> drive*) is a bit "tangential" to its main purpose - since with a
>> *cloning*
>> program like Casper, you would always be recloning the backup partition
>> BACK to the source drive partition for a restore operation, IF you intend
>> to use this program as I have indicated. Is that not correct?
>>
>> But also, as I understand it, you CAN do that restore operation with
>> Casper (for JUST the C: partition) on a multi-partition drive, by
>> recloning that partition (previously cloned over to the external USB
>> drive) BACK to the source drive partition (replacing it after rebooting).
>>
>> But it seems to me that the normal method for this purpose (of what I use
>> it for - testing out programs, and restoring a backup) would be imaging.
>
>
> Bill:
> Let me say, as I've said repeatedly, that I have no problem with those
> users
> who prefer a disk-imaging program for backup/restoration purposes rather
> than a disk-cloning program such as the Casper program I've been
> recommending. But it's my belief that as a general proposition for the
> vast
> majority of PC users the disk-cloning approach is a more practical
> approach
> for establishing & maintaining a comprehensive backup system that will be
> used on a routine basis.
>
> Getting to your specific points...
>
> There is *no* problem - *no* obstacle in using a disk-cloning program for
> the purpose you have indicated, i.e., "(returning) to a clean system". In
> our line of work which involves testing out various programs &
> configurations, hardly a day goes by where we're not using a disk-cloning
> program to do precisely that.

And you mean that having made the clone, one subsequentally copies the
backup clone BACK to the source drive, I presume here.

For some reason I tend to think that is a bit atypical for the normal use of
*cloning* software. I tend to think of *cloning* software being
(principally) used to make a backup disk clone, which will then be pulled
out and swapped with the (bad) source drive, (unlike if one were using
imaging). But maybe that's an incorrect assumption. More on that below.

> What would give you the idea that a
> disk-cloning program (as opposed to a disk-imaging program) would be
> incapable of doing so or be inadequate to that task? Or somehow inferior
> in
> time or effectiveness in doing so? That is simply not the case and I can't
> imagine how you concluded that.
>
> A clone is a clone is a clone. Using the Casper program as an example the
> user can clone the contents of one HDD to another HDD either on a
> partition-by-partition basis or the entire disk in one fell swoop.

OK - that was one point that I still wasn't sure about - sorry. More
below.

> Why do you conclude that "the normal method for this purpose (testing out
> programs and restoring a backup) would be imaging", inferring that somehow
> the disk-cloning "method" is "abnormal" for this purpose?
> Anna

I was just under the impression that a disk *cloning* program was intended
to make the destination *drive* identical to the source *drive* (and not
just a partition), so that you could pull the destination drive out, and
swap it with the (bad) source drive.

And in my case, I can't really do that at the drive level, since my 250 GB
source drive consists of several partitions, and I always ONLY backup the C:
40 GB partition to a much smaller destination drive (80 GB in total) in the
external USB enclosure. So I never can (nor do I want to, anyways) clone
the entire 250 GB source drive completely over to the destination drive in
the external USB enclosure. Nor do I want the other half of that 80 GB
destination drive touched during my backup operation (but I guess it won't
be, from what your saying, as long as I simply elect to do a partition to
partition cloning operation).

So as you said above, Casper can apparently also do JUST do a
partition-to-partition copy (like BootItNG, for example, running in
Maintenance Mode, for partition copying operations). OK then.

So in summary, I guess if we view *cloning* as a partition-to-partition copy
operation, and not necessarily a *drive-to-drive* copy operation, then I
guess there is no real practical difference here, EXCEPT that, of course, if
one uses *imaging*, one cannot ever bootup that backup drive, of course.

Anyway, maybe I've got it straight by now. (if not, pse let me know).

Thanks,
Bill

Anna

"Bill in Co." <> wrote in message
news:.gbl...
(SNIP)
> So in summary, I guess if we view *cloning* as a partition-to-partition
> copy operation, and not necessarily a *drive-to-drive* copy operation,
> then I guess there is no real practical difference here, EXCEPT that, of
> course, if one uses *imaging*, one cannot ever bootup that backup drive,
> of course.
>
> Anyway, maybe I've got it straight by now. (if not, pse let me know).
>
> Thanks,
> Bill


Bill:
Yes, you have it "straight" now. The Casper disk-cloning program can clone
the contents of one partition on a multi-partitioned "source" HDD to another
partition on a multi-partitioned "destination" drive. And when the need
arises, do the same in reverse.

Taking your specific example of your 250 GB HDD which contains a number of
partitions including a 40 GB partition that contains your operating system
and perhaps other data, i.e., your C: partition, and you want to clone
*only* the contents of that specific partition to your 80 GB USBEHD
"destination" drive, but you don't want to use the entire 80 GB of disk
space on that drive to contain that 40 GB of data, but just another 40 GB
partition on that destination drive...

No problem. Using the Casper disk-cloning program it would be a simple
matter to clone the contents of that 40 GB partition on the source HDD to a
similar-sized partition or whatever other partition size you may have
established on the destination drive.

And should you do this on a rather frequent basis - say every few days or
once a week or even more frequently - it would probably take you not much
more than two (2) or three (3) minutes to complete the entire cloning
operation because of Casper's "SmartClone" capability.
Anna

Bill in Co.

Anna wrote:
> "Bill in Co." <> wrote in message
> news:.gbl...
> (SNIP)
>> So in summary, I guess if we view *cloning* as a partition-to-partition
>> copy operation, and not necessarily a *drive-to-drive* copy operation,
>> then I guess there is no real practical difference here, EXCEPT that, of
>> course, if one uses *imaging*, one cannot ever bootup that backup drive,
>> of course.
>>
>> Anyway, maybe I've got it straight by now. (if not, pse let me know).
>>
>> Thanks,
>> Bill
>
>
> Bill:
> Yes, you have it "straight" now. The Casper disk-cloning program can clone
> the contents of one partition on a multi-partitioned "source" HDD to
> another
> partition on a multi-partitioned "destination" drive. And when the need
> arises, do the same in reverse.

And for me, that would always be the case. :-)

> Taking your specific example of your 250 GB HDD which contains a number of
> partitions including a 40 GB partition that contains your operating system
> and perhaps other data, i.e., your C: partition, and you want to clone
> *only* the contents of that specific partition to your 80 GB USBEHD
> "destination" drive, but you don't want to use the entire 80 GB of disk
> space on that drive to contain that 40 GB of data, but just another 40 GB
> partition on that destination drive...
>
> No problem. Using the Casper disk-cloning program it would be a simple
> matter to clone the contents of that 40 GB partition on the source HDD to
> a
> similar-sized partition or whatever other partition size you may have
> established on the destination drive.
>
> And should you do this on a rather frequent basis - say every few days or
> once a week or even more frequently - it would probably take you not much
> more than two (2) or three (3) minutes to complete the entire cloning
> operation because of Casper's "SmartClone" capability.
> Anna

But if I did that AND recloned it back (from the *external* USB backup drive
back to the *internal* source drive), it would surely take more than 3
minutes. Right? And that's the only way I would use the program.

Something else I'm not sure about is: just how reliable relying exclusively
on the Smart Cloning (or incremental in TI) feature is.

For some reason, it seems safer to me to (every time) do the FULL partition
backup cloning (or imaging), rather than RELY on any incremental technology
being able to keep proper track of ALL changes (with 100% certainity).

Of course, this method takes longer. Just to give you some idea, I have
about 20 GB of actual data (programs, data, windows, etc) on my 40 GB C:
partitition.

When I use True Image to make a backup image, it takes about 15 minutes (for
that 20 GB of actual data). (I am using a 1.6 GHz computer here, probably
considered a bit slow these days :-).

However, to restore it back to the source drive, takes almost an HOUR (but
that includes it first verifying the image, etc). And at the end, it
reboots, of course (since it's my Active partition. I presume it would
have to do the same using Casper).

I presume if I used Casper, it would take about the same time, UNLESS I used
the Smart Cloning bit, and *relied* on that. I'm curious about the total
time it would take however, if you have any rough ideas from your
experiences (either using or not using the Smart Cloning feature).

Thanks again,
Bill

Anna

>> "Bill in Co." <> wrote in message
>> news:.gbl...
>> (SNIP)
>>> So in summary, I guess if we view *cloning* as a partition-to-partition
>>> copy operation, and not necessarily a *drive-to-drive* copy operation,
>>> then I guess there is no real practical difference here, EXCEPT that, of
>>> course, if one uses *imaging*, one cannot ever bootup that backup drive,
>>> of course.
>>>
>>> Anyway, maybe I've got it straight by now. (if not, pse let me know).
>>>
>>> Thanks,
>>> Bill


> Anna wrote:
>> Bill:
>> Yes, you have it "straight" now. The Casper disk-cloning program can
>> clone
>> the contents of one partition on a multi-partitioned "source" HDD to
>> another partition on a multi-partitioned "destination" drive. And when
>> the >> need arises, do the same in reverse.
>>
>> Taking your specific example of your 250 GB HDD which contains a number
>> of partitions including a 40 GB partition that contains your operating
>> system and perhaps other data, i.e., your C: partition, and you want to
>> clone *only* the contents of that specific partition to your 80 GB >>
>> USBEHD "destination" drive, but you don't want to use the entire 80 GB of
>> >> disk space on that drive to contain that 40 GB of data, but just
>> another 40 >> GB partition on that destination drive...
>>
>> No problem. Using the Casper disk-cloning program it would be a simple
>> matter to clone the contents of that 40 GB partition on the source HDD to
>> a similar-sized partition or whatever other partition size you may have
>> established on the destination drive.
>>
>> And should you do this on a rather frequent basis - say every few days or
>> once a week or even more frequently - it would probably take you not much
>> more than two (2) or three (3) minutes to complete the entire cloning
>> operation because of Casper's "SmartClone" capability.
>> Anna


"Bill in Co." <> wrote in message
news:.gbl...
> But if I did that AND recloned it back (from the *external* USB backup
> drive > back to the *internal* source drive), it would surely take more
> than 3 minutes. Right? And that's the only way I would use the
> program.
>
> Something else I'm not sure about is: just how reliable relying
> exclusively on the Smart Cloning (or incremental in TI) feature is.
>
> For some reason, it seems safer to me to (every time) do the FULL
> partition backup cloning (or imaging), rather than RELY on any incremental
> technology being able to keep proper track of ALL changes (with 100%
> certainity).
>
> Of course, this method takes longer. Just to give you some idea, I have
> about 20 GB of actual data (programs, data, windows, etc) on my 40 GB C:
> partitition.
>
> When I use True Image to make a backup image, it takes about 15 minutes
> (for that 20 GB of actual data). (I am using a 1.6 GHz computer here,
> probably considered a bit slow these days :-).
>
> However, to restore it back to the source drive, takes almost an HOUR (but
> that includes it first verifying the image, etc). And at the end, it
> reboots, of course (since it's my Active partition. I presume it would
> have to do the same using Casper).
>
> I presume if I used Casper, it would take about the same time, UNLESS I
> used the Smart Cloning bit, and *relied* on that. I'm curious about the
> total time it would take however, if you have any rough ideas from your
> experiences (either using or not using the Smart Cloning feature).
>
> Thanks again,
> Bill


Bill:
With respect to your first question re the cloning (or what you might call
the "re:cloning") of the contents of the USBEHD back to the internal HDD to
restore a dysfunctional HDD or return the system to its state at the time
the contents of that internal HDD was previously cloned to the USBEHD as a
backup of the system...

No, the amount of time that would be expended re that "re:cloning" process
would be similarly relatively slight in most cases. Naturally it would
depend upon when the USBEHD was the recipient of the cloned contents of the
internal HDD, i.e., how close to the time when the clone was created, and of
course the amount of data to be cloned.

Again, taking the kind of situation that you've indicated you frequently
engage in...

Let's say, for example, that you want to experiment with a program with
which you've had no experience to determine whether that program meets a
particular need. But because you're wisely cautious about installing and
working with that new untested program on your day-to-day working HDD you
want to back up your present system in the event things go awry after you've
installed that new program, or you find the program is unsuitable for your
needs and you don't want to leave the usual garbage/debris in your registry
or other parts of your system even after you've uninstalled the program. And
you & I know that frequently happens.

So you do the wise thing and, using Casper in this example, you back up your
system through the disk-cloning process to your USBEHD before installing
that new program. After working with that new program for a couple of days
or so you find yourself dissatisfied with it and want to return to the
previous state of your system before you installed the program. So you clone
the contents of the USBEHD back to the internal HDD. By & large, in the
example you've cited, it would probably take you a couple of minutes to do
so, most likely not much more than four minutes. In effect, the SmartClone
process will kick in.

Now as to the reliability of the SmartClone feature (in effect, an
"incremental" disk-cloning process that Casper incorporates in its
program)...

All I can tell you is that over the two years or so that we've been working
with Casper, and have personally used the program or participated with
others in using or observing the program -- involving hundreds of
disk-cloning operations, we've found it extraordinarily reliable. And that,
of course, includes its SmartClone feature. I won't say the program is
flawless, no program is or ever has been in my experience, but I can't
recall a single instance where use of the program resulted in a corruption
or loss of data. Simply stated, the program *always* seems to "work" without
problems. Of course I'm relating all this to an XP environment since my
experience with Vista is minimal. But I'm also aware of many Casper users
who work primarily or exclusively with Vista and they have reported the
program works just fine in that operating system.

Please bear in mind as I have tried to continually emphasize that this
"incremental" cloning feature results in a *complete* clone of the source
HDD. It's an integral part of the program and, as a practical matter, cannot
be separated from the program by the user. Understand that there is no user
option to select a "full clone" or an "incremental clone". A clone is a
clone is a clone. The SmartClone feature is completely integrated in the
program and thus always present when using the program. I trust I've made
that clear.
Anna

Bill in Co.

Anna wrote:
>>> "Bill in Co." <> wrote in message
>>> news:.gbl...
>>> (SNIP)
>>>> So in summary, I guess if we view *cloning* as a partition-to-partition
>>>> copy operation, and not necessarily a *drive-to-drive* copy operation,
>>>> then I guess there is no real practical difference here, EXCEPT that,
>>>> of
>>>> course, if one uses *imaging*, one cannot ever bootup that backup
>>>> drive,
>>>> of course.
>>>>
>>>> Anyway, maybe I've got it straight by now. (if not, pse let me know).
>>>>
>>>> Thanks,
>>>> Bill
>
>
>> Anna wrote:
>>> Bill:
>>> Yes, you have it "straight" now. The Casper disk-cloning program can
>>> clone the contents of one partition on a multi-partitioned "source" HDD
>>> to
>>> another partition on a multi-partitioned "destination" drive. And when
>>> the need arises, do the same in reverse.
>>>
>>> Taking your specific example of your 250 GB HDD which contains a number
>>> of partitions including a 40 GB partition that contains your operating
>>> system and perhaps other data, i.e., your C: partition, and you want to
>>> clone *only* the contents of that specific partition to your 80 GB
>>> USBEHD "destination" drive, but you don't want to use the entire 80 GB
>>> of disk space on that drive to contain that 40 GB of data, but just
>>> another 40 GB partition on that destination drive...
>>>
>>> No problem. Using the Casper disk-cloning program it would be a simple
>>> matter to clone the contents of that 40 GB partition on the source HDD
>>> to
>>> a similar-sized partition or whatever other partition size you may have
>>> established on the destination drive.
>>>
>>> And should you do this on a rather frequent basis - say every few days
>>> or
>>> once a week or even more frequently - it would probably take you not
>>> much
>>> more than two (2) or three (3) minutes to complete the entire cloning
>>> operation because of Casper's "SmartClone" capability.
>>> Anna
>
>
> "Bill in Co." <> wrote in message
> news:.gbl...
>> But if I did that AND recloned it back (from the *external* USB backup
>> drive > back to the *internal* source drive), it would surely take more
>> than 3 minutes. Right? And that's the only way I would use the
>> program.
>>
>> Something else I'm not sure about is: just how reliable relying
>> exclusively on the Smart Cloning (or incremental in TI) feature is.
>>
>> For some reason, it seems safer to me to (every time) do the FULL
>> partition backup cloning (or imaging), rather than RELY on any
>> incremental
>> technology being able to keep proper track of ALL changes (with 100%
>> certainity).
>>
>> Of course, this method takes longer. Just to give you some idea, I
>> have
>> about 20 GB of actual data (programs, data, windows, etc) on my 40 GB C:
>> partitition.
>>
>> When I use True Image to make a backup image, it takes about 15 minutes
>> (for that 20 GB of actual data). (I am using a 1.6 GHz computer here,
>> probably considered a bit slow these days :-).
>>
>> However, to restore it back to the source drive, takes almost an HOUR
>> (but
>> that includes it first verifying the image, etc). And at the end, it
>> reboots, of course (since it's my Active partition. I presume it would
>> have to do the same using Casper).
>>
>> I presume if I used Casper, it would take about the same time, UNLESS I
>> used the Smart Cloning bit, and *relied* on that. I'm curious about the
>> total time it would take however, if you have any rough ideas from your
>> experiences (either using or not using the Smart Cloning feature).
>>
>> Thanks again,
>> Bill
>
>
> Bill:
> With respect to your first question re the cloning (or what you might call
> the "re:cloning") of the contents of the USBEHD back to the internal HDD
> to
> restore a dysfunctional HDD or return the system to its state at the time
> the contents of that internal HDD was previously cloned to the USBEHD as a
> backup of the system...
>
> No, the amount of time that would be expended re that "re:cloning" process
> would be similarly relatively slight in most cases. Naturally it would
> depend upon when the USBEHD was the recipient of the cloned contents of
> the
> internal HDD, i.e., how close to the time when the clone was created, and
> of
> course the amount of data to be cloned.

OK.

> Again, taking the kind of situation that you've indicated you frequently
> engage in...
>
> Let's say, for example, that you want to experiment with a program with
> which you've had no experience to determine whether that program meets a
> particular need. But because you're wisely cautious about installing and
> working with that new untested program on your day-to-day working HDD you
> want to back up your present system in the event things go awry after
> you've
> installed that new program, or you find the program is unsuitable for your
> needs and you don't want to leave the usual garbage/debris in your
> registry
> or other parts of your system even after you've uninstalled the program.
> And
> you & I know that frequently happens.

Yup. But I probably don't test as many as you have (or have seen),
however.

But some of the larger programs I do try out are in the 30+ MB (exe)
installer sizes, which are often somewhat invasive (and generally the much
smaller ones, aren't).
For anything like this, if after I run try it out using a trial version, and
I don't want to keep it, I'll roll back using my backup, as I have learned
not to simply trust the uninstaller on all occasions (particularly these
larger software packages). :-)

> So you do the wise thing and, using Casper in this example, you back up
> your
> system through the disk-cloning process to your USBEHD before installing
> that new program. After working with that new program for a couple of days
> or so you find yourself dissatisfied with it and want to return to the
> previous state of your system before you installed the program. So you
> clone
> the contents of the USBEHD back to the internal HDD. By & large, in the
> example you've cited, it would probably take you a couple of minutes to do
> so, most likely not much more than four minutes. In effect, the SmartClone
> process will kick in.

Well, that IS quick. Sounds like a LOT quicker than one hour overall, too.
:-)

> Now as to the reliability of the SmartClone feature (in effect, an
> "incremental" disk-cloning process that Casper incorporates in its
> program)...
>
> All I can tell you is that over the two years or so that we've been
> working
> with Casper, and have personally used the program or participated with
> others in using or observing the program -- involving hundreds of
> disk-cloning operations, we've found it extraordinarily reliable. And
> that,
> of course, includes its SmartClone feature. I won't say the program is
> flawless, no program is or ever has been in my experience, but I can't
> recall a single instance where use of the program resulted in a corruption
> or loss of data. Simply stated, the program *always* seems to "work"
> without
> problems. Of course I'm relating all this to an XP environment since my
> experience with Vista is minimal. But I'm also aware of many Casper users
> who work primarily or exclusively with Vista and they have reported the
> program works just fine in that operating system.

I also take it that at least some of these users are also familiar with True
Image, and still prefer it (even if they were using it like I would - to
clone and then reclone back to the source drive after trying something out).

We may have already covered this, but, all this being said, when would YOU
prefer to use *imaging* instead of cloning (in this case, use TI instead of
Casper)? Can you think of any possible case or reason?

> Please bear in mind as I have tried to continually emphasize that this
> "incremental" cloning feature results in a *complete* clone of the source
> HDD. It's an integral part of the program and, as a practical matter,
> cannot
> be separated from the program by the user. Understand that there is no
> user
> option to select a "full clone" or an "incremental clone". A clone is a
> clone is a clone. The SmartClone feature is completely integrated in the
> program and thus always present when using the program. I trust I've made
> that clear.
> Anna

I see. I didn't know the Smart Cloning was completely integrated.

So, that being said, then evidently the option of backing up the whole thing
afresh (as if it were brand new (i.e., without using Smart Cloning) is not
available, nor even needed, (from what you are saying). And we have to
trust that the program is smart enough to keep FULL track of ALL successive
incremental changes over time, with no lapses, whatsover. (Which seems a
bit amazing to me still (that it can be that foolproof, vs doing the whole
thing afresh, each time).

Well, as I said, I'm just accustomed to using Acronis True Image to always
write the complete backup images as completely new files (i.e., no
incrementals, etc, and often overwriting the previous ones to save disk
space).

But it sounds like Casper has a much quicker approach, as you've been
saying.

I still may try it! :-) (I downloaded it before, version 4.0). Maybe
if I can take a break from trying out other things here.

I think they should sell Casper boxed WITH the program on a bootup restore
CD, like Acronis True Image, however. Of course, it's not too much work
to make one, I guess. :-)

Bill

Anna

"Bill in Co." <> wrote in message
news:%.gbl...
> We may have already covered this, but, all this being said, when would YOU
> prefer to use *imaging* instead of cloning (in this case, use TI instead
> of Casper)? Can you think of any possible case or reason?
(SNIP)
> I think they should sell Casper boxed WITH the program on a bootup restore
> CD, like Acronis True Image, however. Of course, it's not too much work
> to make one, I guess. :-)
>
> Bill


Bill:
We rarely use the disk-imaging approach in our day-to-day backups. In
general, when we do use the disk-imaging approach (using Acronis True Image)
it's because of a rather unusual reason that most users would have no need
for.

We frequently have occasion to fresh install the XP OS for a variety of
users with different PCs. And in many instances also install various
programs on these machines. So we like to have copies of those particular
installations in case the user later has problems with the system. Also for
our own reference reasons. To that end the disk-imaging approach better
meets our needs rather than going the disk-cloning route, primarily because
the compression feature of disk-imaging allows us to "store" more different
systems on a multi-partitioned HDD. (We generally work with removable HDDs
so that we store the disk-images on an internal HDD).

Also, when a user is concerned with creating "generational" backups of his
or her system, i.e., individual comprehensive backups of their system at
various points in time, a disk-imaging program is generally considered to be
the program of choice, although depending upon the number of "generations"
desired by the user, the amount of data involved, and the size of the
"destination" HDD, that capability can also be accommodated by a
disk-cloning program such as Casper.

But when all is said & done, we recognize that many users are quite
comfortable with the disk-imaging approach rather than the disk-cloning
approach and simply do not wish to change.

I agree with your comment that the developer should offer a retail, boxed
version of the Casper program - one which, in effect, would include the
"Startup Disk" in the form of the bootable CD that contains the installation
program. Failing that, the "Startup Disk" CD should not be considered an
extra-cost option as it currently is. As I've previously indicated we have
complained to the developer about this since the Startup Disk is obviously
an essential piece of the program.
Anna

Bill in Co.

Anna wrote:
> "Bill in Co." <> wrote in message
> news:%.gbl...
>> We may have already covered this, but, all this being said, when would
>> YOU
>> prefer to use *imaging* instead of cloning (in this case, use TI instead
>> of Casper)? Can you think of any possible case or reason?
> (SNIP)
>> I think they should sell Casper boxed WITH the program on a bootup
>> restore
>> CD, like Acronis True Image, however. Of course, it's not too much
>> work
>> to make one, I guess. :-)
>>
>> Bill
>
>
> Bill:
> We rarely use the disk-imaging approach in our day-to-day backups. In
> general, when we do use the disk-imaging approach (using Acronis True
> Image)
> it's because of a rather unusual reason that most users would have no need
> for.
>
> We frequently have occasion to fresh install the XP OS for a variety of
> users with different PCs. And in many instances also install various
> programs on these machines. So we like to have copies of those particular
> installations in case the user later has problems with the system. Also
> for
> our own reference reasons. To that end the disk-imaging approach better
> meets our needs rather than going the disk-cloning route, primarily
> because
> the compression feature of disk-imaging allows us to "store" more
> different
> systems on a multi-partitioned HDD. (We generally work with removable HDDs
> so that we store the disk-images on an internal HDD).

OK. And the assumption here is that the compressed image is significantly
smaller than the actual data, and that is the main reason in this case.
Although there may be another one come to think of it, mentioned below:

> Also, when a user is concerned with creating "generational" backups of his
> or her system, i.e., individual comprehensive backups of their system at
> various points in time, a disk-imaging program is generally considered to
> be
> the program of choice, although depending upon the number of "generations"
> desired by the user, the amount of data involved, and the size of the
> "destination" HDD, that capability can also be accommodated by a
> disk-cloning program such as Casper.

Right, so what's the big difference here, except that 1) the image is
somewhat smaller than a clone would be, and 2) perhaps it is easier to keep
track of several image files rather than keeping track of several different
clones - because each image just presents itself as a single file to manage,
and NOT the multitude of thousands of directories and files, as it really
is, via the cloning approach.

> But when all is said & done, we recognize that many users are quite
> comfortable with the disk-imaging approach rather than the disk-cloning
> approach and simply do not wish to change.

Well, I'm still thinking about it, if I can get done with some other stuff
I'm messing with here first. :-)

> I agree with your comment that the developer should offer a retail, boxed
> version of the Casper program - one which, in effect, would include the
> "Startup Disk" in the form of the bootable CD that contains the
> installation
> program. Failing that, the "Startup Disk" CD should not be considered an
> extra-cost option as it currently is.

Ooops, I forgot that. I thought you could roll your own CD. My mistake,
there.

> As I've previously indicated we have
> complained to the developer about this since the Startup Disk is obviously
> an essential piece of the program.
> Anna