Re: Backing up the system

"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@xxxxxxxxxxxxx> wrote in message news:lLqdnTocpbqbX0nfRVn-tw@xxxxxxxxxxxxxx 
   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 

.

Loading