Tim,

        I tried a MOVE DATA for offsite data...it did not go after the
data in the primary pool...it wanted to mount the volume in the copy
pool...which was offsite.
        Am I missing something?

Dave Nicholson
Whirlpool Corporation





"Rushforth, Tim" <TRushforth AT WINNIPEG DOT CA>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/09/2004 03:43 PM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Hey Big Blue....Why not MOVE DATA across copy 
pools?!?


Yeah you would think this is easy unless I'm missing something ...

MOVE DATA "works properly" for offsite data - ie if you issue a move data
for a volume that is offsite, it will move the data to another volume in
the
same copy pool using the primary storage pool as input.

Why does MOVE NODEDATA work differently?  It is doing the same thing -
only
selectively moving data.

-----Original Message-----
From: Jurjen Oskam [mailto:jurjen-tsm AT STUPENDOUS DOT ORG]
Sent: June 9, 2004 2:30 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Hey Big Blue....Why not MOVE DATA across copy pools?!?

On Wed, Jun 09, 2004 at 12:10:32PM -0500, Stapleton, Mark wrote:

> I used to think the same thing, but it occurred to me that, while there
> is a one-to-one correspondence between a file in an copy pool and the
> copy of the file in a primary pool, there is not necessarily a
> one-to-one relationship in the other direction.

Especially with MOVE NODEDATA used to move data from one primary pool to
another, where the first primary pool is backed up to COPY01 and the
second primary pool is backed up to COPY02. The data in COPY01 is now
(sort of) 'orphaned', and cannot be removed. (Not easily, at least)

Maybe a DELETE NODEDATA would be nice. (However, a MOVE NODEDATA that
would work on offsite volumes would be *much* nicer. That way, you can
once in a while 'collocate' all files of a node manually, and greatly
speed up a DR when all you got is the copypool.)

> The more I look into this, the more I am inclined to never use more than
> one copy pool for any given TSM server.

Especially so with a MOVE NODEDATA that would work on offsite volumes.

--
Jurjen Oskam

"Avoid putting a paging file on a fault-tolerant drive, such as a mirrored
volume or a RAID-5 volume. Paging files do not need fault-tolerance."-MS
Q308417