Backing up the system

G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.general (More info?)

What is the recommend approach to system backup for XP to include system
setup, program files and data? Or is it more or less backup the data and
format, reload the programs?
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.general (More info?)

Each person has their favorite way/program to backup
I use Acronis True Image.....it images your while HD onto another HD or
CD/DVD(more than one).
It lets you perform incremental backup.It creates a TrueImage Boot disk that
lets you access that image and restore it.
A one shot back...no piece by piece.........and it works.I just restored an
image Last Saturday when I was not watching too carefully and deleted a file
XP needed to boot...........40min later I was back up and running.
peterk

--
It's so much easier to suggest solutions when you don't know too much about
the problem
"Ron Z" <RonZ@discussions.microsoft.com> wrote in message
news:41B64249-2B9A-4295-9674-9ED00F765222@microsoft.com...
> What is the recommend approach to system backup for XP to include system
> setup, program files and data? Or is it more or less backup the data and
> format, reload the programs?
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.general (More info?)

"peterk" wrote:
> Each person has their favorite way/program to backup
> I use Acronis True Image.....it images your while HD onto another HD or
> CD/DVD(more than one).
> It lets you perform incremental backup.It creates a TrueImage Boot disk that
> lets you access that image and restore it.
> A one shot back...no piece by piece.........and it works.I just restored an
> image Last Saturday when I was not watching too carefully and deleted a file
> XP needed to boot...........40min later I was back up and running.


Why did you even have to take 40 minutes - for doing what?
If you had a clone of the system on another HD, just connect
up that HD as a 2nd (or 3rd or 4th) HD and boot it up. (You
will have to put it 1st in the boot order in the BIOS, though.)
Then drag 'n drop the needed file back to the system partition
(which will be seen as just another Local Disk in the system)
on the primary HD. That's the beauty of a bootable clone -
you don't have to copy it back or "restore an image" - you just
boot it up to have a working system again in a couple minutes.

I keep several clones of my system partitions on large capacity
IDE disks mounted in a removable trays, and each clone is bootable.
It really makes for quick recoveries. You do need to know the syntax
of a boot.ini file, though.

*TimDaniels*
..
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.general (More info?)

"Ron Z" <RonZ@discussions.microsoft.com> wrote in message
news:41B64249-2B9A-4295-9674-9ED00F765222@microsoft.com...
> What is the recommend approach to system backup for XP to include system
> setup, program files and data? Or is it more or less backup the data and
> format, reload the programs?
>
While personal preference plays a large part in how you choose to backup
your system the principle that the data you create is unique and needs to be
protected at all cost whereas programs and the like can be reloaded from
their original sources applies.

Having said that my preference is a three shot approach
1. an imaging program (True Image, Ghost at al) to image program and OS
to an external HDD, a backup program, in my case
2. WinBackup, to backup data files and other files that change regularly
(Favorites, OE address book, email, Office Files etc) and
3. ERUNT to backup Registry Files.

The reason for the three shot approach is your System (Program Files)
change relatively infrequently and it is far quicker to recover the system
from an 'image' than by installing from original discs. Data files are
unique and will change daily, hence a dedicated program to backup those
files (daily incremental backup, weekly full backup of all data files) is
more eficient than imaghing the complete system (programs plus data). ERUNT
is set to automatically backup Registry files daily at start up. I do not
use System Restore to backup the Registry as in my experience SR is totally
unreliable.

I have heard good reports of GoBack and that maybe worth considering.
 

anna

Distinguished
Apr 17, 2004
339
0
18,780
Archived from groups: microsoft.public.windowsxp.general (More info?)

"Timothy Daniels" <TDaniels@NoSpamDot.com> wrote in message
news:HJOdnZrg2s09_07fRVn-rQ@comcast.com...
> "peterk" wrote:
>> Each person has their favorite way/program to backup
>> I use Acronis True Image.....it images your while HD onto another HD or
>> CD/DVD(more than one).
>> It lets you perform incremental backup.It creates a TrueImage Boot disk
>> that lets you access that image and restore it.
>> A one shot back...no piece by piece.........and it works.I just restored
>> an image Last Saturday when I was not watching too carefully and deleted
>> a file XP needed to boot...........40min later I was back up and running.


"Timothy Daniels" <TDaniels@NoSpamDot.com> wrote in message
news:HJOdnZrg2s09_07fRVn-rQ@comcast.com...
> Why did you even have to take 40 minutes - for doing what?
> If you had a clone of the system on another HD, just connect
> up that HD as a 2nd (or 3rd or 4th) HD and boot it up. (You
> will have to put it 1st in the boot order in the BIOS, though.)
> Then drag 'n drop the needed file back to the system partition
> (which will be seen as just another Local Disk in the system)
> on the primary HD. That's the beauty of a bootable clone -
> you don't have to copy it back or "restore an image" - you just
> boot it up to have a working system again in a couple minutes.
>
> I keep several clones of my system partitions on large capacity
> IDE disks mounted in a removable trays, and each clone is bootable.
> It really makes for quick recoveries. You do need to know the syntax
> of a boot.ini file, though.
>
> *TimDaniels*


