A backup isn’t a KPI. A restore is. If the only number you track is “backup job completed,” you’re measuring that a process ran, not that your customers’ data is safe, and the only backup restore test that counts is one where somebody actually gets the data back. I didn’t fully appreciate the gap between those two things until I watched a small web company lose everything its users had trusted it with, about a month ago.
Early on Friday, January 30, the social bookmarking service Ma.gnolia went offline after what its founder, Larry Halff, called every web service’s worst nightmare: data corruption and loss. The first reports said both the primary and the backup data had somehow gone. Halff told members the recovery would take days, not hours, and that he couldn’t promise when or to what degree their bookmarks would come back. That’s an honest message. It’s also the message nobody in support ever wants to send, because there’s nothing behind it but hope.
Last month the answer came. A specialist couldn’t recover anything from the corrupted drive, and Ma.gnolia told users that all of the member data was gone for good. The database held nearly half a terabyte. Halff, to his credit, said plainly that he’d made a huge mistake in how he set up his backup system. Members who couldn’t scrape their bookmarks back out of the Google cache or other public copies simply lost them.
Why does “backup completed” tell you so little?
Because it measures effort, not outcome. I made this argument about launches last autumn, in choosing the right KPI from the customer’s side, and backups are the same trap in a quieter room. A backup job finishing tells you a copy was attempted. It doesn’t tell you the copy is complete, that it isn’t carrying the same corruption as the original, or that anyone on the team knows how to put it back. Every one of those is a separate question, and the green tick answers none of them.
Here’s the uncomfortable bit. Most teams I’ve talked to can tell you their backup schedule without looking it up. Very few can tell you the last date they restored something from it and checked the result. That isn’t laziness. A restore test takes time, it pulls a person away from the queue, and it produces nothing anyone outside IT will ever see on a good day. So it slides, and it keeps sliding, until the day it’s the only thing that matters.
The customer doesn’t care how often you copy their data. They care whether they get it back. Pick the number that answers their question, not yours. A backup you’ve never restored is a theory about your data. It isn’t proof of anything.
What should a backup restore test actually measure?
Start with the plain question: when did we last restore real customer data from a backup, end to end, and confirm it was right? That date is the KPI. Put it on the same page as your other operational numbers and let it age in public. If it’s three months old, everybody can see it’s three months old, and that alone does more than any policy document. Nobody enjoys explaining a stale date in a review meeting. That small discomfort is the point, because it gets the test scheduled long before a customer ever has to ask where their data went. I’d rather have one slightly awkward conversation a quarter than one catastrophic one a decade.
Then add the two numbers that turn a single test into something you can manage. The first is time to restore: how long it took from “we need this back” to “the customer can see it.” That’s the number you’ll be asked for on the worst day of the year, so you should know it before then. The second is the share of the restore that came back intact. A restore that brings back 90 percent of the records isn’t a success with a small footnote. For the customer whose records sit in the other 10 percent, it’s a total failure.
I’d keep the test small and regular rather than big and rare. Pick one account, one mailbox, one project folder, and bring it back somewhere safe. Have someone who didn’t set up the backup do it, from the written instructions, because the person who built the system is exactly the person who’ll be on holiday when it breaks. If the instructions don’t work for them, you’ve found the problem cheaply. That’s the test doing its job.
None of this needs special tooling. A spreadsheet with the date, who ran it, how long it took and what came back is enough to start. The discipline is the hard part, not the technology. After three or four months you’ll have a trend line, and the trend line is what tells you whether restores are getting slower as the data grows.
Where does support fit when the data is already gone?
Right at the front. Once the data is lost, the support team is the product. Every customer who writes in about a missing bookmark, a missing file or a missing order is an incident, and all of them trace back to one problem. That’s the incident and problem split I described in what a help desk is, and it matters more here than almost anywhere. Tag every contact to the one problem and you can tell leadership exactly how many customers were hurt. Don’t, and you’ll be estimating in a meeting while the angry emails keep arriving.
The other thing support owns is the message. Ma.gnolia pointed its members to a Twitter account for updates and told them honestly that it didn’t know the outcome. That was the right instinct. When you don’t have good news, the most valuable thing you can give a customer is a straight answer about what you know, what you don’t, and when they’ll hear from you next. Then keep that promise, even when the update is “no change yet.” Customers can live with bad news far longer than they can live with silence. A short update every day that says “still working, here’s what we’ve tried” keeps them with you while the technical people do their work.
What support can’t do is make up for a restore nobody tested. No script, no apology and no goodwill credit brings back a customer’s data. When Amazon S3 went down last year, the service came back and the credits were a sideshow. When data is gone, there’s nothing to come back to. That’s why the support leader has a stake in the restore test even if they’ll never run one themselves. They’re the person who has to take the calls if it was never done.
How do you get a restore test onto the calendar and keep it there?
Give it an owner and a date, the same as any other operational review. Monthly is a sensible starting point for a small team. Put the result in front of the same people who see your response times and backlog, so it gets read in the same breath. A number that only gets looked at when something’s gone wrong teaches everyone to ignore it the rest of the time.
Set a threshold you’re willing to act on. If the last successful restore is more than one cycle old, it’s red, and red means someone stops what they’re doing and runs one this week. If time to restore has crept up since the last test, find out why while it’s still a curiosity rather than a crisis. Write the thresholds down before you need them, because the argument about whether a restore test can wait always sounds reasonable until the day it can’t.
I’d also be honest about size. Ma.gnolia was, by most accounts, close to a one-person operation running on two servers and four Mac minis. Plenty of support teams sit on top of systems that aren’t much bigger, especially in smaller companies where IT is one person and a shared drive. The smaller the team, the more likely the backup was set up once, by one person, and never looked at again. That’s the team that most needs the test, and the one least likely to have time for it.
I used to think a backup schedule was the safety net. It’s the rope. The safety net is knowing, from a test you ran last month, that the rope holds. Ask your team for the date of the last restore before you ask them anything else about backups, and listen carefully to how long the answer takes.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
