Running a Datacenter Through Hurricane Katrina: What It Taught Us About Disaster Recovery

Today is June 1—the official opening of the Atlantic hurricane season. Every year it arrives with the same question for Gulf Coast businesses: if a major storm hit tomorrow, would your data survive it? For members of our team, that question is not hypothetical. In 2005, they helped keep a downtown New Orleans datacenter online through Hurricane Katrina and the weeks that followed. What that experience taught them still shapes how StratiBack approaches disaster recovery today.

When the Levees Failed

The storm itself was the part everyone had planned for. Datacenters in hurricane country are hardened against wind and rain, and a well-built facility can ride out a major storm largely intact. Katrina’s landfall was not what broke New Orleans.

The levee failures were. When the flood protection system gave way, large parts of the city went underwater, and the assumptions behind every local disaster plan went underwater with them. The electrical grid didn’t just blink—it went down and stayed down, in some areas for weeks. Landline and cellular networks collapsed under physical damage and overwhelming congestion, leaving even emergency responders struggling to coordinate. The city was evacuated and access was restricted. You could not simply drive downtown to check on your servers, swap a failed drive, or press a power button.

A datacenter in the middle of all that has exactly one lifeline: its generators. And generators run on fuel, which has to arrive by truck, through flooded and blocked streets, in a region where fuel had become one of the scarcest commodities around. Members of our team lived inside that problem. Keeping the facility online was less about servers and more about logistics—arranging fuel deliveries, improvising communication when the phones were dead, and making judgment calls without the people and information you would normally rely on.

Nothing about it was heroic in the movie sense. It was tiring, repetitive, and stressful, and most of the work was the unglamorous kind: watching fuel levels, rationing generator load, and finding one more way to get a message out of a city that had gone quiet. But the infrastructure stayed up—and the reasons it stayed up, along with the near misses, became the foundation of how we think about disaster recovery.

Five Lessons That Shape Our DR Philosophy

Two decades later, the technology has changed almost completely. The lessons have not. Here is what Katrina taught us, and how each lesson maps to a practice we build into every client engagement.

1. Offsite copies are the only copies that count

Every organization whose only copies of data sat inside the flood zone was betting its survival on a single building, a single power grid, and a single city. Some of those bets did not pay off. A backup in the same room—or the same region—as production is not disaster recovery; it is a convenience copy that shares every risk with the original.

That is why server replication to a geographically separate facility is at the core of our service catalog. When your systems are continuously replicated somewhere the disaster cannot reach, losing a building means losing hardware—not losing the business.

2. Backups you can’t mutate are the ones that survive

Floodwater is indifferent, but it is not the only thing that destroys data. In a chaotic recovery, well-meaning people under pressure overwrite the wrong volume, restore in the wrong direction, or reuse the one good copy as scratch space. And in the modern era, ransomware goes hunting for backups on purpose. The copies that survive a crisis—natural or man-made—are the ones that nothing and no one can alter.

Our object storage platform supports immutable snapshots and object lock: once written, backup data cannot be modified or deleted until its retention period expires, no matter whose credentials are used. Immutability turns your backups from “probably fine” into “provably intact.”

3. Runbooks beat memory when adrenaline is high

In the weeks after the storm, the people who knew where things were and how systems fit together were scattered across several states, often unreachable. Institutional knowledge that lived only in someone’s head might as well not have existed. The procedures that got followed were the ones that were written down, simple, and executable by whoever happened to be present.

Adrenaline makes smart people forget obvious steps. A disaster recovery runbook—which systems come up first, what depends on what, where the credentials live, who to call when a step fails—lets a stressed human act like a calm one. If your recovery plan requires a specific person to be awake, healthy, and reachable, you don’t have a plan. You have a hope.

4. Communication plans fail before servers do

Here is the part that surprises people: during Katrina, the hardest problem often wasn’t keeping machines running. It was talking to anyone about it. Phones were down, cell networks were saturated or destroyed, and teams that had planned to coordinate a response discovered they had no way to find each other. Your communication plan will fail before your infrastructure does, because it depends on the same fragile networks—plus the added complication of scattered, evacuating humans.

Every DR plan we help build includes a communication layer that assumes the primary channels are gone: out-of-region contact points, pre-agreed check-in procedures, and a decision-making chain that still works when half the team cannot be reached. Deciding in advance who can say “fail over now” is worth more than any single piece of hardware.

5. Test restores, or you don’t have backups

After the storm, plenty of organizations discovered the gap between “the backup job ran” and “the data came back.” Tapes that couldn’t be read, backups that had silently stopped weeks earlier, restore procedures no one had ever actually executed—none of these problems announce themselves until the day you need the data. A backup that has never been restored is not a backup. It is a theory.

We treat restore testing as part of the backup itself: scheduled test restores to isolated environments, verification that the recovered systems actually boot and serve data, and a written record of how long recovery really takes. Your recovery time objective is not what the brochure says—it is what your last test proved.

Built for Hurricane Country

Those five lessons are not abstractions to us. They are why StratiBack’s infrastructure lives where it does and is built the way it is: an inland Tier 4 facility outside Baton Rouge, away from the storm-surge zone, with 2N redundancy on power and cooling—two complete, independent systems, so there is no single path whose failure takes the facility down. We don’t operate in hurricane country in spite of the risk—we engineer for it.

Hurricane season runs through November 30. The best time to pressure-test your disaster recovery plan is before the first named storm is on the map—which makes today, the first day of the season, a very good day to start.