ADSM-L

Re: BMR for Win2k: Use of NTBACKUP

2001-11-21 10:38:29
Subject: Re: BMR for Win2k: Use of NTBACKUP
From: Ray Schafer <schafer AT TKG DOT COM>
Date: Wed, 21 Nov 2001 09:35:56 -0600
Yes, I do think the TCO is dependent on the number of machines you have
to protect, and to some extent the way you administer them.  For
example, if you build all your machines the same way, with the drives
and partitions clearly defined (i.e. disk0 is 18 GB and it is divided
into a 4 GB "C:" FAT32 partition and a 14 GB "D:" NTFS partition, then
clearly it is easier to know how the machines are partitioned when you
start the recovery process.  As you deviate from this rigidity, both the
administrative costs of keeping track of the machine configurations and
the potential for human error becomes greater.

On the other hand,  BMR saves this information automatically and uses it
to re-partition and format the drives for you and then restore the data
from TSM automatically.  This is nice because now you are no longer
bound by recovery constraints.  You  have complete freedom to partition
drives according to the needs of the applications.   Also, during a BMR
recovery,  one person can initiate multiple restores and sit back to
watch it all happen.   If you have a multiple server recovery, the more
manual methods - however minimal they may be - will gate the number of
simultaneous restores because they require an administrator to perform
manual steps at various points in the process (and hopefully an
administrator who knows this information is available for the restoration).

Salak Juraj wrote:

Hello Ray,

You are absolutely right we have to think in TCO (Total Costs of
Ownership) terms.
On the other side, the initial investment counts to TCO as well.

Generally speaking, the prices of each product,
will determinate the market share as well as other product attributes.


I had a look at your solution, found it great,
but its price limited its suitability for my business needs
substantially.


There really are disadvantages coming aling with simple solutions
but the extent is not necessarily as high as you mentioned.

The simpler solutions like those with
NTBACKUP or PcBax - to name only two -
are automatisable to a fair extent.
Typically you will  have to create a set of boot media (floppy)
for each node, and schedule the simple tool to
backup system state to a local file,
which is backed-up by TSM in turn.
Obviously, both backup and restore procedures
will require at least one step more than OTG,
but there is neither need for repeated manual tasks
nor for usage of local media.

If I had a w2k server farm I would, no doubt, prefer to use your tool.
For not so critical business with workstations
there are even manual fresh W2K installations cheaper for me.

Facit:  it depends :)

best regards
Juraj Salak
Asamer Familienholding







-----Original Message-----
From: Ray Schafer [mailto:schafer AT TKG DOT COM]
Sent: Wednesday, November 21, 2001 2:05 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: BMR for Win2k: Use of NTBACKUP


Michael Bartl wrote:

In a standard Win2k environment bare metal recovery using TSM doesn't
work. Of course, the Kernel Group BMR is a great tool, but expensive.

I think if you take into consideration all of the costs, TKG's BMR gives
a return on investment rather quickly.  With this solution, after the
initial installation, there is nothing to do except run your incremental
backups the way you do now.   All of the point solutions you have to
perform Bare Metal Restores are no longer needed.  No more local tape
drives or monitoring the processes, no more administrators time tracking
the backups, dealing with the media, wondering if you remembered
everything.  And we're not even talking about the time saved when you
actually have to use it for a Bare Metal Restore.   It is automated in
both daily operations and during the restoration.  That's where the
value comes in.

Weigh the entire solution: what it costs you before you implement BMR
and after.  Most companies get back their investment within the first 6
months of use.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message contains information which may be confidential
and privileged.  Unless you are the addressee (or authorized
to receive messages for addressee), you may not use, copy or
disclose to anyone the message or any information contained
in the message.  If you have received this message in error,
please advise the sender by reply email and delete the
message.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
Ray Schafer             The Kernel Group       www.tkg.com
Sr. Sales Engineer      schafer AT tkg DOT com    +1 512 433 3300



--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message contains information which may be confidential
This message contains information which may be confidential
and privileged.  Unless you are the addressee (or authorized
to receive messages for addressee), you may not use, copy or
disclose to anyone the message or any information contained
in the message.  If you have received this message in error,
please advise the sender by reply email and delete the
message.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
--
Ray Schafer             The Kernel Group       www.tkg.com
Ray Schafer             The Kernel Group       www.tkg.com
Sr. Sales Engineer      schafer AT tkg DOT com    +1 512 433 3300
<Prev in Thread] Current Thread [Next in Thread>