Calculate capacity saving with reduction in retention period...

[manofmilk]

Hi all,

We are looking to save some space in the TSM environment (to reduce cost and possibly enable investment in disk based de-dupe). Our current retention for the 'daily' BA client backups is:

Ver Ex: 28
Ver Del: 5
Ret Ex: 56
Ret On: 56

We run backups every night so essentially we keep between 1 and 2 months worth of file/folder data. With our current environment this equates to quite a lot of data (approx 95TB and growing as the environment grows).

What we want to know is - "Is there any way to calculate the amount of space that would be reclaimed if we reduced this retention category to X versions and X days?"

Thoughts and suggestions gratefully received, anything else you might need to know to assist us please just ask.

Cheers.

 

[JohanW]

Any way - sure.

Any practical way - no.

 

[manofmilk]

Long question, short answer

Any way - sure.

Any practical way - no.

Thats pretty much the conclusion we came to: we thought we could make a lot of assumtions and guesstimate or write a load of SQL queries that would still be running this time next year...
Really we were hoping somebody else would already have had the same thoughts and have some ready made queries or even a recomendation of a reporting tool that would contain this functionality (even if we had to let it run for 2 months to gather enough data).

Its a pain becasue being able to put a reliable figure on the saving would make justifying it much easier.

 

[Eldoraan]

If you have a test host you can play with, then restore the production DB to it and make a change to retention, expire inventory, and see what changes you get. Make sure test hosts can't access production tape library - or you'll hose a bunch of tapes! Remove DB and restore again, try another value on retention and repeat as needed to guage space gains at different retentions. It won't be exact, but should give a basic idea.

 

[manofmilk]

Ah-ha

If you have a test host you can play with, then restore the production DB to it and make a change to retention, expire inventory, and see what changes you get.

Now thats bloody obvious - why didn't you suggest that 3 days ago before we started thinking about this!! ;D

One question - will this work if we just change the settings and then run expiration? (I only ask because I belive that if, for example, you were to change server policy to send all .mp3s to a different management class then you would have to have the client run a backup to re-bind all the files to the new settings, files currently in the system are not automatically rebound. Does this apply here or will the new settings just take effect?).

 

[Eldoraan]

If you're changing management class names/bindings, then yes - you'd need the client to do a complete incremental to get binding updated. Simply changing the retention on existing management classes and running expiration will apply the new values to that existing data. So client won't be needed.

Oh, and as for 3 day delay... you didn't ask until today! ;-)

 

[Jeff_Jeske]

Unless all your servers have the same type of data there's still no easy way to calculate. File servers with millions of small documents should expire at a different rate than database or exchange servers.

The real question is what are your legal requirements for retention. What do your business clients really need? The answer to that has to come from the business or legal expert. You can't just blindly set retention periods. That being said it was next to impossible to get a straight answer from our experts.

Technically daily backups should be used for disaster recovery and not data archiving. Having holding 56 days worth of ALL data a bit overkill. This is especially true for SQL and Exchange databases. Understanding the data is big part of data protection.

Know we all know there are users out there that want to ask for data they knowingly deleted 6 months ago. We also know that asking from something from a week ago isn't too far fetched. There has to be a happy medium that can only be reached by holding users accountable.

We have stated that its the data owners responsibility to protect their data within their application. See below:

With regard to distributed systems and servers, IT Infrastructure does not control the retention policy or rules over business data. IT Infrastructure performs routine, daily backups, which contain copies of data that may be used to restore the original data asset in the event that it is lost or damaged beyond repair. This differs from archiving, which refers to the collection of historical records specifically selected and cataloged for long term retention for future reference. Consequently, from an IT backup perspective, data assets will still be present and available as long as those with write access to the information do not delete the original. If that deletion occurs, the owner has ** days to request that the data asset be restored.

Distributed systems and servers, file retention is at the discretion of the information owner of the data asset in question. Data files are retained indefinitely unless they are deleted or become damaged. When situations occur in which the data is deleted by mistake, the data can be restored within a ** day window of when it was removed by notifying the Support Center. Any requests, to handle backup and recovery differently than the standard, would need the review and approval of IT Infrastructure Management.

We operate with a handful of management classes....
16/42/16/42 for web, app, and file type servers.
7/7/7/7 for exchange
10/10/10/10 for database servers
42/42/42/42 - special request
1/42/1/42 - monthly image backups of file servers