When the towers collapsed, Thermo lost its development servers, which were in the WTC office, as well as file and e-mail servers, desktop workstations, and all the rest of the equipment necessary to run an office. We also lost hundreds of hours of work that hadn't yet been backed up, including new staging templates I'd been working on, improvements to the database by our data base administrator, and a host of bug fixes and interface improvements we had been planning to migrate to our co-location facility that week. However, the company had made some fortuitous choices in the past. The most important of those prior to the eleventh was the decision to co-locate most of the company's servers off site. While we lost a great deal, the lion's share of the Web site and its content, representing thousands of hours of labor, remained intact in New Jersey. The original impetus behind co-location was to protect against comparatively trivial problems, like power outages. But it was also economical, according to Wissman. "For most corporations, it makes sense to leave hosting to people who do it best. The systems you need, like truly redundant power and Internet access, are extremely expensive, but relatively cheap as a marginal cost in a co-hosted facility." Co-location reduces some risks, but it just transfers others to a different place. Realising this, Thermo now removes full data backups to an offsite location at least once a week. "We do a much better job than we used to," Wissman told me. "Until 9/11, we made nightly backups, but left the tape there. Now we take it off site-we're much more aware of what it really means to be redundant and backed up. It's cute to back up on a local tape, and it's useful if there's a grain of sand on the hard drive or whatever. But it won't help at all if there's a real event, potentially something as simple as a fire." Off-site backup can be as basic and cheap as having someone bring a tape home once a week, or as complex as having full real-time mirroring of all data between two facilities. While the latter approach, done correctly, eliminates the possibility of data loss, it requires significant throughput, and can be expensive. Leibundgut and Wissman determined that that level of service wasn't required, and that regular incremental backups would suffice. Every organisation needs to balance the costs of continuity strategies versus the cost of possible downtime. For a big company, continuity costs can be massive. According to a recent Network World report, Coca Cola Enterprises, the bottling division of The Coca-Cola Company, will spend over $400 million on a disaster recovery/business continuity plan this year, the largest IT project in the company's history. Thermo was lucky in many ways, because while the Web site was an important business tool, we weren't as reliant on real-time communication as some other companies. The site's primary purpose was to store the huge volumes of information the company has on the thousands of products sold by various Thermo business units. As Thermo increasingly relies on e-commerce, and uses the Web for internal business processes, the disaster recovery and continuity planning will have to change to reflect the changing role of the Web in the organisation. For now, Thermo has chosen to rely on increased planning using mostly equipment and software already on hand -- for instance, the development environment, housed in a separate facility than the production servers, can be converted to a stand-in production environment should the need arise. If a standby system is necessary, it doesn't have to be identical to the production system it's replacing -- fewer or less expensive servers may be suitable, since a lower level of service can be acceptable as long as availability is maintained. This decision will vary greatly depending on the type of business being protected -- for instance, a news organisation might see Web traffic spike in the event of a major catastrophe, and actually require greater capacity with their standby servers than their normal production servers.