I would hope that the OP and those reading this thread who are interested in
creating & maintaining a relatively simple & effective means for backing up
their systems will pay special heed to Timothy's recommendation as it
applies to equipping one's desktop computer with removable hard drives and
using that hardware configuration in a disk-to-disk "cloning" environment.
Let me add my thoughts on the subject...

One of the most frequent topics on any newsgroup dealing with operating
systems like this one is what's the best strategy for backing up one's hard
drive. There's not a day that goes by where you don't come across literally
dozens, if not scores, of postings on this and similar newsgroups relating
to this subject. The queries (and responses) frequently focus on the
problems the user has encountered in using this or that software backup
program - either some third-party program or whatever built-in backup
program is included with the user's operating system.

In my opinion, the best backup system for the average home user and even
small business owner in most cases is having his or her desktop computer
equipped with two removable hard drives and using a disk imaging program
such as Symantec's Norton Ghost or Acronis True Image to "clone" the
contents of their working hard drive to another removable hard drive. There
are other advantages in having two removable hard drives on one's desktop
computer but the most significant one is providing a near fail-safe backup
system. The speed, flexibility and peace of mind you get with this
arrangement far outweighs (for most users) the relatively small additional
cost of equipping one's desktop computer with this hardware configuration.
Note that the removable hard drive mobile racks we are discussing are
designed to be installed in desktop computers and not laptop or notebook
computers. The size, weight, and design considerations of laptops/notebooks
do not allow for this hardware configuration.

Using this setup, backing up your hard drive is simple, straightforward,
fast, and most important of all -- effective. By easily and relatively
quickly making a clone of your hard drive, using a software program like
Symantec's Norton Ghost or Acronis True Image, programs which are
specifically designed for this purpose, you get, what seems to me, the
ultimate backup solution given the present state of personal desktop
computer technology. Unlike backup programs that merely back up your data
files - that is, the files you've created in the various programs and
applications you use - by cloning your hard drive, you're backing up your
operating system, your registry, all your programs and applications, your
configuration settings, your data files - in short, everything on the hard
drive from which you're making (for all practical purposes) a bit for bit
copy.


And you're doing all this in one fell swoop, the result of which is the
creation of an exact duplicate of your working hard drive. And for *added*
safety you can remove this newly-cloned hard drive from the premises, not to
mention making *another* clone, if desired, for near-absolute security.

While it is true that backup software programs can backup the files you have
created in your various programs, they are unable to backup your operating
system and (for the most part) the programs installed on your computer. As
Bruce Chambers has pointed out a number of times, many, if not most,
computer users have invested substantial time and effort in customizing
Windows and configuring their applications to work the way they want to and
putting all of that back the way it was can be a difficult, frustrating, and
time-consuming effort.

So when the day comes - as it *surely* will - that your hard drive fails
because of some mechanical or electrical defect, it's a wonderful feeling to
know that you have a perfectly good copy of that failed hard drive that you
simply shove in the computer, boot up, and you're off and running. Or if you
ever get some miserable computer virus that plays havoc with your system, or
for some unknown reason this or that system file is missing or becomes
corrupt resulting in an inoperable computer, isn't it nice to know that you
have at hand a perfectly good virus-free clone of your hard drive? And then
simply clone that "good" previously cloned hard drive to the virus-infected
one so that once again you now have two perfectly good hard drives. And in
the case where the hard drive is kaput because of some mechanical/electronic
failure, you purchase a new hard drive, simply remove the defective drive
from the removable tray, plop in the new one, make two simple connections,
shove it in the computer and then clone your good hard drive to the new one.
And the added beauty of this arrangement is that you do all this from the
comfort of your computer chair. There's no need to open your computer case
and get into the "guts" of your computer to make complicated cable
disconnects/connects. Everything is done outside of your computer because
each hard drive resides in a tray (caddy) that you simply slide into the
computer's mobile rack.

There's *no* need to partition and format the new drive; *no* need to
reinstall your operating system on the new drive; *no* need to reinstall
your programs and data files. None of this is necessary. By simply cloning
the
previously-cloned hard drive to the new drive you once again have two
functioning hard drives at your disposal.


As previously indicated, these mobile rack devices are two-part affairs -
the rack itself and the inner tray (caddy) in which the hard drive resides
that slides into the rack. They come in all-aluminum models or a combination
of aluminum-plastic ranging in price from about $15 to $50. Naturally, your
desktop computer case will need two 5¼" bays that are available to house the
mobile racks. Mobile racks come in various versions, depending upon whether
the hard drive to be housed is an IDE/ATA, SATA, or SCSI device. A Google
search for “removable hard drive mobile racks” will result in a wealth of
information on these products and their vendors. I'm aware of many users who
have been using inexpensive plastic mobile racks without any problems
whatsoever. Unfortunately, there is no industry standard involving the
design and construction of the racks nor the inner trays that contain the
hard drive.Consequently, there is (usually) no interchangeability of these
trays among the various manufacturers of mobile racks. Indeed, there is
frequently no interchangeability of the inner trays among different models
from the same manufacturer. This lack of interchangeability may not be an
issue if the user will be purchasing a particular model of mobile rack for a
single computer, however, if the user will have access to other computers,
he or she may want to settle on a specific brand and model of mobile rack
that will provide for tray interchangeability amongst different computers.

