Moving data between copy pools

[purdym]

Yesterday I upgraded my library from LTO1 tape drives to LTO3 tape drives. I renamed all my (primary and copy) tape storage pools to their name plus .old. I have an offsite, DRM managed copy pool called OFFSITE.old (now). I made a new copy pool (DRM managed), called OFFSITE.



So OFFSITE.old is LTO1, OFFSITE is LTO3.



How can I move the data from OFFSITE.old to OFFSITE?



move data doesn't work. I can't set a reclaim storage pool for a copy pool. I can't even reclaim OFFSITE.old - since the LTO3 drives can't write to the GEN1 tapes.



Thanks Miles





>q stg offsite.old f=d



Storage Pool Name: OFFSITE.OLD

Storage Pool Type: Copy

Device Class Name: 3580

Estimated Capacity (MB): 97 149 G

Pct Util: 8.4

Pct Migr:

Pct Logical: 99.9

High Mig Pct:

Low Mig Pct:

Migration Delay:

Migration Continue:

Migration Processes:

Next Storage Pool:

Reclaim Storage Pool:

Maximum Size Threshold:

Access: Read-Only

Description: Offsite Copy Storage Pool

Overflow Location:

Cache Migrated Files?:

Collocate?: No

Reclamation Threshold: 98

Maximum Scratch Volumes Allowed: 500

Delay Period for Volume Reuse: 1 Day(s)

Migration in Progress?:

Amount Migrated (MB):

Elapsed Migration Time (seconds):

Reclamation in Progress?: No

Volume Being Migrated/Reclaimed:

Last Update by (administrator): PURDYM

Last Update Date/Time: 01/21/07 12:25:21

Storage Pool Data Format: Native

Copy Storage Pool(s):

Continue Copy on Error?:

CRC Data: No



q stg offsite f=d



Storage Pool Name: OFFSITE

Storage Pool Type: Copy

Device Class Name: UL3

Estimated Capacity (MB): 76 294 G

Pct Util: 0.2

Pct Migr:

Pct Logical: 100.0

High Mig Pct:

Low Mig Pct:

Migration Delay:

Migration Continue:

Migration Processes:

Next Storage Pool:

Reclaim Storage Pool:

Maximum Size Threshold:

Access: Read/Write

Description:

Overflow Location:

Cache Migrated Files?:

Collocate?: No

Reclamation Threshold: 100

Maximum Scratch Volumes Allowed: 100

Delay Period for Volume Reuse: 1 Day(s)

Migration in Progress?:

Amount Migrated (MB):

Elapsed Migration Time (seconds):

Reclamation in Progress?: No

Volume Being Migrated/Reclaimed:

Last Update by (administrator): PURDYM

Last Update Date/Time: 01/21/07 16:00:10

Storage Pool Data Format: Native

Copy Storage Pool(s):

Continue Copy on Error?:

CRC Data: No

 

[may]

kiet long but you can use the migration process,



affect the new offsite pool as "Next Stg Pool" on Offsite.old

 

[purdym]

No. There is no NEXTstgpool option for a copypool.

Miles

 

[dhcolesj]

You'll have to backup your new primary pools to the new copy pools, and then delete the volumes from the old LTO1 copy pools. I don't know of any other "good" way to do it. However, considering you are going to be using new LTO3 volumes anyway, and you should have a decent volume reuse delay setup, deleting the old LTO1 volumes one by one will not hurt (or shouldn't).



Anyone with better info is welcome to correct me, but this is the plan I had in place for our LTO1 to LTO3 migration.

 

[purdym]

Thanks. I guess they are copy pools - all of the data exists in the primary tape pools. I will backup the .old primary tape pools as well as the "new" primary tape pools to my "new" copy pools (ONSITE and OFFSITE).



I have an onsite copy pool and an offsite copy pool. The offsite is managed with DRM. Do you have an offsite pool managed with DRM? And how did you handle this? Can I remove volumes that have a DRM status of vault?



FYI:

>q stg



<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Code:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><PRE> >q stg



Storage Device Estimated Pct Pct High Low Next Stora-

Pool Name Class Name Capacity Util Migr Mig Mig ge Pool

(MB) Pct Pct

----------- ---------- ---------- ----- ----- ---- --- -----------

ARCHIVE UL3 76 294 G 0.0 1.0 100 70

ARCHIVE.OLD 3580 21 563 G 12.7 43.0 100 20 ARCHIVE

BACKUP UL3 76 294 G 0.0 2.0 100 70

BACKUP.OLD 3580 18 143 G 8.0 44.0 100 70 BACKUP

BACKUP_FC UL3 76 294 G 0.2 1.0 100 70

DATABASE UL3 76 294 G 0.2 1.0 100 70

DATABASE.O- 3580 11 326 G 32.1 38.0 100 0 DATABASE

LD

DIRMCSTGPO- DISK 2 G 10.9 0.0 95 70 BACKUP

OL

DISKDATA DISK 200 G 99.9 1.0 90 0 BACKUP

DISKDATA_A- DISK 8 G 97.5 0.0 50 0 ARCHIVE

RCHIVE

DISKDATA_D- DISK 475 G 99.8 0.1 50 0 DATABASE

ATABASE

DISKDATA_FC DISK 50 G 98.2 0.0 50 0 BACKUP_FC

DISKDATA_S- DISK 8 G 70.2 0.1 50 0 BACKUP

MALL

OFFSITE UL3 76 294 G 0.4

OFFSITE.OLD 3580 97 149 G 8.2

ONSITE_BAC- UL3 0.0 0.0

KUP

ONSITE_BAC- 3580 20 663 G 38.0

KUP.OLD

</PRE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>

 

[dhcolesj]

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>Thanks. I guess they are copy pools - all of the data exists in the primary tape pools. I will backup the .old primary tape pools as well as the "new" primary tape pools to my "new" copy pools (ONSITE and OFFSITE).



I have an onsite copy pool and an offsite copy pool. The offsite is managed with DRM. Do you have an offsite pool managed with DRM? And how did you handle this? Can I remove volumes that have a DRM status of vault?</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



Exactly, You can backup the data before you migrate it over to the LTO3 storage pools or after. I'm going to migrate the data over to the new LTO3 on-site storage pools first, and then backup the data to new copy storage pools later. This will first free up space in the 3584 for new LTO3 tapes, and second allow me to perform a backup from faster LTO3 tapes at a more leisurely pace.



We do use DRM to manage our offsite rotations. Once you have the data backed up to the new offsite copy pools, you can just delete all the volumes with a state of vault, and they will go to pending. They will then go to vault retrieve once the reuse delay setting has expired, at which time you can call them back from offsite and discard them accordingly.



I wouldn't get in a hurry with the off-site data as that's your recovery storage, and its not taking up space in your on-site library. I would get rid of all the LTO1 tapes in your onsite pools first, and get happy with the LTO3's.

 

[brwolfe]

I am going through the same migration now with TSM 5.2.9 running on solaris, I have 4 STK 9840 drives and 4 new LTO3 IBM 3580 drives in a 3584 library, all connected at the same time.

Unless some one has a better plan, I am going to:

Switch daily backups over to the new media.

Run copy pools on the daily data that comes into the new LTO primary pool.

Perform daily "move data volSTKxxx stg=new_LTO_stg_pool on all old STK tapes.



Eventually all the old STK primary pool will be in the new LTO primary pool and the copy LTO pool will take care of itself.

When all data is copied, I can delete the old STK copy pool what-ever is left of it.





Brian