Skip to content

homelab-dr-blueprint, in plain language

What problem does this solve?

You've got four home computers running Docker. One of them holds a database (claude-mem's memory) that you really don't want to lose. Home Wi-Fi is flaky, addresses change, and none of these machines are dedicated servers that stay on forever. This repo is the plan for: how do you keep that database safe and get services back up quickly if a machine dies, without turning your living room into a data center?

The short answer

Don't build a fancy cluster. Fix your network naming first, run things with Docker Compose (a simple "start these containers" file checked into Git), and write — and actually test — a backup/restore plan for the one thing that truly matters: the database.

A panel of three AI models was asked "should I run Kubernetes at home for this?" and they all agreed: no, not as your daily driver. Kubernetes is built for data centers with dedicated, always-on servers and shared network storage. None of that exists in a home lab with laptops that sleep and Wi-Fi that changes your computer's address every so often. Using it here would mean constantly fighting the tool instead of getting value from it.

The plan, in four steps

  1. Give every computer a name that doesn't change. Right now your router might hand out a different address every time a laptop reconnects. Step one fixes that so "the database computer" always means the same thing.
  2. Describe what should run in a file, and check it into Git. Instead of remembering "I ran this command with these flags," you write it down once (a Docker Compose file) and one script brings it up the same way every time, on any machine.
  3. Back up the database every hour, and prove the backup works. A backup nobody has ever restored isn't a real backup — it's a hope. This repo backs up hourly and runs a nightly rehearsal that restores the backup into a throwaway copy and checks the data is actually there.
  4. Have a tested "break glass" plan for when a machine dies. One script walks through: confirm the old machine is really down, restore the latest backup, bring the database up on a different machine, and point everything at the new location. You practice this before you need it for real.

What about Kubernetes, then?

It's still in here — in a folder clearly marked "practice lab, not production." If you want to get better at Kubernetes for a job, you can spin up a real (small) cluster, break it on purpose, and watch it heal, without risking the one thing you actually care about (your data). When your home setup changes — say you buy a small computer that's always on with a fixed address — the rules for when it's actually worth switching to something fancier are written down in ../when-to-graduate.md.

Where the "real" explanation lives

This page is the plain-language summary. The full technical version — with the scored comparison table, the diagrams, and the exact commands — starts at ../../README.md.