Hi
This is more a "heads up" than asking for a solution, as IBM has extensively looked into my problem and replied that "everything works as designed and expected." ( See the whole reply below)
Background:
We have disk based/file pools for most of our backups that are duplicated.
Then we have copies of these made to LTO4 tape and sent offsite daily.
The problem:
Space reclamation of the offsite copy pool is VERY slow. (Tape-to-tape reclamations are quick)
In a 5 hour period around 60-90Gb of data is reclaimed.
The reclamation threshold used to be set to 70% and would finish in the 5 hour reclamation window we had.
Now only tapes with a 95% reclamation threshold finish in that window.
This has off course wrecked havoc with the tapes cycles.
We had to almost double the amount of tapes in the offsite copy pool in order to have enough vault retrieves coming back to be used for the next cycle of copies.
Below is IBM's response after weeks of troubleshooting:
the development team review all serverperformance traces we gathered in May. Run tests on their machines and review the offsite
reclamation code.
From TSM development point of view, there is nothing else they can do as no defect was found and everything works as designed and
expected.
This is more a "heads up" than asking for a solution, as IBM has extensively looked into my problem and replied that "everything works as designed and expected." ( See the whole reply below)
Background:
We have disk based/file pools for most of our backups that are duplicated.
Then we have copies of these made to LTO4 tape and sent offsite daily.
The problem:
Space reclamation of the offsite copy pool is VERY slow. (Tape-to-tape reclamations are quick)
In a 5 hour period around 60-90Gb of data is reclaimed.
The reclamation threshold used to be set to 70% and would finish in the 5 hour reclamation window we had.
Now only tapes with a 95% reclamation threshold finish in that window.
This has off course wrecked havoc with the tapes cycles.
We had to almost double the amount of tapes in the offsite copy pool in order to have enough vault retrieves coming back to be used for the next cycle of copies.
Below is IBM's response after weeks of troubleshooting:
the development team review all serverperformance traces we gathered in May. Run tests on their machines and review the offsite
reclamation code.
From TSM development point of view, there is nothing else they can do as no defect was found and everything works as designed and
expected.