As I've previously indicated, the cloning process itself is easy and
relatively fast. Using Symantec's Norton Ghost 2003 cloning program as an
example, with the two removable hard drives connected to the computer, you
simply boot up your desktop computer with the bootable floppy disk that
contains the Ghost program and after a few key clicks the cloning process
begins. The cloning process is practically automatic and you need not be in
attendance during the actual cloning operation. The size (disk capacity) or
make/model of your hard drives need not be identical; all that matters is
that your destination drive contains sufficient capacity to receive the
contents of your source drive. Incidentally, I’ve recently been
experimenting with the Acronis True Image program because of the many
favorable reports I’ve come across about this program. Using a bootable ATI
CD, I find the cloning speed of this program is considerably faster than
that of Ghost. And so far I’ve run into no problems with the cloning process
itself. Depending upon the speed of your processor and hard drives you
should get cloning speeds of somewhere between 700 MB to 1.5+ GB per minute
(less if cloning to a USB/Firewire external hard drive).


I can virtually guarantee that once you begin working with two removable
hard drives, you'll have but one regret and only one regret. And that is you
didn't have this arrangement on your previous computer or computers. While
the additional cost involved in configuring your desktop computer with two
mobile racks together with the additional hard drive and disk imaging
software is not negligible, I can assure you it's money well spent. Frankly,
when you consider the enormous advantages of having two removable hard
drives on your desktop computer, the additional cost of so equipping your
computer in this fashion practically pales into insignificance.



Timothy mentions that in using the disk-to-disk cloning process, "You do
need to know the syntax of a boot.ini file, though". Insofar as the cloning
process that I've described above is concerned, there is *no* need that I'm
aware of to manipulate boot.ini syntax. A clone is a clone is a clone. When
you clone the contents of your working drive to the destination drive
(bearing in mind we're talking about removable internal drives in their
mobile racks), the destination drive, being for all practical purposes an
exact duplicate of the source drive, is bootable and there's no need to edit
its boot.ini file. If, however, I've misunderstood the thrust of Timothy's
statement, I trust he will amplify his comment.

Anna
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.general (More info?)

Very nice description of cloning and a very very good argument for removable
hard drives.
Until I can afford your solution I will continue to "image" my hard drives.
Using a dual boot system with ME on an IDE as C and XP on a SATA drive as D
I find imaging works very well for me.I use another SATA HD with Acronis
Secure Zone and the time I just spend restoring the D drive is really
nothing compared to the time I would have spend restoring without the image.
But I will be looking at purchasing a removable hard drive tray and another
HD in the very near future.
thank you
peterk


