Hi, The resume issue goes away if the tape backup of the database backup flat files is a non-TSM backup. The probably of managing the non-TSM tapes is left as an exercise for the reader - but it can be done. Jim
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Rodriguez Sent: Wednesday, September 15, 2004 12:09 PM To: [EMAIL PROTECTED] Subject: Re: Antwort: Re: each dbbackup to new tape? 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, 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:[EMAIL PROTECTED] On Behalf Of >Lucian Greis >Sent: Wednesday, September 15, 2004 9:24 AM >To: [EMAIL PROTECTED] >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 <[EMAIL PROTECTED]> >Gesendet von: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> >15.09.2004 16:06 >Bitte antworten an "ADSM: Dist Stor Manager" > > An: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> >Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> >09/15/2004 08:13 AM >Please respond to >"ADSM: Dist Stor Manager" > > >To >[EMAIL PROTECTED] >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 > > > ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------
