ADSM-L

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

2007-07-11 10:35:49
Subject: Re: [ADSM-L] Migration of a Copy storage pool impossible? or is it a feature request?
From: Kelly Lipp <lipp AT STORSERVER DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 11 Jul 2007 08:34:18 -0600
Do you keep all of your Copy Pool tapes in the library?  If so, why not
move data?  Email me off line about how our STORServer Manager product
can help out here.

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.

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

I like option two.  If you don't need the old tapes, use this approach. 


Kelly J. Lipp
VP Manufacturing & CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777
lipp AT storserver DOT com

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Rhodes
Sent: Wednesday, July 11, 2007 6:41 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Migration of a Copy storage pool impossible? or is
it a feature request?

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/11/2007
02:39:52 AM:
> version 5.4.0.3 it is not possible to have a NEXTSTORAGEPOOL on a copy
pool
> to migrate data from stage 1 DISK to stage 2 on TAPE, it is also not 
> possible to make a script to use move data command to move data from
stage
> 1 to stage 2 when move data command is not valid.
>

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.

Any ideas on a better way to accomplish this would be appreciated!!!

It seems to me there should be a feature that allows:
1) copy a copy pool
2) A migration hierarchy on copy pools just like primary pools
3) allow a pool to span libraries

I like #3.  I've never quite understood the limitation of a pool having
to reside within a library.  I've used several other
backup packages that allowed this.   I found it a very useful
feature.

Rick



-----------------------------------------
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.