Tab, I think there IS a simpler way.

1. create a domain 'lto-domain' where all the destinations point to the ltopool.
2. lock bignode
3. update bignode to use the new domain.
4. export bignode
5. delete the filespaces of bignode
6. import bignode
7. configure a domain with a storage hierarchy of 'another-diskpool'
 migrates to ltopool.
8. update bignode to use the new domain and unlock.
9. Miller time!

During export tsm doesn't care about the storage path of future backups,
it just takes the files from where they are.  But during import it does follow
the storage path that was recorded during export by virtue of the domain setting
for the node at the time it was exported.

Hope this helps,

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <OFCEC85049.6FD91767-ON86256AF7.006E50EB AT laitram DOT com>, on 11/01/01
In <OFCEC85049.6FD91767-ON86256AF7.006E50EB AT laitram DOT com>, on 11/01/01
   at 04:10 PM, Tab Trepagnier <Tab.Trepagnier AT LAITRAM DOT COM> said:

>I need to move data from 3570 media in a 3575 to LTO media in a 3583.  I
>expected to be able to use export/import to do that since "move data by
>node" is promised in the future but is not here now.

>I have uncovered some wrinkles to the process which I will share below for
>comment.

>System:
>TSM 4.1.4.1 on AIX 4.3.3
>Primary pools on 3575 Magstar and 3583 LTO; copypool on DLT 8000.

>Assumptions:
>"Bignode" has 200 GB of backup data to be moved;
>"Bignode" has archive data in another library that will not be disturbed;
>Source tapes for "Bignode" are not collocated; but ultimate destination
>pool is;
>"Bignode" will remain in the same policy domain on the same TSM server;
>No data, including inactive versions, can be lost;
>I do not have enough free tapes in the source library to collocate in place
>prior to moving the data.

>What I've found when doing the import of the data is that since the node
>already exists, the IMPORT NODE command will send the imported data to the
>storage pool referenced in the default management class for the policy
>domain of which the node is a member.  In our case, that is a disk pool
>whose migration destination is the 3575, so in the absence of configuration
>changes, the data just makes a big circle.

>Since that disk pool is first stop for the data from about 60 nodes there
>can be accidental mixing of nodes' data while "Bignode's" data is making
>the loop.

>As a result of all that, this is what I think I will have to do to move
>"Bignode's" backup data to LTO.  I am interested in any comments or
>suggestions:

>1) Lock "bignode" to prevent new data from coming in.
>2) Export bignode's backup data from 3575 to DLT.  This will take time
>since the 3575 has to shuffle through about 60 tapes to extract all the
>data.
>3) When export is complete, take DB backup to snapshot system state.
>4) Set source tape pool to 100% reclaim threshold.
>5) Delete all backup data of bignode.
>6) Lock all nodes in bignode's policy domain.
>7) Update disk pool referenced in the default management class of bignode's
>policy domain to point to the LTO tape pool.
>8) Import bignode's backup data from DLT.  Data will go to default disk
>pool.
>9) Migrate all of bignode's data from disk pool to LTO tape pool.
>10) Ensure that bignode's TSM configuration points all new data to the LTO
>data path (there is an upstream disk pool).
>11) Unlock bignode and run a command line backup to verify proper
>configuration.
>12) Unlock all remaining nodes.
>13) Take another DB backup.
>14) Update source storage pool to reclaim at 50% and allow reclamation to
>run.

>That's a lot of work for one node, and I'll ultimately have to do that to
>about 12 of them.

>If anyone has a better idea I'm interested.  If not, then this is offered
>for anyone else with that need to relocate data by node.

>Thanks.

>Tab Trepagnier
>TSM administrator
>Laitram Corporation