ADSM-L

Re: Total newbie question about DB Backups

2006-09-21 11:51:31
Subject: Re: Total newbie question about DB Backups
From: "Smith, I (Ian)" <Ian.Smith AT RABOBANK DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 21 Sep 2006 16:49:45 +0100
 
For protection ensure that the ROLL FORWARD mode is on and there is
enough log space to take account for load during the period between TSM
DB Backups. This can be up to 13.2GB. Also set the Database backup
trigger, and ensure there is always scratch tapes. Put the DB and Log
volumes on different physical disks and both are TSM mirrored-ensure the
Log has sequential mirrorwrite set.

I would advise a scheduled DB backup after all the offsite volumes are
created. i.e 1 DB backup per day.

The Roll Forward mode will then allow you to recover the database from
tape and roll it forward from the transactions in the log.

Volhist will show the DBBackup tapes:

select * from volhistory where type='BACKUPFULL'

_____________________________
Ian Smith
SAN/TSM Specialist
Hitachi Data Systems Certified Professional
IBM Tivoli Storage Manager Certified Consultant



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Angus Macdonald
Sent: 21 September 2006 16:36
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Total newbie question about DB Backups

Okay, I may rely on mirroring then. If I do a DB backup every 4 hours
it'll cost 6 tapes a day and each one will only have a few MB of data.

For some reason, the tapes used for DB Backup aren't listed when I
execute a Q VOL. Something else to investigate.

Thanks again.

-----Original Message-----
From: PAC Brion Arnaud [mailto:Arnaud.Brion AT PANALPINA DOT COM]
Sent: 21 September 2006 16:28
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Total newbie question about DB Backups


Hi Angus !

You'll probably get somehow disapointed, but there's no way to do what
you're asking !
TSM wants a new tape for each DB backup, and the only way to spare your
precious scratch volumes would be to use some form of disk storage, thru
the mean of a sequential-on-disk device class ...

HTH.

Cheers

Arnaud

************************************************************************
******
Panalpina Management Ltd., Basle, Switzerland, CIT Department
Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone:  +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.brion AT panalpina DOT com
************************************************************************
******

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Angus Macdonald
Sent: Thursday, 21 September, 2006 17:11
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Total newbie question about DB Backups

I'm just in the process of implementing TSM 5.3 for the first time in
our environment and I'm following the TSM Implementation Guide (June
2006
edition) redbook very closely ;-) Things are going pretty well so far
but I have a bit of an issue with my database backups. Every DB backup
seems to use another scratch tape so my 3582 is going to run out of
tapes very quickly. My backup command is

Backup DB type=full devc=lto2-dc

lifted directly from the redbook. How can I limit the number of tapes
used for DB backups? I tried limiting the backup to a particular tape
volume but the tape is apparently in use after the first backup and
cannot be reused.

Angus
_____________________________________________________________

This email (including any attachments to it) is confidential, legally 
privileged, subject to copyright and is sent for the personal attention of the 
intended recipient only. If you have received this email in error, please 
advise us immediately and delete it. You are notified that disclosing, copying, 
distributing or taking any action in reliance on the contents of this 
information is strictly prohibited. Although we have taken reasonable 
precautions to ensure no viruses are present in this email, we cannot accept 
responsibility for any loss or damage arising from the viruses in this email or 
attachments. We exclude any liability for the content of this email, or for the 
consequences of any actions taken on the basis of the information provided in 
this email or its attachments, unless that information is subsequently 
confirmed in writing. If this email contains an offer, that should be 
considered as an invitation to treat.
_____________________________________________________________