You have a backup—but can you restore it?
Backing up is a process; being able to restore is a skill. Companies that assume the two are the same only realize this the day they lose their data.
When asked about backups, almost everyone says, “We take them.” But when the follow-up question is asked—when was the last time you restored data?—the picture changes: in most companies, the answer is never.
A backup is a file; a restore is a test. An untested backup is like insurance you think you have but don’t.
Three questions, three distinct answers
The effectiveness of a backup routine isn’t measured by a single number:
- How much data will I lose? As much as the time between two backups. If you back up once a day, the worst-case scenario is a day’s worth of work.
- How long will it take to get back up and running? Including downloading, installing, and verifying the file. This time is often many times longer than expected.
- Is the recovered data accurate? A backup that’s only half complete is more dangerous than one that doesn’t arrive at all: you’ll keep working, and you won’t notice what’s missing until months later.
A backup stored in the same location isn’t a backup
A copy stored on the same disk, in the same account, or in the same data center as the server will be lost along with the primary data in a single incident. In a ransomware scenario, every accessible copy is encrypted—which is why at least one copy must be immutable after it’s written.
The drill must have a schedule
A restore drill should be conducted once a year, with a predetermined date and documented results: how long it took, what was missing, and which step failed. In a system where drills aren’t performed, the first real test happens on the worst possible day.
The statement “We have a backup” is not a fact, but an assumption. A company that tests it once and records the time required knows in advance how much time it will lose on the worst-case scenario.