Re: [ADSM-L] migrating tape storage pools
2012-08-10 12:27:08
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
|
|
|