>> On Wed, 11 Jul 2007 08:40:48 -0400, Richard Rhodes <[EMAIL PROTECTED]> said:
> While not what you are trying to do, next year I'm going to have a > similar copy pool issue. Next year we plan to replace our old 3494 > libs (3590 drives) by expanding our new 3584 libs (3592 drives). > The 3494 libs have our copy pools. The ONLY way I can come up with > to get the copy pools into the 3584 libs is to create new copy > pools. I'm estimating that recreating the copy pools will take up > to 4 weeks. This will put tremendous stress on the primary pool as > it does it's normal processing, keeping the old copy pool up to date > during the change, and creating the new copy pool. You can build the "new" copy pool gradually over time: there's no reason to rush it. 4 weeks, 4 months... :) > Any ideas on a better way to accomplish this would be appreciated!!! Virtual volumes. The primary ( I call it 'client-facing' ) server knows its' copy stgpools as SERVER volumes; the copy server can move its' data from one tape tech to another completely independantly. Virtual volumes are also the answer for staging copy data to disk, with a write to tape at a later point. - Allen S. Rout
