An interesting paper on an obviously VERY large TSM system, involving
upwards to 40 TSM servers.  Your problem was that you did not want to
send 40 tapes offsite everyday with each tape containing a single backup
of a TSM server DB.  So your elegant solution was to create a TSM server
instance, TSMDBB, and have the 40 TSM servers backup to TSMDBB.  This
means that you only had to dedicate a single tape to a single TSM server
DB backup, specifically  when you were backing up the TSM DB on TSMDBB.
(Actually you said you would back up TSMDBB to a disk file and then copy
that file to several locations, but the principle is the same.)  This is
an elegant way to reduce the number of daily TSM DB backup tapes from 40
to 1, however Lucian is already at the point of only having to send off
a single TSM DB backup tape per day.

H. Milton Johnson

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
asr AT UFL DOT EDU
Sent: Thursday, September 16, 2004 11:17 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: each dbbackup to new tape?

==> In article
<OF734B3080.AD152C1C-ONC1256F10.00481344-C1256F10.0048ABD2 AT mkv DOT de>,
Lucian Greis <lgreis AT MKV DOT DE> writes:


> I'm rather green with TSM, actually working through my first 
> client-project with it and have come to a (small for sure) problem
> System: TSM 5.2 on SuSe SLES8, feeding an Adic Scalar24 with one
IBM-LTO2.
> Basically, the system works.
> Whenever I command a dbBackup, wether full or incremetal, TSM wants to

> write to a scratch tape only. If i give the volser of a tape used for 
> an earlier dbbackup explicitly, TSM says the tape is full (which it is
not).
> Can someone point me to the right direction?



My solution to this involved a second server on the same physical
hardware.

The DB backups are to remote server volumes, which I can then copy and
send offsite.


I discuss the evolution of my desin in some detail (including some blind
alleys I went down) at:

http://open-systems.ufl.edu/services/NSAM/whitepapers/design.html



- Allen S. Rout