ADSM-L

Re: tsm internal design?

2002-06-07 12:01:33
Subject: Re: tsm internal design?
From: Roger Deschner <rogerd AT UIC DOT EDU>
Date: Fri, 7 Jun 2002 10:59:48 -0500
I've actually been thinking about this for a while. All I can come up
with is that WDSF/ADSM/TSM is a "pretty good relational database
management system" with backup features bolted on.

So, if you can explain to your students the database tables that
comprise TSM, you've about explained everything other than what's
covered in a generic text on relational database systems. There's not
much else to TSM other than those tables in a DBMS, with some device
drivers, user interfaces, timers, and such wrapped around it.

At the time, around 1990, IBM had a number of similar implementations of
its basic, sound relational database model going. The major example of
this model is IBM's popular and powerful DB2 database system. They
developed two separate (but similar) file systems on this model - the
VM/CMS Shared File System, and the AIX Journaled File System. Then
somebody said, "I think a good database could solve a lot of backup
problems." So WDSF was invented, and now after three name changes and
ports from its VM/CMS home to numerous other platforms, we have IBM TSM.
The database gurus here are constantly in awe, because my database (TSM)
is much larger and much more active than theirs.

You don't have to look very deeply under the covers to see this. Once
you get used to the SQL-style SELECT command in the TSM Administrator
session, you will see that most of the QUERY commands are really just
pretty wrappings around SELECT. Those drop-jawed database gurus are
useful to me for assistance in writing complex SELECT statements that I
need sometimes, or I just enter them straight out of "SQL For Dummies".
What is amazing is that it all just works. TSM really is just a
garden-variety SQL-driven relational DBMS that has been utilized to do
backups, by defining appropriate tables and adding device drivers.

An intersting part of TSM has been the evolution of the clients. They
still depend on the interface to the server database. The way a standard
TSM Progressive Backup (new IBM terminology for what they used to call
"incremental") works is to download the portion of the database for that
client to the workstation, see what has changed, and back those files
up. No matter how much the client programs evolve, this is still the
standard TSM operational model - totally based on the all-knowing server
database. This model is so efficient, that it enabled the whole concept
of backups over a network, which had never been considered feasible
before WDSF's breakthrough database-centric method came along. The older
"weekly full plus daily incremental" backup model could obviously never
work on a network, at least not unless you have an unlimited networking
budget or close friends at Cisco. As hard drives on standard desktop PCs
continue to balloon in size, the efficiency of this model continues to
be the best way to back them up.

It is also this database foundation that separates TSM from all other
backup systems, and makes it so superior to them. All the other systems
start by backing things up pretty well, and then as an afterthought,
decide they need to keep track of what was backed up. That is backwards.
TSM does it right.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
======I have not lost my mind -- it is backed up on tape somewhere.=====



On Thu, 6 Jun 2002, Justin Bleistein wrote:

>I'm planning on taking over classes at a local community college teaching
>classes about Unix operating system design, teaching the super block
>design, inode assignment design, system calls, file descriptor table
>designs etc. I want to try to put together a TSM internals design
>curriculum as well and I was wondering does anyone know of any books or
>online documentation which explains the design of TSM from an internals
>perspective? Is there any documentation for geeks like us?. Any suggestions
>would be appreciated thanks! The best I can do right now is explain the
>different database tables. I'm looking for something more in depth. Like
>what the "dsmfmt" command is actually doing, under the covers. thanks!
>
>--Justin Richard Bleistein
>
<Prev in Thread] Current Thread [Next in Thread>