Re: Backing up the system


>> "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.

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



.

Relevant Pages

  • Re: Dual Boot Instructions
    ... the PHYSICAL DISK number, ... Partition and Boot Volume as well as other things. ... You should, at any one time, see ONE System Partition and ONE Boot Volume - ... for the typical two floppy drives and assigning Drive C: ...
    (microsoft.public.windows.vista.hardware_devices)
  • Re: Boot Problem
    ... Right mouse click the dest disk> Advanced> Edit ... but it should eventually boot to Windows. ... I see a lot of posts in here about the ability of Acronis to clone drives. ... I have managed to successfully copy by DELETING partition, ...
    (microsoft.public.windowsxp.hardware)
  • Re: Dual Boot Instructions
    ... OS on a separate partition. ... the PHYSICAL DISK number, ... You should, at any one time, see ONE System Partition and ONE Boot ... The name stuck when we added hard disk drives, ...
    (microsoft.public.windows.vista.hardware_devices)
  • Re: A Dual-boot question; I thought C was always the partition with the running OS
    ... The Server 2003 will then call its partion "C:" Local Disk. ... When Server 2003 starts up, it will call itself "C:" and it will call the WinXP partition "E:", but again, who cares? ... The OS then assigns drive letters to the first primary partition recognized on each successive hard disk. ... Because they're on separate hard drives, ...
    (microsoft.public.windowsxp.setup_deployment)
  • Re: Seagate(Acronis) cloning not working right.
    ... I am trying to clone my Disk ... Presumably the HDD to be cloned, i.e., the "source" disk, will be ... The next screen will indicate the source and destination drives. ...
    (microsoft.public.windowsxp.hardware)
Loading