I have to agree with Milton on this one.  It seems the system that you
describe has some issues that would make me want to have an updated resume!

Here is what I have been doing for many years.  There is basically 2
types of TSM DB backups, DBB which does fulls and incrementals and DBS
which is a snapshot of the DB similar to a full.  What I recommend is
that you configure two devices for DB backups, one of type=FILE (lets
cal it DBBUFILE) and one that uses some sort of reliable tape format
(lets cal lit DBBUTAPE)  you can decide on what tape after you read
further.

On a weekly basis I do a full DBB to device DBBUFILE.  On all other days
I do a incremental DBB to device DBBUFILE.  Also, I set my
DBBACKUPTRIGGER to use the DBBUFILE device( also set number of
incrementals high, i.e.32), this will allow for this most rapid DB
backups in the event that it is triggered by a log filling condition.
Furthermore in the event of a DB restore restoring from DBBUFILE if
available is very quick even if there are several incrementals since you
don't have to use multiple tapes!  Now what we have done so far is all
on site protection of the TSM DB.

For off site protection I use the DBS type DB backup and send it to
DBBUTAPE.  Then this tape can be taken off site.  The DBS type DB backup
only needs to be done on days you are going to take tapes off site.
This may make it more reasonable for you to use the larger capacity
tapes ( although the still will only be partially full) for off site
protection of the TSM DB.  If you are using DRM than you must make sure
that you specify that you are using DBS type backups for the off site DB
tapes.

Another note, if your TSM DB is set to ROLLFORWARD (which it should be)
than you must to DBB type backups on a regular basis in order for the DB
recovery log to be reset.  A DBS type backup is like a full DBB with the
exception that it does not reset the log!  Therefore on the days you
take tapes off site you will need to do both a DBB and a DBS backup.

In summary:

DBB for on site protection, done daily or more often.
DBS for off site protection, tapes taken off site.
DBBUFILE for on site, very fast and efficient backups and restores.
DBBUTAPE for off site, can use any tape media.1
DRM must be told you are using DBS for off site DB protection.
DBBACKUPTRIGGER should use device DBBUFILE with a high NUMINCREMENTAL value.

I hope this will give you some ideas on best practices for your site.

--
Regards,
Regards,
Mark D. Rodriguez
President MDR Consulting, Inc.

==============================================================================
MDR Consulting
The very best in Technical Training and Consulting.
IBM Advanced Business Partner
SAIR Linux and GNU Authorized Center for Education
IBM Certified Advanced Technical Expert, CATE
AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux
Red Hat Certified Engineer, RHCE
==============================================================================



Johnson, Milton wrote:

OK, I just have to jump in. If I understand Hoa he:
1) Backs up the TSM database to a disk file
2) backs up that disk file to a TSM disk storage pool using DSM
3) moves that db backup to onsite/offsite tapes using "backup stg" and
migration

If this is so, then what do you do when you have lost your current TSM
database?

In Hoa's case, I guess he can get restore a copy of the db backup from
his server located 11 miles away, if he has vaulted the files their and
that server can restore an that individual file from those "vaulted
tapes".

If however Lucian's case is more typical, having only one hot server,
then I believe your restoration procedure consists of telling your boss
you lost the entire TSM server along with all backups and then posting
your resume on monster.com. Of course you may not want to mention your
most recent employment.


H. Milton Johnson


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Lucian Greis
Sent: Wednesday, September 15, 2004 9:24 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Antwort: Re: each dbbackup to new tape?

Hi Hoa,

now this sounds interesting: I suppose I willhave to define a
"FileDrive"
device, since I belive that only device classes are allowed targets to
the dbbackup command. And then set up a nice small storagepool so the
file gets instantly transferred to tape...

Thanks for all responses to my question

Regards, Lucian





Hoa V Nguyen <nguyenhv AT US.IBM DOT COM>
Gesendet von: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
15.09.2004 16:06
Bitte antworten an "ADSM: Dist Stor Manager"

       An:     ADSM-L AT VM.MARIST DOT EDU
       Kopie:
       Thema:  Re: each dbbackup to new tape?


Lucian,

This is what we're doing to save 3592 tapes:

Incremental backup and full DB backup go to flat files, shift those
files to offsite or onsite to Disk Storage Poll and let migrate
functions put them on tapes.
(We have servers onsite & offsite 11 miles away for disaster).

Hoa.



Lucian Greis <lgreis AT MKV DOT DE>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
09/15/2004 08:13 AM
Please respond to
"ADSM: Dist Stor Manager"


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
each dbbackup to new tape?






Hi list,

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?

Regards, Lucian Greis
MKV GmbH