Remarkably, as we work with clients we discover that they rarely analyze the component costs of their operations. So let me make this easy: the bulk of the money is in whatever you do for data protection. But even if you know this, have you looked at the details of what you’re protecting and how it flows through you systems? What components make up the bits you write? How often do you write them and why?

Last year we worked with a client who had done this analysis. They discovered that 40% of what they were writing each day was user PST files in home directories, independent of server backups. (This is a financial institution whose corporate policy requires the preservation of email. Each user needs and wants their own record.)

Outlook, as you may know, has the annoying feature of updating your PST file each time you open it whether you have changed its contents or not. This means that if you do daily incremental backups every PST file for every user is written every day. And, if you’re keeping most or all of your emails, and you have lots of users, this is lots of data. Can this be made less burdensome and less expensive?

We worked with the client to set a system-enforced limit on the size of an individual PST file. This means that each user now has a series of smaller files. Outlook only attaches and updates the current PST file; the others are left as they are. Enterprise-wide, this eliminated 100 tapes from a year’s worth of incrementals. 3M is commonly cited as stating that the cost of maintaining writing and maintaining one tape in a typical backup scenario is about $3,500 a year. One hundred tapes times $3,500 is a lot of money – a third of a million dollars a year. For the sake of argument, let’s assume that your operations are less expensive – only $1,500 per tape per year. This is still $150,000 a year.

We would all agree that every user’s archival mail is something we have to protect. But, maybe it’s worth drilling deeper into how you do it…

Wednesday, December 14, 2005 9:54:45 AM (Eastern Standard Time, UTC-05:00)      Comments [0]  Observations | Storage Management