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.