At 05:57 PM 9/29/2008, steve sorenson wrote:
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?
True. I don't know if IBM has announced a date yet.
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?
True, for serial disk storage pools (not random access). Not
tape. Assuming they don't change directions, this will happen with the
same release as DB2.
3. What interesting features have arrived since 5.3 (e.g. active datapools),
and what interesting features are expected in the next release?
Refer to the IBM TSM versions 5.4 and 5.5 Technical Guide, at
http://publib-b.boulder.ibm.com/abstracts/sg247447.html?Open.
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?
I'll leave this for others. I've never used NBU.
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.
TSM can migrate from random-access disk to serial (tape), simultaneously
copying to the copy pool(s). I don't have first-hand experience with this,
but plan to soon.
2. Image backup (for a drive with millions of files) didn't support
file-level restore.
AFAIK, this is still the case. But you can combine image with file-level
incremental to get fast restore and also file-level restore. Yes, this
will take more storage resources. You can also base an incremental off of
an image backup.
3. All migration/reclamation activities had to be done on the TSM server
(the LAN-free storage agents couldn't help)
Still true. Never been a problem for me, tho.
4. Upgrading TSM clients to the latest version had to be done manually at at
client.
Alas, still true. But perhaps for good reasons.
5. You couldn't restore from a backup set using typical TSM GUI/command
(they are designed for use outside of TSM)
I'll leave this for others. We've never used backupsets.
6. Adaptive subfile backup would require multiple tapes to restore a single
file, as parts of the file would be spread out across tapes.
Well, theoretically this could happen, but if you use collocation (or
disks), it won't be a problem. If you have lots of data, you'd probably
want to use collocation. There are three options (by storage
pool): filespace, node, or collocation group (groups of nodes).
Thanks in advance for your help. Please be kind as TSM is not my native
language. :)
Not at all. Good luck with your analysis. One of the best things about
TSM is the community of users that has developed over the years.
..Paul
--
Paul Zarnowski Ph: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801 Em: psz1 AT cornell DOT edu
| 