TSM and your SLA's

[mosiac]

We're running TSM currently and we're reviewing all of our policies with it and I'd like compare some other user's SLA's based off node's and storage etc. I know everyone is going to be different for different reasons so I'm just trying to get an idea of how wide a variety of different ways people do it compared to our current situation that may or may not be optimal and where I could look to change things.

Currently we backup around 15ish terabytes of data across physical and virtual servers that goes to our main diskpool its all in the same domain of 30 days 3 versions. (I'm considering bumping to 5 or 7 versions to cover a full week of different changes per nightly incrementals.

We currently run 3 types of different backupset jobs spanned across the week starting on Wednesday nights thru to Monday night. The different types are 1 year, 10 year and infinitive sets. This is an old standard that was started by the previous admin and it's the first thing we are really looking to change because it isn't cost effective since we're doing it all to LTO tapes (4's and 5's). The 1 year set is the majority of our server nodes both linux and windows, the 10 year set is a subset just for our main database (full node backup not just the db) and the infinitve set is our file server due to some requests from certain users. (I really think this might need to be moved more to an archive instead of a backupset).


So what does everyone else do?

 

[moon-buddy]

Nothing that you do is different for most setups.

All have short and long term retention requirements. The question now is: do you want to do backups or archives for anything longer than 1 year?

The latter is preferred.

Version numbers (also retention) is an Operational and Business issue that you need to get a nod for. Not your decision.

Also, how many nodes are you backing up? If it is a mixture of platforms, I question the logic of just having 1 domain. This is a performance concern rather than a policy or operational issue.

 

[mosiac]

Why would you have different domains for different platforms, if the standard retention is the same no matter the platform?

 

[moon-buddy]

Reason: Data isolation, collocation, flexibility, and DR.

I have been using a single Domain for a long time until I started doing serious tuning and optimization. This also allowed me to just recover a particular domain without bring up the whole package.

Also, if need be, I can easily change retention.

By the way, by using multiple domains, I also use multiple storage pools - that is where the flexibility comes in.

 

[Paradox667]

I second moon-buddy here on multiple domains.
We've had a single domain for as long as TSM has been in place and I'm now in the process of breaking it out to multiple domains / multiple storage pools for exactly the reasons that moon-buddy highlighted.

The key is granularity in configuration and reporting (eg: detailed breakdown to management).

As for SLA we don't have any hard and fast (unfortunately) and generally default to a 'keep everything approach'.
That said for the majority of things we use the standard:
7 versions
1 version data deleted
31 extra versions
90 retain only version.

We are in the process of getting some hard and fast rules for how data should be retained / archived but it's a slow process.

 

[mosiac]

Thanks for all the input guys. We scoured other universities for their retention polices when they used tivoli and we were actually doing way more than many other schools, so we've started looking at where we can quickly dial back to cut some costs and some things we can change for better SLA's over all.