Just one point of note.

upd stgpool <stgpoolname> acc=unavailable

      Specifies that **client nodes** cannot access files stored on
volumes
      in the storage pool.
     ** Server processes can move files within the volumes in the
storage
      pool and can also move or copy files from this storage pool to
      another storage pool. However, no new writes are permitted to
      volumes in the storage pool from volumes outside the storage
pool.**

In a DR, may not strictly be what you want.

update vol  *  wherestgpool=primarytapepoolname access=unavailable

Specifies that **neither client nodes nor server** processes can
 access files stored on the volume.


Leigh








"-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Large, M (Matthew)
Sent: 09 August 2006 16:01
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] restore directly from copy pool tapes

Wanda wrote:

Look at the parms for the "update vol" command - All you have to do is
enter "update vol  *  wherestgpool=primarytapepoolname
access=unavailable"
(or DESTROYED)
"update vol  *  wherestgpool=copypoolname access=readonly"



I find it much easier to just update the storage pool

Tsm:> upd stgpool <stgpoolname> acc=reado

Just a thought..

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Prather, Wanda
Sent: 09 August 2006 15:55
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] restore directly from copy pool tapes

Easy as pie.

When you restore the TSM data base, it wil show that your primary tape
pool tapes are still "readwrite", and your offsite tapes are "offsite".
But, your primary pool tapes are actually burned up, and your copypool
tapes have presumably been retrieved from your vault and are now at your
recovery site.

Look at the parms for the "update vol" command - All you have to do is
enter "update vol  *  wherestgpool=primarytapepoolname
access=unavailable"
(or DESTROYED)
"update vol  *  wherestgpool=copypoolname access=readonly"

Now check your copypool tapes into your library (if you have one at your
recovery site), status=PRIVATE.

When you start a restore on one of your clients, TSM checks to see what
tape is needed.  When it sees the primarypool tape is marked
UNAVAILABLE, it will automatically switch over and mount the copypool
tape instead.

The gotcha:

At your offsite location, your tape drives may not have the same
/dev/rmtx names they did at your primary location.  BUT, when you reload
your TSM data base, the drive & path definitions get reloaded as well.
So you may have a bit of patching to do before you can start your
restores.


Wanda Prather
"I/O, I/O, It's all about I/O"  -(me)





-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Hammersley
Sent: Wednesday, August 09, 2006 10:40 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: restore directly from copy pool tapes

I'm working on a disaster recovery scenario where our TSM server (AIX)
and tape library (3584)that has 90 LTO tapes in tape pools is destroyed
and several other servers are destroyed.  We have approx. 85 copy pool
tapes off site.

Our thought is to recreate the TSM server via mksysb, restore the TSM
database, etc.  Then get several of our critical other systems up and
restore their data by using the copy pool tapes and then recreate the
tapes in the tape pools in the tape library.

How does one set up the recreated TSM server so that it does not think
that the tape pool tapes are in the tape library ?

How does one restore from copy pool tapes ?

Are we going about this in a realistic way ?

Thank you.

Richard
_____________________________________________________________

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.
_____________________________________________________________