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.

Two kinds of data

The catalogue is reproducible. Every course and lesson lives in db/seeds.rb and db/seeds/*.json, in version control, and bin/rails import:lessons rebuilds them from those files.

Losing the database doesn't lose the catalogue. It loses the time it takes to run an import task.

Everything a learner did isn't reproducible: accounts, enrollments, lesson completions, code submissions, experience points. None of that exists anywhere but in Postgres and its backups.

flowchart TB
  D["the production database"] --> R["catalogue: courses and lessons"]
  D --> I["learner data: enrollments, completions, submissions, XP"]
  R --> G["also in git. rebuildable by a rake task"]
  I --> N["nowhere else. gone means gone"]
  G --> S["most of the bytes"]
  N --> T["all of the loss"]

The asymmetry is the point

Most of the data is reproducible, and all of the irreplaceable data is small.

That combination is unusually favorable, and it changes what a sensible backup looks like. You aren't protecting a large database; you're protecting a handful of tables.

A team that hasn't done this inventory tends to reason about the database as one thing, conclude that backing it up properly is a project, and defer it. The inventory is what turns it back into an afternoon.

The thing that isn't in the database at all

RAILS_MASTER_KEY decrypts config/credentials.yml.enc.

It lives in the operator's shell and in the running container's environment, as the senior course "Infrastructure: Kamal 2" established, and deliberately not in the repository.

If it's lost, the credentials file in version control becomes permanently undecryptable. No backup of the database helps, because the key was never in the database.

That's the most severe loss available in this project, and it isn't a database problem at all.

The uploads

/opt/newbieonrails/storage on the host holds Active Storage files, such as partner logos and course cover images.

They aren't in the database and aren't in git, so a backup plan has to name that directory as well as the database.

Key takeaways

• Disaster recovery starts with an inventory of what's irreplaceable, not with a schedule.
• The catalogue is in git and rebuildable, so losing the database doesn't lose it.
• Learner data exists only in Postgres and its backups.
• Most of the data is reproducible, and all of the irreplaceable data is small.
• RAILS_MASTER_KEY is the most severe possible loss, and it isn't in the database.