This document applies only to the following language version(s):
Procedure to migrate any Tivoli Storage Manager data that resides in Storage Pools from one library to another library. This procedure can be used to move data from any devclass to any other devclass.
Data needs to be migrated to alternate library hardware.
Resolving the problem
1) Physically attach the new library to the server and define it in the Tivoli Storage Manager server.
2) Once it is defined to the O/S and Tivoli Storage Manager, create a new stgpool (NEWPOOL) using the new library. See the Tivoli Storage Manager Admin guide / quick start guide for procedure.
DEFINE STG NEWPOOL
3) disable sessions & events so that backups will not go to old stgpool.
It depends on how much data you have and what daily processing is going on at the time, but it is recommended to mark the OLDPOOL volumes 'read only' at this point.
4) Change the copygroup DESTination setting from your OLDPOOL to point to NEWPOOL. If your backups go to a Disk stgpool and then migrate to OLDPOOL, update the disk stgpool to point to NEWPOOL as well, without changing copygroup setting.
If your copygroups go directly to tape, then change those now as well. Validate and Activate the policy sets after making the changes to the copy destinations.
5) Enable sessions & events.
Now new backups will go to new library. Next we will migrate the data off of the old library..
6) Update your old stgpool NEXTstgpool setting to go to the new stgpool.
UPDATE STG OLDPOOL NEXT=NEWPOOL
7) Create the new copy storage pool, if you use them.
DEFINE STG NEWCOPY
8) Do this next step in increments as a large amount of data will be transferred during each step. During the migration you probably want to continue with every day production and you do not want to fill up your database. Migration can be controlled through your Hi / Lo settings, for example:
UPDATE STG OLDPOOL HI=80 LOW=70
UPDATE STG OLDPOOL HI=70 LOW=60 (next day, and so on.)
Look at Q STG OLDPOOL to verify your setting so migration can occur if you are having trouble at this point.
After each migration increment, Bring the new copy pool up to date (if used.)
BACKUP STG NEWPOOL NEWCOPY
This will run a backup from the NEWPOOL to the NEWCOPY pool. When this step is complete, do the next incremental migration and another backup stgpool and so on until the entire storage pool is migrated.
A way to move the data over to the new storage pool with more control is to use the MOVE DATA command. See the ADMIN REFERENCE for the syntax and options for this command.
Notes: Regardless of the method used, the only way to move copypool data to the new devclass is by backing it up again with 'backup stg' specifying a copy stgpool in the new devclass. The data in the copy stgpool in the old devclass will need to be removed by 'delete volume ##### discarddata=yes'. It is recommended to do this after the data has been copied to the new copy stgpool.
9) Once the BACKUP STG is done, get rid of the old pool
for each volume in "Q VOL STG=OLDCOPY" do
DELETE VOL <name>
10) When done, delete the old copy stg pool.
DELETE STG OLDCOPY