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:[EMAIL PROTECTED]] >Sent: Wednesday, November 21, 2001 2:05 AM >To: [EMAIL PROTECTED] >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 [EMAIL PROTECTED] +1 512 433 3300 > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 [EMAIL PROTECTED] +1 512 433 3300