--
It's so much easier to suggest solutions when you don't know too much about
the problem
"Anna" <myname@myisp.net> wrote in message
news:%23jVH6rwhFHA.3012@TK2MSFTNGP12.phx.gbl...
>
> "Timothy Daniels" <TDaniels@NoSpamDot.com> wrote in message
> news:HJOdnZrg2s09_07fRVn-rQ@comcast.com...
>> "peterk" wrote:
>>> Each person has their favorite way/program to backup
>>> I use Acronis True Image.....it images your while HD onto another HD or
>>> CD/DVD(more than one).
>>> It lets you perform incremental backup.It creates a TrueImage Boot disk
>>> that lets you access that image and restore it.
>>> A one shot back...no piece by piece.........and it works.I just restored
>>> an image Last Saturday when I was not watching too carefully and deleted
>>> a file XP needed to boot...........40min later I was back up and
>>> running.
>
>
> "Timothy Daniels" <TDaniels@NoSpamDot.com> wrote in message
> news:HJOdnZrg2s09_07fRVn-rQ@comcast.com...
>> Why did you even have to take 40 minutes - for doing what?
>> If you had a clone of the system on another HD, just connect
>> up that HD as a 2nd (or 3rd or 4th) HD and boot it up. (You
>> will have to put it 1st in the boot order in the BIOS, though.)
>> Then drag 'n drop the needed file back to the system partition
>> (which will be seen as just another Local Disk in the system)
>> on the primary HD. That's the beauty of a bootable clone -
>> you don't have to copy it back or "restore an image" - you just
>> boot it up to have a working system again in a couple minutes.
>>
>> I keep several clones of my system partitions on large capacity
>> IDE disks mounted in a removable trays, and each clone is bootable.
>> It really makes for quick recoveries. You do need to know the syntax
>> of a boot.ini file, though.
>>
>> *TimDaniels*
>
>
> I would hope that the OP and those reading this thread who are interested
> in creating & maintaining a relatively simple & effective means for
> backing up their systems will pay special heed to Timothy's recommendation
> as it applies to equipping one's desktop computer with removable hard
> drives and using that hardware configuration in a disk-to-disk "cloning"
> environment. Let me add my thoughts on the subject...
>
> One of the most frequent topics on any newsgroup dealing with operating
> systems like this one is what's the best strategy for backing up one's
> hard drive. There's not a day that goes by where you don't come across
> literally dozens, if not scores, of postings on this and similar
> newsgroups relating to this subject. The queries (and responses)
> frequently focus on the problems the user has encountered in using this or
> that software backup program - either some third-party program or whatever
> built-in backup program is included with the user's operating system.
>
> In my opinion, the best backup system for the average home user and even
> small business owner in most cases is having his or her desktop computer
> equipped with two removable hard drives and using a disk imaging program
> such as Symantec's Norton Ghost or Acronis True Image to "clone" the
> contents of their working hard drive to another removable hard drive.
> There are other advantages in having two removable hard drives on one's
> desktop computer but the most significant one is providing a near
> fail-safe backup system. The speed, flexibility and peace of mind you get
> with this arrangement far outweighs (for most users) the relatively small
> additional cost of equipping one's desktop computer with this hardware
> configuration. Note that the removable hard drive mobile racks we are
> discussing are designed to be installed in desktop computers and not
> laptop or notebook computers. The size, weight, and design considerations
> of laptops/notebooks do not allow for this hardware configuration.
>
> Using this setup, backing up your hard drive is simple, straightforward,
> fast, and most important of all -- effective. By easily and relatively
> quickly making a clone of your hard drive, using a software program like
> Symantec's Norton Ghost or Acronis True Image, programs which are
> specifically designed for this purpose, you get, what seems to me, the
> ultimate backup solution given the present state of personal desktop
> computer technology. Unlike backup programs that merely back up your data
> files - that is, the files you've created in the various programs and
> applications you use - by cloning your hard drive, you're backing up your
> operating system, your registry, all your programs and applications, your
> configuration settings, your data files - in short, everything on the hard
> drive from which you're making (for all practical purposes) a bit for bit
> copy.
>
>
> And you're doing all this in one fell swoop, the result of which is the
> creation of an exact duplicate of your working hard drive. And for *added*
> safety you can remove this newly-cloned hard drive from the premises, not
> to mention making *another* clone, if desired, for near-absolute security.
>
> While it is true that backup software programs can backup the files you
> have created in your various programs, they are unable to backup your
> operating system and (for the most part) the programs installed on your
> computer. As Bruce Chambers has pointed out a number of times, many, if
> not most, computer users have invested substantial time and effort in
> customizing Windows and configuring their applications to work the way
> they want to and putting all of that back the way it was can be a
> difficult, frustrating, and time-consuming effort.
>
> So when the day comes - as it *surely* will - that your hard drive fails
> because of some mechanical or electrical defect, it's a wonderful feeling
> to know that you have a perfectly good copy of that failed hard drive that
> you
> simply shove in the computer, boot up, and you're off and running. Or if
> you ever get some miserable computer virus that plays havoc with your
> system, or for some unknown reason this or that system file is missing or
> becomes
> corrupt resulting in an inoperable computer, isn't it nice to know that
> you have at hand a perfectly good virus-free clone of your hard drive? And
> then simply clone that "good" previously cloned hard drive to the
> virus-infected
> one so that once again you now have two perfectly good hard drives. And in
> the case where the hard drive is kaput because of some
> mechanical/electronic failure, you purchase a new hard drive, simply
> remove the defective drive from the removable tray, plop in the new one,
> make two simple connections, shove it in the computer and then clone your
> good hard drive to the new one. And the added beauty of this arrangement
> is that you do all this from the comfort of your computer chair. There's
> no need to open your computer case and get into the "guts" of your
> computer to make complicated cable disconnects/connects. Everything is
> done outside of your computer because each hard drive resides in a tray
> (caddy) that you simply slide into the computer's mobile rack.
>
> There's *no* need to partition and format the new drive; *no* need to
> reinstall your operating system on the new drive; *no* need to reinstall
> your programs and data files. None of this is necessary. By simply cloning
> the
> previously-cloned hard drive to the new drive you once again have two
> functioning hard drives at your disposal.
>
>
> As previously indicated, these mobile rack devices are two-part affairs -
> the rack itself and the inner tray (caddy) in which the hard drive resides
> that slides into the rack. They come in all-aluminum models or a
> combination of aluminum-plastic ranging in price from about $15 to $50.
> Naturally, your desktop computer case will need two 5¼" bays that are
> available to house the mobile racks. Mobile racks come in various
> versions, depending upon whether the hard drive to be housed is an
> IDE/ATA, SATA, or SCSI device. A Google search for "removable hard drive
> mobile racks" will result in a wealth of information on these products and
> their vendors. I'm aware of many users who have been using inexpensive
> plastic mobile racks without any problems whatsoever. Unfortunately, there
> is no industry standard involving the design and construction of the racks
> nor the inner trays that contain the hard drive.Consequently, there is
> (usually) no interchangeability of these trays among the various
> manufacturers of mobile racks. Indeed, there is frequently no
> interchangeability of the inner trays among different models from the same
> manufacturer. This lack of interchangeability may not be an issue if the
> user will be purchasing a particular model of mobile rack for a single
> computer, however, if the user will have access to other computers, he or
> she may want to settle on a specific brand and model of mobile rack that
> will provide for tray interchangeability amongst different computers.
>
> As I've previously indicated, the cloning process itself is easy and
> relatively fast. Using Symantec's Norton Ghost 2003 cloning program as an
> example, with the two removable hard drives connected to the computer, you
> simply boot up your desktop computer with the bootable floppy disk that
> contains the Ghost program and after a few key clicks the cloning process
> begins. The cloning process is practically automatic and you need not be
> in attendance during the actual cloning operation. The size (disk
> capacity) or make/model of your hard drives need not be identical; all
> that matters is that your destination drive contains sufficient capacity
> to receive the contents of your source drive. Incidentally, I've recently
> been experimenting with the Acronis True Image program because of the many
> favorable reports I've come across about this program. Using a bootable
> ATI CD, I find the cloning speed of this program is considerably faster
> than that of Ghost. And so far I've run into no problems with the cloning
> process itself. Depending upon the speed of your processor and hard drives
> you should get cloning speeds of somewhere between 700 MB to 1.5+ GB per
> minute (less if cloning to a USB/Firewire external hard drive).
>
>
> I can virtually guarantee that once you begin working with two removable
> hard drives, you'll have but one regret and only one regret. And that is
> you didn't have this arrangement on your previous computer or computers.
> While the additional cost involved in configuring your desktop computer
> with two mobile racks together with the additional hard drive and disk
> imaging software is not negligible, I can assure you it's money well
> spent. Frankly, when you consider the enormous advantages of having two
> removable hard drives on your desktop computer, the additional cost of so
> equipping your computer in this fashion practically pales into
> insignificance.
>
>
>
> Timothy mentions that in using the disk-to-disk cloning process, "You do
> need to know the syntax of a boot.ini file, though". Insofar as the
> cloning process that I've described above is concerned, there is *no* need
> that I'm aware of to manipulate boot.ini syntax. A clone is a clone is a
> clone. When you clone the contents of your working drive to the
> destination drive (bearing in mind we're talking about removable internal
> drives in their mobile racks), the destination drive, being for all
> practical purposes an exact duplicate of the source drive, is bootable and
> there's no need to edit its boot.ini file. If, however, I've misunderstood
> the thrust of Timothy's statement, I trust he will amplify his comment.
>
> Anna
>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.general (More info?)

