>> On Wed, 15 Mar 2006 14:16:43 -0500, Richard Rhodes <rrhodes AT 
>> FIRSTENERGYCORP DOT COM> said:

> We have a complicating problem - several disk pools using migration delay.
> We do this
> for several applications that use TSM to archive data (deleting it from
> within the application).  We
> hold this data in a disk pool for fast restores, migrating it to tape after
> about a year.
>  We accomplish this by using a 1 yr migration delay to make the disk pool
> into a queue fifo queue.

> Any thoughts on how to migrate this kind of disk pool to a new system?  If
> we follow the cook book,
> we delete the pool.... but this also deletes the queued data and I know of
> no way to repopulate
> the new disk pool that will retain with the most recent data sent to TSM
> from these applications.

> I'm thinking of something like this . . .

> ( . . . . they are on raw volumes right now . . . )

> 1)  migrate these disk pools to disk pool that is on a filesystem.
> 2)  just copy the files to the new server


Suggestion:

Define a new copy pool.  copy -only- the disk pool to it.  That way
you take care of the years' backlog of data at your leisure.

On the occasion of your migration:

+ Disable sessions
+ backup the stgpool again, to catch any new data since last regular
  backup.
+ Migrate as previously planned, blowing away the disk stgpool.
+ Restore the disk stgpool in the new location.


If you make the copystgpool on FILE devclasses, you can even serve
requests for the data while the recovery is happening, with not much
user-visible delay.


- Allen S. Rout