ADSM-L

Re: Problems with moving tapes OFFSITE

2002-07-19 02:16:55
Subject: Re: Problems with moving tapes OFFSITE
From: Gordon Woodward <gordon.woodward AT DB DOT COM>
Date: Fri, 19 Jul 2002 16:15:08 +1000
Thanks for the reply Mark, read below to answer some of your questions:

You have several different issues here to deal with.  First and foremost
are you licensed to use DRM, it is a separate purchasable product.  If
you are then I highly recommend that you configure it and use it to its
fullest.

[Gordon] We do have DRM installed are are licensed for it. Currently we have 
configured our TSM server at our HO to backup it's database to our secondary 
TSM server kept at our DR site via a 100Mb Ethernet link. This has been working 
fine and allows us to do a bare-metal restore of our main TSM server in a DR 
situation. As for whether it is configured to it's fullest, we believe it is as 
it was setup by some consultants we got in to setup our TSM environment.

Now as far as taking tapes offsite, TSM beleives the only tapes you will
be taking offsite is the tapes from your copypool, i.e. a second copy
(posibly third) of the data and of course your TSM DB's backups.  The
ANR2117E error you are getting is due to you trying to update volumes
that are in a primary storage pool.  I can only deduce from this that
you are definately not using DRM and further it seems that you are not
backing up your primary storage pools (using the ba stg Pri_pool
Copy_pool command).  It is the volumes from the copy pool that you would
then take offsite.  I recommend that you read thru chapter titled
"Protecting the Server" in the TSM Adminstrator's Guide this will give
you a good over view of how copy pools and offsite tape rotations work.
 Furthermore, if you are licensed for DRM then read the documents on
that as well.  I hate to be one of those guys that just says "RTFM"
(Read The Fine Manual) but this time I think it will really go a long
way to solving this problem.

[Gordon] Currently we have 3 backups running on our network: a daily 
incremental, a weekly incremental and a monthly archive. As each server is 
backed-up by each respective schedule, the data is temorarily stored on a Disk 
Storage Pool before being migrated onto tape. Ultimately we will have both the 
daily and weekly backups data being copied across to our DR TSM server for 
secondary storage. Our archive backups (the one causing us problems) are point 
in time snapshots and are purely kept on the tapes we have removed from the 
library, no copies of this data is kept within the library on any other tapes. 
I will re-read that chapter you mentioned and double check we are not making 
any glaring mistakes with our data protection scheme.

Now on the library full problem, it appears that the library inventory
and the TSM "q libv" are out of sync.  I have seen this happen for a
variety of reasons with several different libraries.  It usually stems
from the way tapes are physically and logically checked in and out of
the library.  However, since I am not real familiar with the Dell
library you are referencing I will make some general suggestions. See if
there is a library interface (separate from TSM) that allows you to
check the inventory that the library beleives it has and compare it to
the "q libv" output.  Please keep in mind TSM slot numbers and the
library slot numbers are often different, but usually only by some
offset.  I would then run an "audit library" check the sysntax on this
so that if you have a bar code reader that it uses the bar codes other
wise every tape will be mounted and the label read.  Then I would have
the library itself do an audit.  This is not a TSM command but rather a
library command of the hardware itself.  I am not sure how to do that on
your library but most library will do an inventory if you power cycle
it.  I understand that maybe lengthy and inconvenient so I would look
for a way to do it thru hardware control.  Once this is complete you can
then check the two inventories and they should be in sync.

[Gordon] I ran a TSM AUDIT LIBRARY process this afternoon which didn't do 
anything as no changes were reported. I checked the statistics of our library 
via it's firmware and it only recorded 58 tapes being stored within it, but 
have kicked off a hardware audit of it's columns now. I'll do another AUDIT 
LIBRARY when it is finished and see if anything changes,

Now the next step is keeping the library inventory and TSM's inventory
in sync.  Without DRM make sure you are using commands like "move media"
and "q media" for managing you tapes.  These are handy commands and they
can build macros for you that will assist you in checking the tapes in
and out of the library as well as doing some tracking of the tapes.  The
TSM Admin Guide has a pretty good section on "Managing Media in
Automated Library Devices".  If you do have DRM there will be a
different set of commands to use.

[Gordon] Basically it looks like we will have to rethink or change the way we 
are doing things. I'll recall our current archive tapes from offsite, reload 
them back into the library and try to check them out again properly because at 
the moment TSM doesn't let us do anything while the tapes are not physically 
available to the library.

Thanks again for the information.





--
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.
<Prev in Thread] Current Thread [Next in Thread>