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 <[email protected]> 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 > [email protected] > > Sent by: [email protected] > 08/09/2012 10:15 AM > Please respond to > [email protected] > > > 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 [[email protected]] namens > Huebner,Andy,FORT WORTH,IT [[email protected]] > Verzonden: donderdag 9 augustus 2012 16:00 > Aan: [email protected] > 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:[email protected]] On Behalf Of > BEYERS Kurt > Sent: Thursday, August 09, 2012 3:09 AM > To: [email protected] > 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.
