Every business owner has heard they need backups, but few could tell you what the 3-2-1 backup rule actually requires, or why an AI coding agent’s mistake this year is as good an illustration of that gap as anything I’ve seen.
What Happened When an AI Agent Deleted a Real Database
On July 18th, 2025, Jason Lemkin, the founder of SaaStr, discovered that Replit’s AI coding agent had deleted the production database for a SaaS app it was helping him build for the firm. He had put the project under a code freeze specifically to stop any changes without his permission, and later said he’d told the agent, in his own words, “eleven times in ALL CAPS,” not to touch anything. The agent ran an unauthorized command anyway, wiping out live records for roughly 1,200 real executives and their companies. Then, rather than admit what had happened, it fabricated fake data to paper over the gap. Its own logs later described the incident as “a catastrophic error in judgment.”
When Lemkin asked whether the real data could be recovered, he was initially told it couldn’t be, that the database’s prior versions were gone for good. That turned out not to be true. The data was ultimately recovered, and Replit’s CEO publicly apologized, calling what happened “unacceptable” and promising changes so a single agent couldn’t take that kind of action again. But for a stretch of time, the loss looked permanent, and the only thing standing between recoverable and gone was whether a real, separate backup of that data existed somewhere the AI agent’s mistake couldn’t reach.
I’ve been sitting with that story because it re-frames something I only told half of back in April. Issue 4 covered the difference between redundancy and backup: your cloud provider keeping multiple copies of your live data is not the same as having a real backup, because whatever deletes, corrupts, or encrypts the original usually takes the redundant copies right along with it. That’s still true. But I never told you what an actual backup looks like structurally, and Lemkin’s story is as good an excuse as any to fix that.
What the 3-2-1 Backup Rule Actually Requires
The standard is called the 3-2-1 rule, and it’s been around longer than cloud computing has. Three copies of your data, total. Two different types of storage media, so a single hardware failure or software flaw doesn’t take out both at once. And one copy kept somewhere physically or logically separate from the systems it’s protecting, so that whatever goes wrong with your live environment, whether that’s ransomware, a compromised account, or an AI agent with too much access and too little judgment, can’t reach it.
Why the Isolated Copy Is the One That Matters Most
That third piece is the one people skip, and it’s the one that mattered most in Lemkin’s case. His agent had direct access to his live environment. If his only backup had lived in that same environment, reachable by the same credentials the agent was already using, there’s a real chance it would have been gone too, regardless of what he was initially told. It wasn’t, so the data came back. The whole point of the off-site, isolated copy is that you shouldn’t need luck.
I bring this up now specifically because AI coding tools and AI agents are showing up inside more small businesses every month, often with real access to real systems, and the mistake in this story wasn’t trusting the wrong tool. It was assuming that if something did go wrong, someone somewhere would be able to fix it. That’s a backup question, not an AI question, and it was true before agents existed and it will still be true after this AI moment passes. This is exactly the kind of thing that belongs in routine monthly IT work, not just crisis response.
If you don’t know how many actual copies of your business data exist right now, what kind of storage they’re on, or whether at least one of them sits somewhere a compromised account couldn’t reach, that’s worth finding out this week, not after something breaks.
