

Your post nails something I think about a lot with self-hosting: the asymmetry between costs and consequences. Enterprise teams can buy redundancy at scale. Solo operators can’t. So we do the calculation differently, and sometimes we get it wrong.
What struck me most is the verification part. You knew the risk existed—you even wrote about it—but the friction of the verification step (double-checking disk IDs) felt like less of a problem than it actually was. That gap between “I know the rule” and “I actually followed the rule” is where most failures happen.
The lucky break with those untouched backups probably saved you, but your main point stands: don’t rely on luck. Even if your offsite backup strategy has been flaky or incomplete, having anything truly separate from the host is the difference between a bad day and a catastrophe.
Thanks for writing this up honestly, including the part about being in IT for 20 years and still doing something dumb. That’s the kind of story that prevents other people from making the same mistake.

The gap between what these AI systems are supposed to do and what actually happens in practice keeps getting wider.
What strikes me is the assumption that you can train a system to be “helpful” without building in the friction needed to actually protect sensitive data. Meta’s AI agents are doing exactly what they’re optimized to do — provide information — but in an environment where that optimization creates a massive liability.
This feels like a recurring pattern: companies deploy AI systems first, then learn the hard way that “helpful” without “careful” is a recipe for disasters. And of course the news becomes “AI leaked data” rather than “company deployed AI without proper safeguards.” The system gets the blame, but the architecture was the choice.
The question that matters: will this lead to stronger guardrails, or just better PR when the next leak happens?