May be migrate data to new LTO x1(primary) pool, and after that say
copy from LTO x1 primary toLTO y1 (new copy pool)

On Fri, Aug 10, 2012 at 8:21 PM, Shawn Drew
<shawn.drew AT americas.bnpparibas DOT com> wrote:
> Further, it will use the copy pool volumes if they are available and have
> an access of readw/reado.  If they are offsite, then it will use the
> primary volumes.
>
> Regards,
> Shawn
> ________________________________________________
> Shawn Drew
>
>
>
>
>
> Internet
> Kurt.BEYERS AT VRT DOT BE
>
> Sent by: ADSM-L AT VM.MARIST DOT EDU
> 08/09/2012 10:15 AM
> Please respond to
> ADSM-L AT VM.MARIST DOT EDU
>
>
> To
> ADSM-L
> cc
>
> Subject
> Re: [ADSM-L] migrating tape storage pools
>
>
>
>
>
>
> Hi Andy,
>
> A 'move data' on a copy stg pool volume works, the primary stg pool
> volume(s) is/are used for the operation. It just does not work for tapes
> that contain NDMP backups (primary or copy).
>
> regards,
> Kurt
> ________________________________________
> Van: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] namens
> Huebner,Andy,FORT WORTH,IT [Andy.Huebner AT ALCONLABS DOT COM]
> Verzonden: donderdag 9 augustus 2012 16:00
> Aan: ADSM-L AT VM.MARIST DOT EDU
> Onderwerp: Re: [ADSM-L] migrating tape storage pools
>
> You cannot use move data on a copy tape.  I have tried.
> I am very interested if you find a good solution.  We are moving some of
> our copies to a different drive type.
>
>
> Andy Huebner
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> BEYERS Kurt
> Sent: Thursday, August 09, 2012 3:09 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] migrating tape storage pools
>
> Good morning,
>
> We are in the process of migrating several tape storage pools, both
> primary and copy, from LTO generation x to LTO generation y.
>
> It is easy for primary storage pools, since the incremental backup
> mechanism is taking all the primary storage pools in scope:
>
> *         Redirect the backups to an LTO_Y storage pool
>
> *         Migrate in the background  the LTO_X storage pool to the LTO_Y
> with a duration of x minutes
>
> However  this does not work for copy storage pools since there is a valid
> reason why a backup would be kept in multiple copy storage pool volumes.
> But this implies that the copy storage pool from generation LTO_Y needs to
> be rebuild from scratch. Which is time consuming and expensive (more tape
> volumes, more slots,more offsite volumes ....). Are there really no other
> workarounds available?
>
> An option might be that given the fact we use dedicated device classes for
> each  sequential storage pool and that multiple libraries will be or are
> defined for each LTO generation:
>
>
> *         A DRM volume is linked to a copy storage pool
>
> *         The copy storage pool is linked to a device class
>
> *         Hence change the library in the device class from LTO_X to LTO_Y
> for the copy storage pool
>
> Would this workaround work? Then I could perform a daily move data in the
> background to get rid from the LTO_X copy storage pool volumes. Will test
> it myself of course.
>
> It would be great too if IBM  could consider introducing the concept of a
> 'copy storage pool group' consisting of multiple copy storage pools that
> contains only 1 backup of the item.  Perhaps I should raise an RFC for it
> if other TSM users find it also a good feature. So please provide me some
> feedback. Thanks in advance!
>
> Regards,
> Kurt
>
>
>
>
>
> *** Disclaimer ***
> Vlaamse Radio- en Televisieomroeporganisatie
> Auguste Reyerslaan 52, 1043 Brussel
>
> nv van publiek recht
> BTW BE 0244.142.664
> RPR Brussel
> http://www.vrt.be/gebruiksvoorwaarden
>
> This e-mail (including any attachments) is confidential and may be legally
> privileged. If you are not an intended recipient or an authorized
> representative of an intended recipient, you are prohibited from using,
> copying or distributing the information in this e-mail or its attachments.
> If you have received this e-mail in error, please notify the sender
> immediately by return e-mail and delete all copies of this message and any
> attachments.
>
> Thank you.
> *** Disclaimer ***
> Vlaamse Radio- en Televisieomroeporganisatie
> Auguste Reyerslaan 52, 1043 Brussel
>
> nv van publiek recht
> BTW BE 0244.142.664
> RPR Brussel
> http://www.vrt.be/gebruiksvoorwaarden
>
>
>
> This message and any attachments (the "message") is intended solely for
> the addressees and is confidential. If you receive this message in error,
> please delete it and immediately notify the sender. Any use not in accord
> with its purpose, any dissemination or disclosure, either whole or partial,
> is prohibited except formal approval. The internet can not guarantee the
> integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
> not therefore be liable for the message if modified. Please note that certain
> functions and services for BNP Paribas may be performed by BNP Paribas RCC, 
> Inc.