Re: [ADSM-L] migrating tape storage pools
2012-08-09 12:12:12
Hi Kurt,
My advice should be going on using backup stg and reclaim stg instead of move
data. Just use scratch volumes LTO generation y and do not checkin LTO
generation x back from the vault. You'll still may have to use move data for
offsite volumes with a low reclaim percentage.
Time after time, you'll may be able to lower the reclaim percentage
Note that you can easily estimate the number of tape by counting the tapes
witch have a determined reclaim_pct. You can also control the period and
duration of the reclaim process.
Hope this help.
Regards,
Erwann
----- Mail original -----
De: "BEYERS Kurt" <Kurt.BEYERS AT VRT DOT BE>
À: ADSM-L AT VM.MARIST DOT EDU
Envoyé: Jeudi 9 Août 2012 10:09:15
Objet: [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
|
|
|