Quantcast
Channel: ADSM.ORG
Viewing all articles
Browse latest Browse all 2470

TSM as single point of failure in productive environments - transactional logging

$
0
0
Hey guys,

I'd really like some input on this and how you do this. Now what I have here seems like a pretty standard thing - we have our Hyper-V environment on a SAN storage hosting our productive services. Also we have a TSM server with storage, a tape library and so on. So naturally, we save the data from our productive clients to said TSM server. That includes database backups. Since we need to be able to to up-to-the-minute and point-in-time restores we naturally use log archival and this have the various TDP products backup the database logs.

Now consider this - the TSM server horribly fails, of course this happens when nobody is around and thus nobody can act for a few days (holiday season, whatever). What will happen is that the logs cannot be backed up and will pile up on the database servers disks - until the disks are full and the databases come to a grinding halt.

What is a practical way not to have this happen?

Of course, one way would be to make the TMS Server itself highly available. Which however means that no server can directly be attached to a tape drive anymore, we would have to have a library server. And I'm not sure of the performance we can expect from this. And of course this requires a significant investment, since we either need to expand our SAN to have the backup data stored on it or need another SAN just for the TSM servers. Ay!

I was really hoping for TSM "two-way-replication". As in there are Servers A and B and A replicates node data to B. When A fails nodes can restore AND backup to B and when A comes back B will replicate the differences to A. This would (to me) be an ideal solution but no, TSM can't do it.


How have you guys set this up?

Viewing all articles
Browse latest Browse all 2470

Trending Articles