"Anna" wrote:
>
> "Timothy Daniels" wrote:
>> I keep several clones of my system partitions on large capacity
>> IDE disks mounted in a removable trays, and each clone is bootable.
>> It really makes for quick recoveries. You do need to know the syntax
>> of a boot.ini file, though.
>
> Timothy mentions that in using the disk-to-disk cloning process, "You do
> need to know the syntax of a boot.ini file, though". Insofar as the cloning
> process that I've described above is concerned, there is *no* need that I'm
> aware of to manipulate boot.ini syntax. A clone is a clone is a clone. When
> you clone the contents of your working drive to the destination drive
> (bearing in mind we're talking about removable internal drives in their
> mobile racks), the destination drive, being for all practical purposes an
> exact duplicate of the source drive, is bootable and there's no need to edit
> its boot.ini file. If, however, I've misunderstood the thrust of Timothy's
> statement, I trust he will amplify his comment.


As you can see above, my mention of the boot.ini file was in
the context of archiving (and accessing) several bootable partitions
on the same backup drive. To be able to use the boot manager
(ntldr) and the system partition selection menu (boot.ini) to choose
the correct partition to boot, one must be able to understand and
edit boot.ini - whether boot.ini used resides on the primary system
drive or on the "active" partition of the archive drive.

As it is the "active" partition that gets control at boot time,
one must be aware which of the multiple system partitions on
a drive has been marked "active". (Use Disk Management to
see and set this flag: rt-clk on My Computer, clk Manage,
clk Disk Management.)

If you want to boot one of the systems on other than the primary
hard drive, you must put that hard drive at the head of the hard
drive boot order in the BIOS. And so, if the primary hard drive is
not removed from the system, it must be moved from its position
at the head of the boot order or its "active" partition will get control
at boot time - just as it always does.

Another caveat is that one must boot a cloned WinXP system for
the 1st time in isolation from its "parent", otherwise some sort of
"linking" takes place which makes the clone forevermore dependent
on the continued presence of it "parent". But once the clone has been
booted for the 1st time in isolation from its "parent", it becomes an
independent system, and subsequent boot-ups can be made with its
"parent" visible to it, and it merely sees the "parent" system as just
another Local Disk (i.e. a file structure), and files may very conveniently
be dragged 'n dropped between the two system partitions.

Removing a source hard drive from view of its clone can be
accomplished by physically unplugging its data cable or by unplugging
its power cable. To avoid having to open the PC's case each time
I boot a clone for the 1st time, I run the HD power cables through
miniature DPST toggle switches that I have mounted under the front
plastic bezel, reachable through the air intake vents. Before booting
up a clone, I throw the toggle switch first to remove the "parent" from
view of the clone.

