ADSM-L

Re: [ADSM-L] Migration of a Copy storage pool impossible? or is it a feature request?

2007-07-11 11:24:36
Subject: Re: [ADSM-L] Migration of a Copy storage pool impossible? or is it a feature request?
From: Richard Rhodes <rrhodes AT FIRSTENERGYCORP DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 11 Jul 2007 11:24:53 -0400
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/11/2007
10:34:18 AM:
> Do you keep all of your Copy Pool tapes in the library?

Yes, the copy pool is offsite from the primary, but connected via
DWDM.  All tapes are within the libs - no manual tape movement.
So we have a onsite 3584/3592 and a offsite 3494/3590.

These are peer datacenters, so we then turn around and have
a mirror of the setup.

    site 1                                 site 2
3494/3590/pri_pools site1     ==>    3584/3592/copy_pools for site1
3584/3592/copy_pools site2    <==    3494/3590/pri_pools for site 2

The new environment will be:

    site 1                                             site 2
3584/3592/pri_pools_site1/copy_pools_site2   <==>
3584/3592/pri_pools_site2/copy_pools_site1


The 3494's and 3590 drives are being retired.  The replacement is the
expansion of the 3584 libs with 3592 drives.

I cannot simply move the tapes because they are of a different kind
and there are no 3590 drives in the 3584 lib.  In fact, I don't think
3590 drives will fit in a 3584 at all.

>
> Or why not simply start a new copy pool and leave the old one to expire
> (perhaps not completely, but enough to make the load on the primary pool
> reasonable).  The only issue with that plan would be very long retention
> periods on some data making the plan take too long.

Yes.  The only way I've come with to get copy pools in the 3584 libs is
to create NEW copy pools.  Keeping the old copy pools around isn't a
problem.  The major issues are having to keeping the old copy pool
up to date while the new copy pool is created.  It will take weeks
to create the new copy pool.  From what I figure, I can't simply stop
updating the old copy pool.  That would leave a unknown gap of
files not in a copy pool until the new copy pool is fully created and
up to date.

>
> The nice thing about the Move Data option is you can schedule it to
> occur and it will not impact Primary pools.
>

Yes.  That's how I moved the PRI data.  The PRI data used to be in the
3494 also.  It was moved by creating a new pri pool in the hierarchy,
pointing the disk pool to the new pri pool, then running
movedata cmds from old pri to new pri as tape drives
were avaiable.  During the night I had 4-6 movedata's
running concurrently.

Unfortunely, there is not the same level of control for
a "upd stg" cmd for a new copy pool.


-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.