Hi, Kurt.  The way you're doing it sounds fine to me.  In fact, it
sounds like the only real problem is offsite slots.  Are those very
expensive for you?

But this implies that the copy storage pool from generation LTO_Y needs to be 
rebuild from scratch.

Which is time consuming - Alex: Not really - it's incrementally building copy_y 
as data is moved from primary_x to primary_y.  This more-or-less approximates 
the kind of overhead involved in moving from data from copy_x to copy_y.

and expensive (more tape volumes, - Alex: Not really - you have already had to 
invest in lto_y volumes, and those empty (after moving from copy_x to copy_y) 
copy_x volumes would just be lying around taking up space until the migration 
is complete anyway.

more slots, - Alex: Not really - the copy_x volumes would be offsite, and so 
would most of the copy_y volumes, so they won't occupy many slots in the 
library.

more offsite volumes ....). - Alex:  this is the only real impact I see, and 
it's a temporary expense until you're done.  Also, the copy_y volumes shouldn't 
occupy as much additional offsite space as their storage density should be much 
higher.  How expensive is the additional space for a few hundred (I assume) 
lto_y carts for the duration of the migration?

Bonus: You can save time and effort when you stop reclamation on copy_x until 
primary_x is completely moved to primary_y and a final backup of primary_y to 
copy_y is complete.  Then you can bring back all copy_x volumes in one fell 
swoop without having to babysit them for months.

About your second thought, changing the library in the devclass, I think
it should work.  The Admin Guide has this to say about mixed media:
You can migrate to a new generation of a media type within the same
storage pool by following these steps:
1. ALL older drives are replaced with the newer generation drives within
the library (they cannot be mixed).
2. The existing volumes with the older formats are marked R/O if the new
drive cannot append those tapes in the old format. If the new drive can
write to the existing media in their old format, this is not necessary,
but Step 1 is still required. If it is necessary to keep both LTO1 and
LTO2 drives within the same library, separate storage pools for each
must be used.

Of course, this requires your lto_x to be within two generations of
lto_y so the new lto_y drives can read the lto_x volumes.

On 8/9/2012 1:09 AM, BEYERS Kurt wrote:

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