To avoid the complication of making each boot.ini file unique
to the partition it resides in, I have just a large generic boot.ini file
that I use which has pointers to at least 4 partitions on every hard drive.
That way, any partition that gets control has a boot.ini file which can
point to any other partition to boot (including itself).

Of course, if you just put one clone on a backup HD, and you
never use that HD unless the "parent" HD has been removed due
to its failure, things are simple, and you never have to worry about
the above caveats. AND.... you can use Acronis True Image
(which clones an entire source HD to an entire destination HD)
and you don't have to use Ghost (which can take a specific
bootable partition from among several on the source HD and put
it among several other partitions on the destination HD.) Obviously,
for my purposes, I can't use Acronis' True Image, and I'm getting
ready to give Casper XP a try in order to avoid having to use Ghost
(which, in its previous life as Drive Image 7.03, has stopped working
in my system).

*TimDaniels*
 

anna

Distinguished
Apr 17, 2004
339
0
18,780
Archived from groups: microsoft.public.windowsxp.general (More info?)

>> "Timothy Daniels" wrote:
>>> I keep several clones of my system partitions on large capacity
>>> IDE disks mounted in a removable trays, and each clone is bootable.
>>> It really makes for quick recoveries. You do need to know the syntax
>>> of a boot.ini file, though.
>>

> "Anna" wrote:
>> Timothy mentions that in using the disk-to-disk cloning process, "You do
>> need to know the syntax of a boot.ini file, though". Insofar as the
>> cloning process that I've described above is concerned, there is *no*
>> need that I'm aware of to manipulate boot.ini syntax. A clone is a clone
>> is a clone. When you clone the contents of your working drive to the
>> destination drive (bearing in mind we're talking about removable internal
>> drives in their mobile racks), the destination drive, being for all
>> practical purposes an exact duplicate of the source drive, is bootable
>> and there's no need to edit its boot.ini file. If, however, I've
>> misunderstood the thrust of Timothy's statement, I trust he will amplify
>> his comment.


"Timothy Daniels" <TDaniels@NoSpamDot.com> wrote in message
news:lLqdnTocpbqbX0nfRVn-tw@comcast.com...
> As you can see above, my mention of the boot.ini file was in
> the context of archiving (and accessing) several bootable partitions
> on the same backup drive. To be able to use the boot manager
> (ntldr) and the system partition selection menu (boot.ini) to choose
> the correct partition to boot, one must be able to understand and
> edit boot.ini - whether boot.ini used resides on the primary system
> drive or on the "active" partition of the archive drive.
>
> As it is the "active" partition that gets control at boot time,
> one must be aware which of the multiple system partitions on
> a drive has been marked "active". (Use Disk Management to
> see and set this flag: rt-clk on My Computer, clk Manage,
> clk Disk Management.)
> If you want to boot one of the systems on other than the primary
> hard drive, you must put that hard drive at the head of the hard
> drive boot order in the BIOS. And so, if the primary hard drive is
> not removed from the system, it must be moved from its position
> at the head of the boot order or its "active" partition will get control
> at boot time - just as it always does.
>
> Another caveat is that one must boot a cloned WinXP system for
> the 1st time in isolation from its "parent", otherwise some sort of
> "linking" takes place which makes the clone forevermore dependent
> on the continued presence of it "parent". But once the clone has been
> booted for the 1st time in isolation from its "parent", it becomes an
> independent system, and subsequent boot-ups can be made with its
> "parent" visible to it, and it merely sees the "parent" system as just
> another Local Disk (i.e. a file structure), and files may very
> conveniently
> be dragged 'n dropped between the two system partitions.
>
> Removing a source hard drive from view of its clone can be
> accomplished by physically unplugging its data cable or by unplugging
> its power cable. To avoid having to open the PC's case each time
> I boot a clone for the 1st time, I run the HD power cables through
> miniature DPST toggle switches that I have mounted under the front
> plastic bezel, reachable through the air intake vents. Before booting
> up a clone, I throw the toggle switch first to remove the "parent" from
> view of the clone.
>
> To avoid the complication of making each boot.ini file unique
> to the partition it resides in, I have just a large generic boot.ini file
> that I use which has pointers to at least 4 partitions on every hard
> drive.
> That way, any partition that gets control has a boot.ini file which can
> point to any other partition to boot (including itself).
>
> Of course, if you just put one clone on a backup HD, and you
> never use that HD unless the "parent" HD has been removed due
> to its failure, things are simple, and you never have to worry about
> the above caveats. AND.... you can use Acronis True Image
> (which clones an entire source HD to an entire destination HD)
> and you don't have to use Ghost (which can take a specific
> bootable partition from among several on the source HD and put
> it among several other partitions on the destination HD.) Obviously,
> for my purposes, I can't use Acronis' True Image, and I'm getting
> ready to give Casper XP a try in order to avoid having to use Ghost
> (which, in its previous life as Drive Image 7.03, has stopped working
> in my system).
>
> *TimDaniels*


Tim:
Thanks for your response.

Just so there's no misunderstanding, let me reiterate (in summary form) my
previous comments and recommendations concerning the use of removable hard
drives and the disk cloning process.

