ADSM-L

Re: Automated / manual DRM actions

2004-01-14 02:16:00
Subject: Re: Automated / manual DRM actions
From: "Wijnbergen, AMv" <arnold.van.wijnbergen AT METRO-MCC DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 14 Jan 2004 08:15:04 +0100
Maybe this is what you're looking for.
Only one question ? Was the customer also not backupping the tapepool to
copypool ?
Maybe this could be the answer, because no updates ( changes) we're done on
the copypool. Then you cannot restore the tsm environment with the latest db
backup volume . You need the db backup ( in the DRM file) that was made
after the latest copypool backup, otherwise your drm plan is also useless.

Also the following dbbackup expiration condition could be interesting :

For volumes other than virtual volumes, all volumes in the series are in the
VAULT state.

I hope this helps


>From the Help at the db expire parameter .

This value should match the value of the Delay Period for Volume Reuse field
for the copy storage pool. This ensures that the database can be restored to
an earlier level and that database references to files in the storage pool
are valid.

A database backup volume is considered eligible for expiration if all of the
following conditions exist:

The age of the last volume of the series is greater than the expiration
value specified in this operation.
For volumes other than virtual volumes, all volumes in the series are in the
VAULT state.
The volume is not part of the most recent series. disaster recovery manager
does not expire the most recent database backup series.


>From the TSM Admin manual .

Moving Backup Volumes Onsite

Use the following procedure to expire the non-virtual database backup
volumes and return the volumes back onsite for reuse or disposal.

To specify the number of days before a database backup series is expired,
issue the SET DRMDBBACKUPEXPIREDAYS command. To ensure that the database can
be returned to an earlier level and database references to files in the copy
storage pool are still valid, specify the same value for the REUSEDELAY
parameter in your copy storage pool definition.
The following example sets the number of days to 30.

set drmdbbackupexpiredays 30

A database backup volume is considered eligible for expiration if all of the
following conditions are true:

The age of the last volume of the series has exceeded the expiration value.
This value is the number of days since the last backup in the series. At
installation, the expiration value is 60 days. To override this value, issue
the SET DRMDBBACKUPEXPIREDAYS command.
For volumes that are not virtual volumes, all volumes in the series are in
the VAULT state.
The volume is not part of the most recent database backup series.
Note:
Database backup volumes that are virtual volumes are removed during
expiration processing. This processing is started manually by issuing the
EXPIRE INVENTORY command or automatically through the EXPINTERVAL option
setting specified in the server options file.
Move a backup volume onsite for reuse or disposal when the volume is
reclaimed and:
The status for a copy storage pool volume is EMPTY.
The database backup series is EXPIRED.
To determine which volumes to retrieve, issue the following command:


query drmedia * wherestate=vaultretrieve

After the vault location acknowledges that the volumes have been given to
the courier, issue the following command:

move drmedia * wherestate=vaultretrieve

The server does the following for all volumes in the VAULTRETRIEVE state:

Change the volume state to COURIERRETRIEVE.
Update the location of the volume according to what is specified in the SET
DRMCOURIERNAME command. For more information, see Specifying Defaults for
Offsite Recovery Media Management.
When the courier delivers the volumes, acknowledge that the courier has
returned the volumes onsite, by issuing:
move drmedia * wherestate=courierretrieve

The server does the following for all volumes in the COURIERRETRIEVE state:

The volumes are now onsite and can be reused or disposed.
The database backup volumes are deleted from the volume history table.
For scratch copy storage pool volumes, the record in the database is
deleted. For private copy storage pool volumes, the access is updated to
read/write.
If you do not want to step through all the states, you can use the TOSTATE
parameter on the MOVE DRMEDIA command to specify the destination state. For
example, to transition the volumes from VAULTRETRIEVE state to
ONSITERETRIEVE state, issue the following command:
move drmedia * wherestate=vaultretrieve tostate=onsiteretrieve

The server does the following for all volumes with in the VAULTRETRIEVE
state:

The volumes are now onsite and can be reused or disposed.
The database backup volumes are deleted from the volume history table.
For scratch copy storage pool volumes, the record in the database is
deleted. For private copy storage pool volumes, the access is updated to
read/write.

Best Regards,
Met Vriendelijke Groet,
Mit freundlichen Gruessen,

Arnold van Wijnbergen

-----Oorspronkelijk bericht-----
Van: Alex den Hartog [mailto:dukeherd AT HOTMAIL DOT COM]
Verzonden: dinsdag 13 januari 2004 16:13
Aan: ADSM-L AT VM.MARIST DOT EDU
Onderwerp: Automated / manual DRM actions


Dear Listers,

Because of the holidays in the last two weeks of december (and the lack of
tapechanges because of absence of operators), a customer of ours
de-activated the scheduled copypool-reclamation to reduce the usage of
scratch-tapes in the library. In this way, the only scratch-tapes that were
going to be used were supposed to be database-backup tapes and
tapepool-tapes.

When the holiday started at the 16th of december, there were 26 scratch
tapes available in the (3584) library. When one of the operators checked the
status of the system on the 5th of januari, there were only 3 scratch tapes
left.

With dbbackupexpiredays set to 3 days, and no DRM checkout / checkin
activities during a period of about two weeks, is it correct that there are
20 mountable (db-tapes) waiting in the library on the 5th of januari?

Does TSM always need the  move drm  command to change the status from
 mountable  to  vault  to  vaultretrieve  to  onsiteretrieve ?

By the way: when the command  move drm * wherestate=mountable tostate=vault
remove=bulk  was initiated, 17 of those 20  mountable  volumes became
 vaultretrieve  (effectively  scratch ) immediately.

Thanks for any help!

With kind regards,

Alex

_________________________________________________________________
Talk with your online friends with MSN Messenger http://messenger.msn.nl/

<Prev in Thread] Current Thread [Next in Thread>