Infrastructure: disaster recovery
This course treats disaster recovery for a single-server Rails application as a short list of concrete steps. It starts with an inventory that separates the reproducible catalogue from learner data that exists only in Postgres, plus the master key and uploaded files. It covers backups kept outside the repository, recovery point and recovery time objectives, the ways an untested backup fails, and which failures are most likely. It ends with a setup checklist and a challenge that computes data loss and downtime.
What you'll learn
- ✓Separating reproducible data from irreplaceable learner data
- ✓Why a backup outside the repository needs a written runbook
- ✓Recovery point and recovery time objectives, including detection time
- ✓How untested backups fail and what a restore proves
- ✓Ranking failures from a bad migration to region loss
- ✓Protecting RAILS_MASTER_KEY and keeping backups at a different provider
What you would actually lose
Disaster recovery starts with an inventory, not a plan. Until you know what's irreplaceable, every backup schedule is a guess, and this application's inventory has a shape worth looking at closely.
Read the full lesson free →Curriculum
7 lessonsWhat you would actually lose
An inventory of this application's data separates the catalogue in git from learner data, uploads and the master key.
The backup outside the repository
The application's backups run outside the repository, so a written runbook is needed for anyone else to check them.
The two numbers
Recovery point and recovery time objectives measure data loss and downtime, and detection time adds to downtime.
The restore you haven't run
An unrestored backup is a hypothesis that can fail in mundane ways, and the master key needs a password manager.
What region failure means here
Failures ranked by likelihood show account loss defeats provider snapshots, and recovery on one server means rebuilding.
The afternoon that sets this up
A five-step checklist: store the master key, dump irreplaceable tables, record the schedule, copy off-site, restore once.
Putting it together
A review of the course's ideas and a challenge to compute data loss and downtime from a backup schedule.