Using two removable hard drives in their mobile racks, the user (via a disk
imaging program such as Symantec's Norton Ghost or Acronis True Image) can
clone the contents of one drive to another drive. Assuming the user is
cloning the contents of his/her working hard drive to the second removable
HD, the user will now have (for all practical purposes) a bit-for-bit copy
of his/her working HD. As such, that second drive, being an exact duplicate
of the user's source disk, will be bootable. Under those circumstances there
will be *no* need to modify the boot.ini file or any other file in order
that the cloned drive be bootable.

Should the working HD's operating system subsequently become corrupt for one
reason or another, the user can re:clone the contents of his/her second HD
to the working drive for restoration purposes. Again, the working drive will
be bootable & functional and there will be *no* need to modify the boot.ini
file or any other file in order to achieve that functionality.

I trust we are agreed on the above.

As you point out, it is wise to boot to the newly-cloned drive following the
cloning process. For one thing, it's desirable to check that the clone
"took" and that the user now has a bootable, functioning copy of his/her
working HD. Both Symantec and Acronis recommend this course of action.
Indeed, as a general proposition, they both recommend disconnecting one or
the other drive so that both drives are not simultaneously connected during
normal operations. In the hundreds of times (after having used the Ghost
2003 program to perform the cloning operation) that I've worked with both
the working (source) drive and the cloned drive connected, except for a
single instance that I remember, I can't recall running into any problem
because both drives were connected. But having said this, we *do* recommend
that only one drive be connected during normal operations. And that's
another reason why having two removable hard drives is such a desirable
configuration. A simple turn of the keylock and the drive residing in that
mobile rack is turned off. And the user is able to boot to whichever drive
he/she desires. The simplicity and effectiveness of it all is nearly
breathless.

So, to summarize. In my view, equipping one's desktop computer with two
removable hard drives is an extraordinarily desirable configuration for
many, if not most, users. Through use of the disk cloning process as
previously described, the user is able to establish & maintain a
near-failsafe backup system. And do so in a routine manner simply and
reasonably quick.
Anna
 
G

Guest

Guest
Archived from groups: microsoft.public.windowsxp.general (More info?)

"Anna" wrote:
>
>>> "Timothy Daniels" wrote:
>>>> I keep several clones of my system partitions on large capacity
>>>> IDE disks mounted in a removable trays, and each clone is bootable.
>>>> It really makes for quick recoveries. You do need to know the syntax
>>>> of a boot.ini file, though.
>>>
>
>> "Anna" wrote:
>>> Timothy mentions that in using the disk-to-disk cloning process, "You do
>>> need to know the syntax of a boot.ini file, though". Insofar as the
>>> cloning process that I've described above is concerned, there is *no*
>>> need that I'm aware of to manipulate boot.ini syntax. A clone is a clone
>>> is a clone. When you clone the contents of your working drive to the
>>> destination drive (bearing in mind we're talking about removable internal
>>> drives in their mobile racks), the destination drive, being for all
>>> practical purposes an exact duplicate of the source drive, is bootable
>>> and there's no need to edit its boot.ini file. If, however, I've
>>> misunderstood the thrust of Timothy's statement, I trust he will amplify
>>> his comment.
>
>
> "Timothy Daniels" <TDaniels@NoSpamDot.com> wrote in message
> news:lLqdnTocpbqbX0nfRVn-tw@comcast.com...
>> As you can see above, my mention of the boot.ini file was in
>> the context of archiving (and accessing) several bootable partitions
>> on the same backup drive. To be able to use the boot manager
>> (ntldr) and the system partition selection menu (boot.ini) to choose
>> the correct partition to boot, one must be able to understand and
>> edit boot.ini - whether boot.ini used resides on the primary system
>> drive or on the "active" partition of the archive drive.
>>
>> As it is the "active" partition that gets control at boot time,
>> one must be aware which of the multiple system partitions on
>> a drive has been marked "active". (Use Disk Management to
>> see and set this flag: rt-clk on My Computer, clk Manage,
>> clk Disk Management.)
>> If you want to boot one of the systems on other than the primary
>> hard drive, you must put that hard drive at the head of the hard
>> drive boot order in the BIOS. And so, if the primary hard drive is
>> not removed from the system, it must be moved from its position
>> at the head of the boot order or its "active" partition will get control
>> at boot time - just as it always does.
>>
>> Another caveat is that one must boot a cloned WinXP system for
>> the 1st time in isolation from its "parent", otherwise some sort of
>> "linking" takes place which makes the clone forevermore dependent
>> on the continued presence of it "parent". But once the clone has been
>> booted for the 1st time in isolation from its "parent", it becomes an
>> independent system, and subsequent boot-ups can be made with its
>> "parent" visible to it, and it merely sees the "parent" system as just
>> another Local Disk (i.e. a file structure), and files may very
>> conveniently
>> be dragged 'n dropped between the two system partitions.
>>
>> Removing a source hard drive from view of its clone can be
>> accomplished by physically unplugging its data cable or by unplugging
>> its power cable. To avoid having to open the PC's case each time
>> I boot a clone for the 1st time, I run the HD power cables through
>> miniature DPST toggle switches that I have mounted under the front
>> plastic bezel, reachable through the air intake vents. Before booting
>> up a clone, I throw the toggle switch first to remove the "parent" from
>> view of the clone.
>>
>> To avoid the complication of making each boot.ini file unique
>> to the partition it resides in, I have just a large generic boot.ini file
>> that I use which has pointers to at least 4 partitions on every hard
>> drive.
>> That way, any partition that gets control has a boot.ini file which can
>> point to any other partition to boot (including itself).
>>
>> Of course, if you just put one clone on a backup HD, and you
>> never use that HD unless the "parent" HD has been removed due
>> to its failure, things are simple, and you never have to worry about
>> the above caveats. AND.... you can use Acronis True Image
>> (which clones an entire source HD to an entire destination HD)
>> and you don't have to use Ghost (which can take a specific
>> bootable partition from among several on the source HD and put
>> it among several other partitions on the destination HD.) Obviously,
>> for my purposes, I can't use Acronis' True Image, and I'm getting
>> ready to give Casper XP a try in order to avoid having to use Ghost
>> (which, in its previous life as Drive Image 7.03, has stopped working
>> in my system).
>>
>> *TimDaniels*
>
>
> Tim:
> Thanks for your response.
>
> Just so there's no misunderstanding, let me reiterate (in summary form)
> my previous comments and recommendations concerning the use of
> removable hard drives and the disk cloning process.
>
> Using two removable hard drives in their mobile racks, the user (via
> a disk imaging program such as Symantec's Norton Ghost or Acronis
> True Image) can clone the contents of one drive to another drive.
> Assuming the user is cloning the contents of his/her working hard drive
> to the second removable HD, the user will now have (for all practical
> purposes) a bit-for-bit copy of his/her working HD. As such, that
> second drive, being an exact duplicate of the user's source disk,
> will be bootable. Under those circumstances there will be *no* need
> to modify the boot.ini file or any other file in order that the cloned
> drive be bootable.


