Most firms have backups but have never tested a restore. Here is why untested backups fail, what the 3-2-1 rule means, and what Microsoft 365 and Google do not cover.
Almost every firm I talk to says they have backups. Far fewer can tell me the last time someone actually restored from one. That gap is where the trouble lives. A backup is a promise about the future: when something goes wrong, you will get your data back. The problem is that the promise is invisible until the day you need it, and that is the worst possible moment to discover it was empty. Backup jobs report green for months while quietly skipping a folder, excluding a mailbox, or writing to storage that fills up and silently stops. Nobody notices, because nobody looks. Then a laptop dies, or ransomware lands, and the restore either works or it does not. The job ran. That is not the same as the data being there. There is a real difference between a backup job completing and a restore succeeding. The job is the easy half. It runs on a schedule, it copies files, it sends a confirmation. The hard half is the part most firms never exercise: taking that copy and turning it back into a working file, a full mailbox, or a usable system, within a time frame that actually keeps the business moving. I have seen backups that excluded the one shared drive everyone depended on, because it was added after the original job was configured and nobody updated the scope. I have seen retention set so short that by the time a problem surfaced, the clean version was already gone. None of these showed up as a failure. They showed up as a green checkmark, right up until the restore. If you take one thing from this, make it this: an untested backup is a guess. You do not have a recovery plan, you have a hope. What the 3-2-1