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