That is true only if the destination HD contains only the clone of
the system partition in the source HD. If it contains several bootable
system partitions, the boot.ini file in each of them must know where
it is relative to the other partitions, OR the boot.ini file must have
enough pointers to partitions within it such that the aware user can
specify which partition to boot.



> Should the working HD's operating system subsequently become
> corrupt for one reason or another, the user can re:clone the contents
> of his/her second HD to the working drive for restoration purposes.
> Again, the working drive will be bootable & functional and there will
> be *no* need to modify the boot.ini file or any other file in order to
> achieve that functionality.


That is true only if the second HD contains only a cloned system
partition which comprise the entirety of the source HD when they
were copied.

The difference between your and my viewpoints involves the
storage of multiple versions of the primary system partition. You
assume that the primary HD contains only one system partition
and that the entire HD is copied to a second HD and that there
are no other system partitions on the second HD. IOW, your
scheme clones HDs. My scheme clones system partitions,
putting several copies on the second HD (all bootable where they lie).
For your system to work, the primary HD must "disappear" so
that the second HD becomes "primary", that is, at the head of
the BIOS' hard drive boot order. That is done by turning off the
power to the primary HD or by putting the second HD in its
place physically or by re-copying the clone back to the primary
HD.

My scheme allows for booting any one of the archived
system partitions directly from the second HD even with the
primary HD still visible to the BIOS. That has the advantage
of speed and provides the capability of dragging 'n dropping
individual files between any of the partitions on the two HDs.
But it also requires an understanding of boot.ini file syntax,
and it requires a cloning utility that can copy individual bootable
partitions and doesn't just copy the entire HD contents. Acronis
True Image cannot do this. Ghost *can* do this (and perhaps
Casper XP as well).


> I trust we are agreed on the above.


Only with the restrictions I mentioned above.


> As you point out, it is wise to boot to the newly-cloned drive following the
> cloning process. For one thing, it's desirable to check that the clone
> "took" and that the user now has a bootable, functioning copy of his/her
> working HD. Both Symantec and Acronis recommend this course of action.
> Indeed, as a general proposition, they both recommend disconnecting one or
> the other drive so that both drives are not simultaneously connected during
> normal operations. In the hundreds of times (after having used the Ghost
> 2003 program to perform the cloning operation) that I've worked with both
> the working (source) drive and the cloned drive connected, except for a
> single instance that I remember, I can't recall running into any problem
> because both drives were connected. But having said this, we *do* recommend
> that only one drive be connected during normal operations. And that's
> another reason why having two removable hard drives is such a desirable
> configuration. A simple turn of the keylock and the drive residing in that
> mobile rack is turned off. And the user is able to boot to whichever drive
> he/she desires. The simplicity and effectiveness of it all is nearly
> breathless.
>
> So, to summarize. In my view, equipping one's desktop computer with two
> removable hard drives is an extraordinarily desirable configuration for
> many, if not most, users. Through use of the disk cloning process as
> previously described, the user is able to establish & maintain a
> near-failsafe backup system. And do so in a routine manner simply and
> reasonably quick.
> Anna
 

TRENDING THREADS