Help me repel the enemy: TSM

[goony]

I work in a medium-sized corporation that has IBM mainframes, Intel/Windows servers and Sun/Solaris (Unix) boxes. The department that I am in supports the Sun/Solaris stuff.

I've been using Legato Networker for 5+ years now and while I've cussed it on a few occasions, basically it works very, very well for backing up and restoring our 40+ Sun and Linux boxes. We backup to disk, then stage the oldest savesets to LTO3 tape. We have some unusual requirements on a few systems that have .nsr files with some specific directives of files that need to be skipped. Often, we have requests to restore files from production onto different servers in the development/test area and that's no problem using Legato Networker.

We have built a number of reporting tools around the command line capabilities of the mminfo program. Our staff knows and understands the Networker product and has a real "comfort level" about the product.

Whenever we do a "disaster recovery" drill our Legato Networker server is always able to be restored and the restores of selected servers go well and we're able to have our systems running far sooner than the IBM mainframe or the Windows/Intel folks (they both rely on Tivoli Storage Manager).

------------

All was well until my manager came to me a few days ago and said that "a bigwig upstairs" went to one of those Gartner-type symposiums and was told how much money could be saved by standardizing on a single TSM storage solution across all of the departments and ditching any other existing backup solutions.

It seems they must have drank copious amounts of the Kool-Aid while there because they returned with a gleam in their eye and chomping at the bit to rip out what is working very, very well and replace it with TSM.

-------------

I'm going to attempt to mount a justification for our department to remain with Legato Networker. I'm asking here if anyone can think of a technical angle that I might use for ammunition since I'm not familiar with TSM at all. I have no doubts that it is good stuff, but how much better can it be that what is working well already?

Of course, I'll point out many of the non-technical reasons of not pursuing this course of action, along with "If it's not broke, don't try to fix it" approach.

Thanks!

 

[605]

I have no TSM experience either, but make your manager clear how much he needs to (indirectly) invest in education and the fact, that building up experience will just take its time. And this has to be paid for as well.

 

[Chapter11]

You cannot use technical angles with management. Ever.

Figure out how much it would cost to convert the TSM environment to Networker (and if anyone complains, call it "due diligence"). Don't bother including training costs or media costs, since the sales presentation (don't mistake it for a technology symposium) didn't include those either.

Also figure the cost of maintaining your infrastructure as it is.

In short, give him 3 numbers: No Change, Networker environment, TSM environment. The *only* thing that will matter is the size of the number after the dollar sign.

 

[goony]

You cannot use technical angles with management. Ever.

You would think I have learned that by now, but I haven't... I'm ever the optimist.

Thanks to both for the advice - I'll see what I can come up with.

 

[minzbigr]

I am currently in the process of migrating from TSM5.3 to Networker7.3.2. I wasn't in on "ground-up" building of TSM, but once it got given to me, found it to be very cumbersome for our size operation. I've always been told that TSM works better for larger operations. I have been involved from the beginning, with the Networker install and found it to be fairly easy to work with, even though like anything, it has it's quirks during setup/etc.

I have to agree with everyone else though, unless there is some pressing need to switch backup platforms, don't. "If it ain't broke, don't fix it." Obviously sight all the normal reasons: training, hardware costs, software costs, etc. Training is huge by the way. I've had to learn the hardway, how to manipulate both solutions and have had much better success with Networker.

 

[TDun]

i think your management spent too much time on the freebie juice as the idea is that a single solution tends (ok, almost always) to end up cheaper.

This could have as easily been Networker.
Personally, I don't (yet) touc the readed TSM, but I prefer Networker over NetB***p.

Your management must also remebmer the overheads in keeping any legal requirements (e.g 7 years of data) and their respected overheads of keeping the systems to recover this if they switch to a totally different solution.

 

[goony]

Well, I've just scored somewhat of a coup with Networker - recently, the requirement for encrypted data has been suggested and I was able to implement that using NW, but it seems they cannot encrypt using Tivoli/TSM as it requires hardware tape encryption and the disaster site company we contract with doesn't have compatible hardware!

NW, using software-based encryption, can decrypt on any system as long as you have the proper tape drives to read the tapes and the correct passphrase for the 256-bit AES encryption.

Maybe I can stave off the assault on Networker after all!

Oh, but there's a caveat that I ran into with NW encryption, which I'll post in a separate topic. Gist: You cannot have NW do encryption AND data compression - you have to choose one or the other.

 

[Martin999]

Consider this ...

You have NW, and retention times that vary from probably a month to a several years.

What if you want this data back ??? (Yes, I know it can be done by 3rd parties, but at what cost ?)

So, certainly for the "swap over" you would need to run NW and TSM in parallel so will need extra drives and silos ...

I'm not convinced that TSM is better in large setups (dep[ends how you define large I guess). We backup 50-60 TB a day with a >98.5% success rate (on average).

Bye bye cost saving ...

Martin

 

[Chapter11]

The downside of NW's software encryption is that it creates a lot of CPU overhead on the clients. If you're running, or heading for, a virtualized environment, you're going to have to manage CPU time availability as an extra client factor for your backup window.

Most DR facilities do not have any of the major HW crypto devices yet, you'd have to provide one yourself, and that's why we haven't done it yet either. I believe it's something they're going to need to do eventually, but it's expensive to support.

As for data retention, you can always restore data with a demo license for NW, so you don't *have* to maintain an active NW system for that.