Robin,

I am not sure your concern is valid.  Why wouldn't the destroyed tape or
for that matter even a single bad file on an otherwise good tape be
caught (and resolved either automatically or manually) during the move
data phase for the primary pool.  If there was a bad tape it would
report it and you could then restore the volume.  Or if it was a bad
file it would also report that if it could not immediately get it from
an on site copy pool.  In either case if you monitored the move data
process and the activity log you would be able to catch the problem and
resolve it long before you ever destroyed the copy pool version.

--
Regards,
Mark D. Rodriguez
President MDR Consulting, Inc.

===============================================================================
MDR Consulting
The very best in Technical Training and Consulting.
IBM Advanced Business Partner
SAIR Linux and GNU Authorized Center for Education
IBM Certified Advanced Technical Expert, CATE
AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux
Red Hat Certified Engineer, RHCE
===============================================================================



Robin Sharpe wrote:

Seems to me this process does not guarantee you have everything.

Hypothetical situation:

File A gets backed up from client to Pool A.
File A gets backed up to Copypool B.
FIle A becomes inactive.
Primary tape (in Pool A) gets destroyed, and does not get restored.  now
the only copy is in Copypool B.
THere is no way to recreate the primary copy (except restore volume....
will restore storage pool work?)
If you delete the volume from Copypool B, that version of FIle A is gone
forever.


Robin Sharpe
Berlex Labs


|---------+--------------------------->
|         |           "Miller, Ryan"  |
|         |           <Miller.Ryan@PRI|
|         |           NCIPAL.COM>     |
|         |           Sent by: "ADSM: |
|         |           Dist Stor       |
|         |           Manager"        |
|         |           <[email protected]|
|         |           T.EDU>          |
|         |                           |
|         |                           |
|         |           04/05/2005 11:55|
|         |           AM              |
|         |           Please respond  |
|         |           to "ADSM: Dist  |
|         |           Stor Manager"   |
|         |                           |
|---------+--------------------------->
 
>--------------------------------------------------------------------------------------------------------------------|
 |                                                                              
                                      |
 |                                                                              
                                      |
 |To:     ADSM-L AT VM.MARIST DOT EDU                                           
                                             |
 |cc:                                                                           
                                      |
 |Subject:                                                                      
                                      |
 |        Re: Changing copypools                                                
                                      |
 
>--------------------------------------------------------------------------------------------------------------------|



I don't know if there is a change in 5.3 as we have not upgraded yet, but I
just went through this process in November/December when we upgraded our
tape environment.  The only option was to backup data from the primary pool
to the new copypool, just like you stated.  The good/bad news(depends on
how you look at it) is...we had 500 TB of data to do this with and over
6000 tapes to delete.  I ended up building command scripts to delete the
volumes, much easier than hitting each on separately.  Also the data copied
much quicker than expected and we were done in 2 months...

Ryan Miller

Principal Financial Group

Tivoli Certified Consultant
Tivoli Storage Manager v4.1


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Zoltan Forray/AC/VCU
Sent: Tuesday, April 05, 2005 10:49 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Changing copypools


Richard.  Where do you find the time to remember all this !

A very interesting idea/process. Would work great for small amounts of
data !

Unfortunately,  I have 20TB to move/recopy !

Thanks for the pointer, though !




Richard Sims <rbs AT BU DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/05/2005 11:31 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: [ADSM-L] Changing copypools






On Apr 5, 2005, at 11:22 AM, Zoltan Forray/AC/VCU wrote:

Am I correct that there is still (even in V5.3) no method to move all
data
from one copypool to another ?

I have a need to move all copypool data from a 3590 pool to an LTO2
pool !

IIRC, unless things have changed, the only choice I have is to
re-backup
the primary pool to the new copypool and then manually "delete volume
...
discarddata=yes" for the 300+ volumes in the old copypool !

Please tell me there is an alternative !

A previously listed alternative:
  http://www.mail-archive.com/adsm-l AT vm.marist DOT edu/msg57424.html


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to Connect AT principal DOT com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.