Backup 3-2-1 is table stakes - why restore drills are the metric that actually matters

The 3-2-1 rule is old, simple, and correct: three copies of your data, on two different media types, with one copy offsite. It is also, on its own, a rule about where data sits, not about whether it can be recovered. An MSP can be in perfect 3-2-1 compliance across every client and still discover, mid-incident, that a "backup" doesn't actually restore cleanly. Compliance with the rule and confidence in the recovery are not the same claim.

Why 3-2-1 alone can still leave you exposed

• A job can report success while backing up an incomplete data set — a scope misconfiguration, a quota silently truncating a mailbox, an exclusion rule someone added years ago and forgot about.
• A copy can exist in the right place, on the right media, and still be unusable if the credentials or encryption keys needed to access it have drifted out of sync since the backup was written.
• 3-2-1 says nothing about how long a restore takes — a technically complete backup that takes four days to recover from is a different business outcome than one that takes four hours, and the client's tolerance for downtime doesn't care which rule you followed.

A restore-drill checklist worth actually running

• Pick a real target, not a convenient one — restore an actual mailbox or file set a client would notice missing, not a trivial test file created solely to make the drill pass.
• Time it — record how long the restore actually took, from decision to usable data, and compare that number to what you've told the client to expect.
• Verify completeness, not just success — open the restored data and confirm it matches what should be there, not just that the restore job returned a success status.
• Rotate who runs it — a drill run by the same person every time only proves that person can do it; rotate it across the team so the procedure is documented well enough for anyone to follow under pressure.
• Put the result somewhere a client can see it — a logged drill outcome is evidence in a QBR or a compliance review; a drill that happened but wasn't recorded is functionally the same as a drill that didn't happen.

3-2-1 measures where your data sits. A restore drill measures whether you can get it back. An MSP that can only answer the first question is one incident away from finding out the second answer the hard way.

We've written before about the your-bucket-your-keys model behind Microsoft 365 backup in Nexus, and the design intent carries the same logic here: because the storage is yours, restore verification is work you schedule and own, not a support ticket to a vendor. The design goal is for that verification to be tracked as recurring, first-class work with its outcome recorded against the client — not a once-a-year fire drill nobody wrote down. The platform page has the current, honest status of exactly what's built versus still in progress.