Family Self-Hosters Need a Backup and Rollback Preflight Before Every App Upgrade

There's a moment that separates a hobby homelab from one a family relies on: the upgrade. When it's just you, a botched update is an evening of tinkering. When your partner's photos, the kids' media, and the household's files all live on your server, "I'll just update real quick" can take everyone's stuff offline right before bed — and that's how trust in self-hosting evaporates. The fix isn't to stop upgrading. It's a short, repeatable preflight before every one.

Why upgrades are the risky moment

Upgrades change two things that can break independently: the app (new bugs, changed config) and the data schema (migrations that may not reverse — exactly the Immich database-migration problem). A "quick update" that hits a forward-only migration and then fails leaves you needing to restore, not retry. If you can't restore, you're debugging someone else's irreplaceable data under pressure.

The two-minute preflight

Before clicking update on anything the family uses:

1. Snapshot the data. A fresh database dump and a note of where the volume/library is — consistent, with the app stopped if it's database-backed (the app-owned-state rule).
2. Note the current version. Write down the exact image tag/digest you're upgrading from. Rollback means returning to a known artifact, not guessing — the pin-the-digest discipline.
3. Know the undo. One sentence: "to roll back, redeploy app:1.2.3 and restore last night's dump." If you can't write that sentence, don't upgrade yet.
4. Read the release notes for breaking changes — 30 seconds that prevents the nastiest surprises.
5. Pick a low-stakes time. Not 11pm when everyone's about to use it.

Make rollback real, not theoretical

A rollback plan you've never executed is a wish. Once — on a scratch copy — actually restore a backup and bring the old version back up. That single restore drill is what converts "I think I can roll back" into "I've done it." For a household, that confidence is the whole product.

A rollback playbook in ServerCompass — the pre-written undo (restore this backup, redeploy this version) that turns a bad family-server upgrade into a five-minute recovery.

Automate the boring parts

The reason people skip the preflight is that it's manual. Remove the excuse:

• Scheduled nightly backups so step 1 is already done most of the time.
• Version pinning so "what was I running?" is in the config, not your memory.
• A second person who can run the documented rollback if you're not around.

Preflight checklist

• Fresh, consistent data snapshot taken.
• Current version/digest recorded.
• One-sentence rollback plan written.
• Release notes skimmed for breaking changes.
• Upgrading at a low-stakes time; rollback rehearsed at least once.

Takeaway

When the family depends on your server, every upgrade is a small production change and deserves a production habit. Snapshot the data, record the version, write the one-sentence undo, and rehearse a restore once. Two minutes of preflight is what lets you keep the apps current and keep the household's trust.