ADSM-L

TSM recovery failure

2006-09-11 06:30:06
Subject: TSM recovery failure
From: Oscar Kolsteren <Oscar.Kolsteren AT INGDIRECT.CO DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 11 Sep 2006 11:28:02 +0100
Hi all,

 

We did a test on our remote site to restore our primary TSM server on a
second DR server. On the DR site we've got two servers, one for normal
backups and the other for DR purposes. When TSM is restored we would
like to use the DR server to act as a library client to the first TSM
server.

 

Some details:

 

TSM version = 5.2.*

AIX = 5.3.*

 

Procedure:

 

-          Shutdown primary TSM server 

-          Restore TSM on DR server

-          Startup primary TSM server

-          Remove paths, library and drives from DR server

-          Configure library client on DR server

-          Put all tapes in library

-          Checkin tapes as private in primary TSM server

-          Audit library on DR server

 

Only two tapes are changing ownership to DR server instead of the 180
off-site tapes. The diff with the q vol command on the DR server is :

 

Tape which change ownership:

 

                   Volume Name: RG0166

             Storage Pool Name: CR_TAPEPOOL_COPY

             Device Class Name: ULTRIUM3

       Estimated Capacity (MB): 228,029.4

       Scaled Capacity Applied: 

                      Pct Util: 74.7

                 Volume Status: Full

                        Access: Read-Only

        Pct. Reclaimable Space: 25.6

               Scratch Volume?: Yes

               In Error State?: No

      Number of Writable Sides: 1

       Number of Times Mounted: 1

             Write Pass Number: 1

     Approx. Date Last Written: 08/11/2006 17:13:23

        Approx. Date Last Read: 08/11/2006 14:06:48

           Date Became Pending: 

        Number of Write Errors: 0

         Number of Read Errors: 0

               Volume Location: VAULT

Volume is MVS Lanfree Capable : No

Last Update by (administrator): ADMIN

         Last Update Date/Time: 09/09/2006 15:37:51

 

 

Example tape which isn't changing ownership:

 

                   Volume Name: RAR010

             Storage Pool Name: ARCHIVECOPY_1YEAR

             Device Class Name: ULTRIUM3

       Estimated Capacity (MB): 569,254.7

       Scaled Capacity Applied: 

                      Pct Util: 89.2

                 Volume Status: Full

                        Access: Read-Only

        Pct. Reclaimable Space: 10.8

               Scratch Volume?: No

               In Error State?: No

      Number of Writable Sides: 1

       Number of Times Mounted: 4

             Write Pass Number: 1

     Approx. Date Last Written: 08/08/2006 17:02:58

        Approx. Date Last Read: 06/20/2006 10:27:31

           Date Became Pending: 

        Number of Write Errors: 0

         Number of Read Errors: 0

               Volume Location: VAULT

Volume is MVS Lanfree Capable : No

Last Update by (administrator): ADMIN

         Last Update Date/Time: 09/09/2006 15:37:45

 

 

The only diff I can see is the output on the Scratch Volume question.

If I look in the Volume History file on the primary server this RAR010
tape has ownership of the DR server.

 

Why isn't this changing then ???

 

Any help is appreciated...

 

Best regards,

Oscar Kolsteren

 

UNIX / TSM Administrator | ING Direct
410 Thames Valley Park Drive, Reading, Berkshire, RG6 1RH
Tel: 0118 938 1990 l Email: Oscar.kolsteren AT ingdirect.co DOT uk
<mailto:[email protected] AT ingdirect.co DOT uk> 

 

 

-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>
  • TSM recovery failure, Oscar Kolsteren <=