Tab, I was thinking that archived files would have to be moved also and deleted.
If you only delete the backups then import will rename the filespaces as it
imports them; //bignode/c$ will be imported as //bignode/c$.1.
(at least that is what I remember from a long time ago, you should test it with
something small).

The rename will make the imports useless as far as the next incremental backup
is concerned, unless you can rename the old filespace with the archives and then
rename the imported filespaces to the correct names.

Considering that you don't want to move 1.2T of archives, and I completely
understand this, my suggestion won't fly.   And considering the relative size
of the backups to the archives, why don't you just reconfigure and force an
absolute backup of bignode?

Bill


In <OF092C9137.A1E08F16-ON86256AF7.00769E0C AT laitram DOT com>, on 11/01/01
   at 04:53 PM, Tab Trepagnier <Tab.Trepagnier AT LAITRAM DOT COM> said:

>Bill,

>Thanks for your suggestions.

>There are two considerations that would make me hesitant to follow your
>shorter procedure:
>- I would prefer to not change domains since in our case that domain is
>used to delegate administrative client monitoring.  It could be done but
>would add a small amount of complication to the delegatees.
>- By "delete the filespaces" are you including the archive data?  That node
>has 1.2 TB of archived data that I want to neither delete nor move.

>Thanks again.

>Tab





>Bill Colwell <bcolwell AT DRAPER DOT COM>@VM.MARIST.EDU> on 11/01/2001 
>03:10:56 PM

>Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

>Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


>To:   ADSM-L AT VM.MARIST DOT EDU
>cc:
>Subject:  Re: Move a node's data from pool to pool (long message)


>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
>C. S. Draper Lab
>Cambridge, Ma.
>bcolwell AT draper DOT com
>--------------------------


>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

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
=========================================================================