ADSM-L

[ADSM-L] NBU user considering switch to TSM

2008-09-29 17:59:55
Subject: [ADSM-L] NBU user considering switch to TSM
From: steve sorenson <nbu.user AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 29 Sep 2008 14:57:44 -0700
Hello all.  I'm a long-time user of NBU, but have recently started to
consider switching our backups over to TSM.  My coworker used TSM at a
previous company, but his experience was not as good as a friend of mine who
speaks very highly of TSM.  I have a basic understanding of TSM's
architecture, having perused some of the redbooks and poked around a bit in
this list's archives (I understand progressive incrementals, file-level
version-tracking, expiration, reclamation, collocation, etc), but my
coworker had some issues that I'm hoping have either been addressed or were
user errors on his part.  I'm familiar with TSM's advantages, and NBU has
its own list of issues to be sure, but I need to verify/debunk some of the
perceived TSM disadvantages before we call in a sales rep.  I thought that
this listserv would be a perfect place to get the straight scoop.

First, some clarification of good things I've heard about.  Is my
interpretation correct?

1. TSM will be migrating to a full DB2 database (if so, I think it would be
the only one to use such a full-featured database for backups).  When will
that happen?

2. TSM will be doing deduplication in the TSM server (after data has been
sent to the server).  Is this feature going to only apply to disk pools, or
will it dedupe tape as well?  When is this supposed to happen?

3. What interesting features have arrived since 5.3 (e.g. active datapools),
and what interesting features are expected in the next release?

4. Can anyone who has switched from NBU to TSM tell me of any advantages of
TDP & TSM's NDMP over NBU's approaches to that?

Now for the concerns my coworker has:

1. He could make simultaneous copies during the initial backup, but not
during migration and while copying to the copy pool.

2. Image backup (for a drive with millions of files) didn't support
file-level restore.

3. All migration/reclamation activities had to be done on the TSM server
(the LAN-free storage agents couldn't help)

4. Upgrading TSM clients to the latest version had to be done manually at at
client.

5. You couldn't restore from a backup set using typical TSM GUI/command
(they are designed for use outside of TSM)

6. Adaptive subfile backup would require multiple tapes to restore a single
file, as parts of the file would be spread out across tapes.

Thanks in advance for your help.  Please be kind as TSM is not my native
language. :)