Geoff,
To add to Wanda's point #6 regarding "recoverability in 10 years".
   It is relatively simple (but time consuming) to transfer old data to
new media by simply creating a storage pool for that new media and
running a "move data" command.  If you upgrade to a new TSM server, it
is also simple (but takes a bit of time) to move data from the old
server to the new server attached to media incompatible with the old
server with the "export node" command.  That will leave only the
recovery target operating system and application to worry about in 10
years (after you devine the current TSM licensing conspiracy).

The incremental forever methodology takes a bit getting used to if you
come from the Gf-F-S world, but once you really sit down and think about
long term recovery with no data holes, it really fits nicely.

Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Wanda Prather
Sent: Tuesday, January 20, 2009 2:48 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Transfer/transition netbackup data to TSM

1) TSM is designed to scale to very, very large configurations.

2) The amount of data we have to deal with is growing rapidly throughout
the industry.  I have customers that are seeing data growth of more than
50% per year; with the growth in non-text data (video & images) and the
cost of storage dropping rapidly, 50% growth per year is probably on the
low side.
In this environment, it just doesn't make sense to adopt a technology
that requires you to do repeatedly send data that hasn't changed across
your network.

3) If you are involved with a grandfather/father/son backup technology,
there are holes in that system.  Typically people who use non-TSM backup
software do something like weekly fulls and daily incremnentals.  The
fulls go into the vault a some point, say monthly for a year.  If you
have a file that is created on a Tuesday, and accidentally deleted on a
Thursday, after a few months you have no backup copy of that file
because it isn't on a full dump tape.  TSM won't let that happen:  if
you are supposed to have backups of that file, you WILL have backups of
that file.  GF-F-S backup softare manages tapes.  TSM manages your data.

4) By using TSM incremental-only, you get a no holes backup system (i.e.
better backup coverage) and you use less media (therefore less$$) to do
it, because you don't need full dumps.

5) TSM DRM gives you a recovery plan, you don't have to create it
yourself.

6) The most important and least-advertised feature of TSM ( I think
because the sales folk seldom understand the difference):

Not all data has the same value to the organization.  I don't need to
keep backups of Windows executables forever; I need legal records 7
years and I need patient data lots longer.  With increasing regulations
regarding records retention (SOX, HIPPA, general liability, etx.), it's
more important than ever to recognize and enforce retention rules
properly.

TSM lets you treat different data differently; you can assign different
backup frequencies and different retention rules to different data,
based on its value and retention requirements.

W




On Tue, Jan 20, 2009 at 2:24 PM, Gill, Geoffrey L.
<GEOFFREY.L.GILL AT saic DOT com
> wrote:

> Hi all,
>
>
>
> I am trying to put together an email stating all the reasons TSM is
> the way to go and to 'hopefully' dump our netbackup system. For those
> that we know will be refusing to move for one reason or another I want

> to be able to have answers for questions they might bring up or
> statements they may try to use to state why this is 'impossible'. I
> have a list with some thing and am trying to work out answers but
> would certainly love input from anyone who may have gone through this
> in the past. If you know of a document out there I might reference
that would also help.
> Feel free to mention it no matter how simple you might think it is or
> even how irrelevant you think someone else thinks it is.
>
>
>
> We have some major changes going on here and I am trying to take
> advantage while the time is right to see if I can get this thing
> dumped before it grows any further. The folks that brought it in are
> gone or no longer in a position to oppose this so I'm trying to put
> together something that will hopefully do the trick.
>
>
>
> If you think you should reply to me personally please also feel free
> and I certainly appreciate the help.
>
>
>
> Geoff Gill
> TSM Administrator
> PeopleSoft Sr. Systems Administrator
> SAIC M/S-G1b
> (858)826-4062 (office)
>
> (858)412-9883 (blackberry)
> Email: geoffrey.l.gill AT saic DOT com
>
>
>

IMPORTANT: E-mail sent through the Internet is not secure and timely delivery 
of Internet mail is not guaranteed. Legg Mason therefore, recommends that you 
do not send any  action-oriented or time-sensitive information to us via 
electronic mail, or any confidential or sensitive information including:  
social security numbers, account numbers, or personal identification numbers.

This message is intended for the addressee only and may contain privileged or 
confidential information. Unless you are the intended recipient, you may not 
use, copy or disclose to anyone any information contained in this message. If 
you have received this message in error, please notify the author by replying 
to this message and then kindly delete the message. Thank you.