Because when time comes to restore from this DB your volumes could be
already overwritten. Do you want this.
Check carefully disaster recovery procedure if your TSM server and primary
pool volumes are completely destroyed!
So if you want to restore DB which is 7 days old your volumes must be kept
from overwriting at least 7 days (or more)
Zlatko Krastev
IT Consultant
"Van Ruler, Ruud R SITI-ISES-31" <[EMAIL PROTECTED]> on
24.09.2001 15:59:42
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: copy storage pool volumes missing
Matthew
thanks for the quick response.
(q volhist type=dbb) only shows 4 tapes.
drmdbbackupexpiredays is set to 7. If uya005 was a DBB volume then uya005
should be available as from tomorrow !!!!
but this is not the case as uya005 contained client data:
copy storage pool STG_DATA_1C
For all copy storage pools (Delay Period for Volume Reuse) is set to 1.
why should it be greater or equal to drmdbbackupexpiredays ???
thanks.
Ruud van Ruler, Shell Information Technology International B.V. - ISES/31
Our Central Data Storage Management home page:
http://sww2.shell.com/cdsm/
> Room 1B/G01
> Dokter van Zeelandstraat 1, 2285 BD Leidschendam NL
Tel : +31 (0)70 - 3034644, Fax 4011, Mobile +31 (0)6-55127646
Email Internet: [EMAIL PROTECTED]
[EMAIL PROTECTED]
R.vanRuler
-----Original Message-----
From: Matthew Large [mailto:[EMAIL PROTECTED]]
Sent: maandag 24 september 2001 13:48
To: [EMAIL PROTECTED]
Subject: Re: copy storage pool volumes missing
if the tape contained a TSM database backup (q volhist type=dbb) then your
setting for drmdbbackupexpiredays has come into affect. find out the
setting
for that with 'q drmstatus'
if the tape contained normal client data, then your setting for
noreusedelay
will keep the tape offsite until it's passed. this setting shold be greater
than or equal to your drmdbbackupexpiredays setting. find noreusedelay in
your storage pool attributes (delay period for volume reuse)
these two reasons COULD explain why the tape wasn't returned.
hope this helps..
Matthew
-----Original Message-----
From: Van Ruler, Ruud R SITI-ISES-31
[mailto:[EMAIL PROTECTED]]
Sent: 24 September 2001 12:33
To: [EMAIL PROTECTED]
Subject: copy storage pool volumes missing
L&g
We have TSM4.2 on AIX 4.3 and 3584 LTO library.
09/10/01 UYA005, Mountable, 09/10/01, 06:04:50,
LIB_3584_1
on the 10th this volume UYA005 was moved to offsite vault using :
move drm * wherestate=mountable remove=untileefull
move drm * wherestate=notmountable tostate=vault
on the 17th
09/17/01 10:39:49 ANR1423W Scratch volume UYA005 is empty but will not
be
deleted - volume access mode is "offsite".
MOVE DRMEDIA * wherestate=vaultretrieve tostate=onsiteretrieve
09/17/01 10:40:21 ANR1341I Scratch volume UYA005 has been deleted from
storage pool STG_DATA_1C.
09/17/01 10:40:21 ANR6684I MOVE DRMEDIA: Volume UYA005 was deleted.
I would expect this tape to be returned from vault but it did not !!!!!!?
ps. this is not the only one.
any ideas ???? am I doing something wrong ???
q libv * * and q vol does not show these (kind of) tapes ...... is there
something else i could
use to identify these tapes ???
thanks.
Ruud van Ruler, Shell Information Technology International B.V. - ISES/31
Our Central Data Storage Management home page:
http://sww2.shell.com/cdsm/
> Room 1B/G01
> Dokter van Zeelandstraat 1, 2285 BD Leidschendam NL
Tel : +31 (0)70 - 3034644, Fax 4011, Mobile +31 (0)6-55127646
Email Internet: [EMAIL PROTECTED]
[EMAIL PROTECTED]
R.vanRuler
http://www.phoenixitgroup.com
******************Internet Email Confidentiality Footer*******************
Phoenix IT Group Limited is registered in England and Wales under company
number 3476115. Registered Office: Technology House, Hunsbury Hill Avenue,
Northampton, NN4 8QS
Opinions, conclusions and other information in this message that do not
relate to the official business of our firm shall be understood as neither
given nor endorsed by it.
No contracts may be concluded on behalf of our firm by means of email
communications.
Confidentiality: Confidential information may be contained in this message.
If you are not the recipient indicated (or responsible for delivery of the
message to such person), you may not take any action based on it, nor
should
you copy or show this to anyone; please reply to this email and highlight
the error to the sender, then delete the message from your system.
Monitoring of Messages: Please note that we reserve the right to monitor
and
intercept emails sent and received on our network.
Warning: Internet email is not 100% secure. We ask you to understand and
observe this lack of security when emailing us. We do not accept
responsibility for changes made to this message after it was sent
Viruses: Although we have taken steps to ensure that this email and any
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus
free.
