Why backup verification matters more than backup itself

Here is a pattern I have seen more than once. A business discovers it has a serious problem: a ransomware incident, a failed server, a corrupted database. The owner or office manager says “it’s okay, we have backups.” Someone goes to restore from the backup. It fails. Or it restores but the environment will not boot. Or it restores to a state from eight months ago because the incremental chain has been silently broken since last fall and nobody knew.

The green checkmark in the backup dashboard means the job ran. It does not mean the data is recoverable. Those are two entirely different things, and most businesses only find out the difference during an actual emergency.

The specific ways backups fail without telling you

Corrupt incremental chains. Most backup solutions take a full backup once a week (or once a month) and then incremental backups every night. The incrementals capture only what changed since the previous backup. If one incremental is corrupt, every subsequent incremental that depends on it is unrestorable. The job still reports success because it completed the export. The corruption only surfaces when you try to reconstruct the chain at restore time. Depending on when the corruption happened, your most recent clean restore point might be three months old rather than yesterday.

Unbootable images. Disk imaging tools capture the entire volume, including the operating system and boot sectors. Sometimes the image is technically valid but the resulting system will not boot, due to driver conflicts, hardware abstraction issues, or errors in the boot record that got baked into the image. The image exists. The restore process completes without errors. The system never comes back online. Testing this requires actually booting the restored image in a virtual machine, which most backup workflows never do.

Excluded folders from a policy someone set years ago. Someone configured the backup agent in 2021. They excluded the Users folder because the profile directories were large and the backup window was tight. The configuration sat there for three years. The actual user documents, desktop files, and local application data were never backed up. The server backup ran every night and reported success. It just was not backing up the data anyone actually needed. Nobody noticed the exclusion until a restore attempt.

OneDrive and cloud sync mistaken for backup. This one comes up constantly. OneDrive syncs your files between your device and Microsoft’s servers. It is a sync tool, not a backup. If you delete a file, the deletion syncs. If ransomware encrypts your files, the encrypted versions sync to the cloud. Microsoft retains version history (93 days for Microsoft 365 Business plans), which provides some recovery window, but it is not the same as a managed backup with defined retention, tested recovery, and documented restore procedures. If your current backup strategy for a shared drive or file server is “it’s also on OneDrive,” that is not a backup strategy.

Backup rotation that ran out of space and started silently truncating. Backup destinations fill up. When the destination is full, most agents will either fail the job or start rotating out old backups to make room. If nobody is actively monitoring the backup reports, this change can go unnoticed for weeks. The job reports “complete with warnings.” The warnings say the retention policy was truncated. Three months of restore points are gone. The warnings are buried in a daily digest email that nobody reads because it says “success” in the subject line.

What real verification looks like

Verification means actually testing that the backup produces a working restore. Here is the minimum practice that makes a backup program meaningful.

Scheduled test restores. At least quarterly, take a specific backup snapshot and restore it to a test environment. For a virtual machine: spin up the restored VM, verify it boots, verify that critical services start, and verify that data is accessible and uncorrupted. For file backups: pick a representative folder, restore it to a test location, verify the files open correctly and their contents match what is expected. Log the test. Keep the log.

Measure your actual restore time (RTO). Recovery Time Objective is how long your business can afford to be down. Restore Time is how long the restore actually takes. Most businesses have never measured the second number. The estimate in their head comes from vendor marketing or guesswork. The actual restore time for a 500GB volume to a new server, over a WAN connection, might be eight hours. For a multi-terabyte database server it might be two days. If your RTO is four hours and your actual restore takes twelve, you have a problem that does not show up until you are in the middle of the incident.

Understand what data is actually protected (RPO). Recovery Point Objective is how much data loss your business can accept. If the last backup ran at 10pm and the incident happens at 4pm the following day, you lose 18 hours of work. Is that acceptable for your operation? The answer depends on what your team was doing during those 18 hours. For most professional services firms, losing a full business day of work is a serious problem. Most businesses have never had this conversation with their IT provider and have no documented answer.

Keep a restoration log. What was tested, when, what the restore time was, who verified it, and what was included and excluded from the test. If you are ever in a situation where you need to demonstrate your data protection posture to a cyber insurer, an auditor, or a client with contractual requirements, a restoration log is meaningful evidence. A backup dashboard full of green checkmarks is not.

The Anchorage factor

Anchorage is three and a half hours by air from Seattle. There is no same-day IT hardware delivery. If your on-premises server fails and you need replacement hardware, you are waiting at minimum for overnight shipping, and probably two days if the failure happens on a Thursday or Friday. The nearest enterprise colocation facility is in Seattle. If your disaster recovery plan requires spinning up a physical replacement server, the logistics of managing that remotely add real time to an already bad situation.

This does not mean disaster recovery is harder in Anchorage for cloud-centric businesses. If your workloads live in Microsoft 365, Azure, or a similar hosted platform, geographic distance barely matters. But if you are running on-premises infrastructure and your recovery story depends on physical hardware or local restore times, the geographic reality deserves honest planning. A restore that takes two days instead of six hours is the difference between a bad week and a business-continuity event. In a market where you cannot call a local equipment vendor and have someone drive over with parts, the restore time you measured during a quarterly test is the restore time you will have during the real incident.

Alaska Power also factors in. Utility disruptions in Southcentral Alaska are more common than in major metro areas, and generator and battery backup coverage for on-premises servers is part of any complete continuity plan here.

What to do with this

If you have a backup solution, ask your IT provider three questions: when was the last test restore, what specifically was restored, and how long did it take? If they cannot answer all three, your backup is a dashboard indicator, not a verified recovery system.

The free IT Health Check we run at Freeze Frame Solutions includes a backup audit. We look at what is being backed up, what is excluded, when the last verification happened, and whether the documented RTO and RPO match your business’s actual tolerance for downtime. We also look at whether the backup destination is healthy and what the current retention policy actually covers. It takes about 15 minutes of the conversation and it has never failed to turn up something worth fixing.