Free — no signup required

Introduction: When an Incident Becomes a Disaster

2 min read

Incidents vs. Disasters

In the previous topics, we talked about handling incidents: a database runs slow, a bug breaks a feature, or a server crashes. These are routine emergencies that your team handles weekly. They're painful, but they're survivable with a good on-call rotation and a runbook.

A Disaster is categorically different. A disaster is a catastrophic event that causes a complete, prolonged stoppage of your business operations — one that your normal incident response process cannot handle. Think big:

  • An entire cloud region (e.g., AWS us-east-1) goes offline due to a hurricane or a cascading infrastructure failure.
  • A disgruntled employee deletes all your production data and your backups.
  • A ransomware attack encrypts every server in your environment simultaneously.
  • A critical third-party dependency (a payment processor, an identity provider) suffers a multi-day outage.

The key distinction is scope and duration. An incident takes down a service for minutes to hours. A disaster takes down the business for hours to days — or permanently, if you're unprepared.

Business Continuity Planning (BCP)

Disaster Recovery (DR) is the technical part of a larger process called Business Continuity Planning (BCP).

  • BCP is the "big picture" plan for how the entire business keeps running during a crisis. It covers questions like: "Where do employees work if the office burns down?" "How do we process payroll if the finance system is offline for a week?" "Who is authorized to speak to the press?" "Which business functions are legally required to keep operating?"
  • DR is the specific IT subset of that plan: "How do we get the servers, databases, and applications running again — in a new location, with recovered data — within an acceptable timeframe?"

Think of BCP as the emergency plan for the whole hospital, and DR as the plan specifically for getting the operating rooms back online. DR cannot succeed in isolation; it must be coordinated with the broader BCP so that when the systems come back up, the people and processes are ready to use them.

If you don't have a tested DR plan, you don't have a business. You have a ticking time bomb.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free