Either way works, the way you have coupled the TSM servers in production can differ from the way you use them in DR. If you care about recovery speed and have a hot site, you can setup a dedicated library manager instance on that site and recover the library clients in parallel. I have used this to recover more than 2 TSM instances at once.
The library manager is just a small TSM instance that only does one thing - being library manager. You checkin the tapes (on the library manager) and start the DB restores on the library clients. Because path definitions are stored on the library manager, the only thing defined on the library client is the shared library pointing to the lib mgr. If you have a library manager that needs to be restored first, your second (and third, fourth etc) instance has to wait until the lib mgr has been restored. If RTO matters, setting up a pre-prepared library manager helps. 2014-08-25 22:06 GMT+02:00 Matthew McGeary <[email protected]>: > Hello all, > > We're in the process of setting up a second TSM server at our head office > to split the backup load. Primary storage is disk, so that's no problem > but we offsite to LTO4 tape. > > My original thought was that we'd set up library sharing using either the > current TSM server as the manager or a new TSM server instance that is > solely responsible for library operations. I'm leaning towards a new, > library-manager-only TSM server, with two TSM library clients. > > Where I'm unclear is how DR works with a shared library manager. Do we go > through the process of restoring the TSM library manager instance first, > then the two (or more) library clients? Or (if we have two libraries > available at our DR site) can I restore the two library clients > independently, each attached to their own library? > > Thanks! > > Matthew McGeary > Technical Specialist > PotashCorp - Saskatoon > 306.933.8921 > -- Kind Regards, Groetje, Marcel Anthonijsz T: +31(0)299-776768 M:+31(0)6-53421341
