AI Hints
Home›MLOps Tutorial›Reliability
MLOps · Lesson 48 of 80

Disaster Recovery

Backups, and maturity.

⏱ 2 min read▶ Video at 2:00:06🎓 Free
Watch this lesson in the MLOps courseWatch on YouTube ↗Full MLOps course

What if a whole region goes down? What if somebody deletes the model registry, or the feature store is corrupted? Disaster recovery means being able to rebuild, from almost nothing. The good news is, that if you followed the habits in this course, most of the work is already done. Let's connect the dots.

Disaster Recovery
From the video: Disaster Recovery
  • Rebuild from almost nothing
  • Habits you already have
  • Practice the recovery

What to protect, and how

List what you would need to rebuild. The code, in Git. The pipeline definitions, in Git. The data, versioned, with copies in more than one place. The model artifacts, and the registry, backed up, with their lineage. The configuration, and the infrastructure, written as code, so that a new environment can be created by a command. And the secrets, in a vault, with recovery procedures. If everything is declared in files, then recovery means, run the files, in a new place.

AssetHow it is protected
Code and pipelinesGit, with remote copies
DataDVC remotes, replicated storage
Models and registrybacked-up storage, lineage kept
Infrastructuredeclared as code, rebuilt by command
Secretsvault with recovery procedure

Two numbers to agree on

Two numbers shape every recovery plan. The recovery point objective, how much data can you afford to lose, measured in time. If it is one hour, backups must run at least hourly. And the recovery time objective, how long can the service be down. If it is four hours, your rebuild must be that fast, and you must have rehearsed it. These numbers come from the business, not from engineering, because they decide how much to spend, on redundancy, and on practice.

  1. RPOhow much data can we lose?
  2. RTOhow long can we be down?
  3. Plan and spendbackups, redundancy, rehearsals
  4. Rehearsea recovery you never tried is a hope
Business sets the numbers
Two numbers to agree on
From the video: Two numbers to agree on

From heroics to maturity

Finally, a look at team maturity. In an immature team, each release is an event, models are fragile files, and fixes depend on one expert, who stays late. In a mature team, releases are routine, every model is reproducible from code and data, incidents follow a runbook, and any engineer can respond. Maturity is not about tools. It is about habits, versioning, testing, automation, monitoring, and learning, repeated until they are boring. Boring operations are the goal.

Immature

  • Every release is an event
  • Models are fragile files
  • Depends on one expert
  • Incidents are improvised

Mature

  • Releases are routine
  • Everything is reproducible
  • Any engineer can respond
  • Runbooks and reviews

Summary

Wonderful. Disaster recovery rests on code, versioned data, backed up artifacts, and infrastructure as code. Agree the recovery point and the recovery time with the business, and rehearse. Mature teams make operations boring. Next, case studies, to see these ideas working together.

Key takeaways
  • Everything as code, versioned
  • RPO and RTO from the business
  • Rehearse recovery
Next up: Case Studies — three systems, end to end