Tip: Data in storage pools that have an NDMP format (NETAPPDUMP,
CELERRADUMP, or NDMPDUMP) cannot be migrated. However, in primary
storage pools that have an NDMP format, you can make space available by using
the MOVE DATA command. The target storage pool must have the same data
format as the source storage pool.
Met vriendelijke groet,
Theo Brettschneider
+31 (0)6 29 02 13 53
-----Oorspronkelijk bericht-----
Van: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Namens
Chavdar Cholev
Verzonden: dinsdag 14 augustus 2012 14:26
Aan: ADSM-L AT VM.MARIST DOT EDU
Onderwerp: Re: [ADSM-L] migrating tape storage pools
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.
|
