ADSM-L

Re: Hey Big Blue....Why not MOVE DATA across copy pools?!?

2004-06-09 15:30:05
Subject: Re: Hey Big Blue....Why not MOVE DATA across copy pools?!?
From: Jurjen Oskam <jurjen-tsm AT STUPENDOUS DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 9 Jun 2004 21:29:55 +0200
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