Director’s Blog
2007 August

Here’s a scary statistic for you: The Mean Time Between Failure (MTBF) on hard disk drives is generally reported by manufacturers as 300,000 hours or more. That means that, on average, a disk will fail after 300,000 hours of use. That sounds like a long time–300,000 hours is 12,500 days, or about 35 years on average. Not so bad, right? The scary part is that I’d estimate there are at least 50,000 spinning disks on campus right now, which means that there are probably multiple disk failures on campus every day.

We recently had a hard disk drive failure in a customer’s machine that was not backed up. She lost years of stored email, along with a database and other documents which took uncountable hours to create. We’ve all heard similar horror stories, or lived through them, yet we still seem to make the same mistakes.

Some people back up their files to writable CDs or DVDs; removable media are cheap and it just takes a couple of minutes, right? That’s my backup scheme on my personal machine at home. Now ask me, how long has it been since I actually backed up my home machine? (Answer: No idea, but it was at least 6 months ago, probably a year or more. But thanks for reminding me–I’ll go do it tonight.) For backups to be effective, they really need to be automatic and invisible to the user.

Fortunately, the campus has an inexpensive automated system: UC Backup, which is based on IBM’s Tivoli Storage Manager. For just 30 cents per gigabyte of data stored, you can install the TSM client on your machine and be protected in case of data loss. The office of the Vice Chancellor for Research provides an additional subsidy; researchers can get their data backed up for only 15 cents per gigabyte while funds allow. (See UC Backup’s page for information on signing up for the service and the research subsidy).

LSCR would like to see all of our customers’ files (both staff and faculty) regularly backed up by UC Backup or a similar system. I’d recommend the same for all computer users in L&S departments. The cost is low and the benefit is large; our institution has a huge liability out there due to irreplaceable data not being backed up. We’ll be contacting our departments to encourage them to sign up all their users with UC Backup, if they’re not already. (Over half of our administrative staff users are already being backed up through UC Backup, but for our faculty it’s a very low percentage).

Side note: The campus-wide IT Strategic Plan identifies backup as a critical issue, and sets a goal of having 80% of faculty and staff backed up by July 2006. [Obviously the plan needs some updating.] Personally, I think that the current UC Backup model doesn’t put the campus in position to accomplish this goal; the low cost is OK, but the administrative overhead required to manage the billing, even for that small a charge, creates a barrier significant enough to keep many departments and individuals from rolling out this professional backup service. I would like to see the service be free of cost to the user up to some reasonable threshold of data storage; 10GB or so. It’s really not worth generating hundreds of BFS transactions for $1.50 each.

We’ve been working for almost a year now on a plan to migrate away from Eudora as an email client. Qualcomm announced last year that they are discontinuing Eudora as a product, and they have already stopped development. This has left us with an email client with known security holes which are never going to be fixed; an unpleasant situation for all concerned. Qualcomm had really given up on Eudora long before the announcement, so it didn’t come as a complete surprise to us.

Most of the team that was working on Eudora at Qualcomm, including Steve Dorner, Eudora’s original developer, are now working for the Thunderbird project. Thunderbird is an open-source, full-featured email client, and it really is a pretty good product. I’ve been using it myself for a few months, and I think it’s pretty easy to use, and more reliable than Eudora was.

We know that people have a lot of experience working with Eudora, and in some cases a huge number of existing mailboxes and address book entries. One of the things we’ve been spending time doing is coming up with documentation to help users with the transition. Check out our Thunderbird pages; they give some basic background on the program, as well as information which will help Eudora users familiarize themselves with the new client.

Right now we’re testing our migration procedures with a few test departments and with selected individuals; there are a few expected glitches, but in most cases the transition isn’t too difficult. We expect that we’ll be starting to schedule migrations for all our departments in September.

The UCB Messaging Steering Committee today sent out a memo to the campus technical mailing lists officially de-supporting Eudora, and recommending Thunderbird as a replacement. They give a deadline of October 31, but that deadline is kind of arbitrary; that’s the day the UC support contract with Qualcomm runs out, but it’s not like Qualcomm is giving us any support, anyway. LSCR’s timeline is a little more extended than that; we’re expecting to have the bulk of our users migrated by the end of the calendar year.

Contact your support team if you’re interested in being migrated early in the process, or if you have any questions.

At this week’s UCCSC conference, I spoke about a report that I’d helped write, on providing “less seamful services,” and better collaboration between distributed and centralized IT units. I spend a lot of time thinking about that issue, because LSCR is positioned right in the middle of it; to IST, LSCR looks like a department, but to our departments, LSCR tends to look like centralized IT.

(Aside: I would prefer that our customers view us as peers and partners. We do make an effort to behave that way: for example, we locate our folks in departmental space rather than moving off-campus to an office where we could all sit together. We’d rather be closer to the users. But looking at the survey and interview results so far, it seems we have a ways to go to really be seen as integral by most of our customers.)

The report was done as part of ITLP, which is a leadership program for IT folks in higher ed. The program included folks from Berkeley, UDub, Minnesota, and Penn State, and the report we did surveyed people in distributed and centralized IT at all four of those universities. Because they’re all large public research institutions, the issues tend to be pretty similar.

My presentation (.ppt) focused on the communication and collaboration challenges. We have a ton of meetings, but we spend too much time presenting to each other and not enough time talking to each other. Our communications tend to be along accepted and formalized lines, and we often gloss over or ignore the underlying issues which keep us from moving forward. And yes, there is an irony that I was making this point via a PowerPoint presentation; however, the most important part of my presentation was a break-out session where I got the folks from each campus to talk to each other about the pressures or barriers they are facing in their local organization. I think it went well; the room got noisy enough that it was hard to hear, which I took as a good sign.

The report (.doc) addresses the above issue of communication and collaboration, and also has a number of recommendations to make the user experience better in specific technical areas (desktop support, email, and information systems).