View Single Post
  #14  
Old January 17th 09, 08:22 PM posted to microsoft.public.windowsxp.basics,microsoft.public.windowsxp.help_and_support
Anna
external usenet poster
 
Posts: 2,039
Default How to use Acronis to backup o/s ?


"Anna" wrote in message
...
John99...
I've not included the instructions for the Acronis disk-imaging process
since I assume from your query that you would be interested only in the
disk-cloning process. But if you want step-by-step instructions for the
disk-imaging (and restoration) process, I'll post them.
Anna



"John D99" wrote in message
m...
Please post your Acronis 9 disk-imaging process notes also, and everything
for recovery for both approaches.

Your note about cloning on an internal hard drive, possibly creating a
problem on bootup was excellent.

I guess that's becasue a "clone" is an operable copy of the o/s, and on
bootup, the system won't know which "o/s" it's supposed to bootup from?



John99:
I did post step-by-step instructions re the Acronis disk-imaging process -
at least as it applies to the ATI versions 9, 10, and probably 11. You've
probably seen my post by now. Hope it will help.

One thing I didn't cover in those instructions was the distinction of
creating "incremental" vs. "differential" archives (as Acronis calls them).
I purposely left out of those basic disk-imaging instructions an explanation
of those processes. I did so because the differences between the two seemed
to confuse users and it appeared to me that there was near-universal
acceptance of the incremental-archive approach, at least among the users I
talked to or who read the instructions. So I focused only on creating
incremental files (archives).

But there are pros & cons between the two processes and a user such as
yourself, as well as others who use the ATI program, might want to
investigate the differences since both capabilities are present in the
program and the user has the option of using one or the other. The ATI
program's Help files contain info on this and as I recall there was also
info on the Acronis site as well.

As to your question...

It's really just a (potential) glitch in virtually every disk-cloning
program that I've worked with except for one exception (which I'll get to).

Again, this is a *potential* problem that *may* occur when using an
*internally-connected* HDD as the recipient of the clone, i.e., the
"destination" drive. Keep in mind that if the destination HDD is an
*external* HDD, e.g., a USB external HDD, there's ordinarily no problem
along the lines that will be described.

Following the successful disk-cloning operation should the user boot with
*both* of his/her hard drives connected (the so-called "source" &
"destination" drives), the system, of course, will ordinarily boot to the
source HDD (presumably the C: drive) as would be expected.

However, at some later date when the user attempts to subsequently boot with
*only* the previously-cloned (destination) HDD connected - let's say for
restoration purposes - there's a strong possibility the system will not boot
should *only* that HDD be connected. And this, even though the disk-cloning
operation had been successful, i.e., the cloned HDD is a precise copy of the
source HDD.

What has happened (and again, keep in mind this is a *potential* problem in
that it
does not *always* occur) 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 (newly-cloned) HDD. This
other-than-C: drive letter assignment 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 to be a reliable,
workable solution).

So the point here is that it's desirable for the user that *immediately*
following the disk-cloning process he or she disconnect the destination HDD
from the system and boot only to the source HDD.

Alternatively, the user can disconnect the source HDD and boot only to the
newly-cloned HDD and then shut down the machine and disconnect that drive
and connect the source HDD. The advantage here is that the user checks
that the disk-cloning process was successful.

Again, I have to emphasize that this problem doesn't always occur and it
only affects a situation where the destination HDD is an
*internally-connected* HDD. There's no problem affecting a USB external HDD
if that device is the recipient of the clone. But the problem has arisen
with sufficient frequency that we refer to this cautionary note.

Our disk-cloning program of choice is the Casper 5 program - one of the
reasons being that we've never encountered the above problem with this
program regardless that both the source & destination drives were connected
immediately following the disk-cloning operation. And we've been involved in
hundreds of disk-cloning operations with this program. It is simply
unnecessary that following the successful
disk-cloning operation (again, involving internal hard drives), the cloned
HDD be disconnected from the system (or, conversely, the source HDD be
disconnected from the system and an initial boot be made only to the
newly-cloned HDD.)

As far as we're concerned the disk-cloning approach (especially using the
Casper 5 program) is ideally suited for the vast majority of PC users in
terms of creating & maintaining a comprehensive backup program. We greatly
prefer it over the Acronis program (for a variety of reasons) and believe
that the disk-to-disk (or partition-to-partition) disk-cloning process
better meets the needs of average PC users. What better backup system can
one have than having at hand a precise copy of his or her day-to-day working
HDD? Where all the data on the cloned disk is immediately accessible and
should that disk be an internal HDD it's immediately bootable & completely
functional without the need for any restoration process.

Now I do realize that many users - particularly the more advanced users -
for various reasons prefer the disk-imaging process for backup purposes. I
always encourage users to experiment with both approaches and decide for
themselves what best meets their needs.
Anna


Ads