Untested Data Backup Is No Backup at All

A city had operated for a long time with tape backup and decided to upgrade. City administrators heard from their IT staff that they needed something more reliable than a manual solution reliant upon busy people to both conduct the backup and store it offsite.

Spending a lot of money on a modern complex data backup solution, the city was assured by its IT staff that this automated beast would solve all their problems. Indeed, the data backup worked automatically. In a meeting, IT staff showed city department heads the wonder of the data backup system by retrieving a few PDF documents from the backup data storage. To city council and the public, the city administrator proudly said they had ticked data backup off their list. Problem solved!

One day, a fire tragically tore through most of city hall. The building ruined, city staff needed to relocate to a temporary building until a new city hall was built. But thank goodness—despite all the servers destroyed—that the city could retrieve its data.

Or not. When IT staff attempted to restore the city’s data through its backup, most of the major databases, applications, and data would not restore. A few chunks of data—like some people’s individual documents—were okay. But the city’s most important information was not there.

And so...an expensive backup solution became nearly worthless. Why? Upon further investigation, the city administrator was told that nobody ever tested the data backup. “But...it was an expensive solution,” the city administrator said. “And my IT staff said that it was automated. The data backup solution’s reporting even said it worked.”

Well...it didn’t. And that’s all that mattered when the city administrator had to now explain why this expensive investment failed them after a disaster—and failed to do the exact thing it was supposed to do.

Preventing This Disaster

One aspect of data backup and disaster recovery—testing—is nearly as crucial as simply having data backup at all. No matter what kind of data backup you use, you need to test it. Otherwise, you don’t know that it’s working.

Let’s look more closely at the errors in our city scenario above.

Error #1: Assuming the data backup works.

A data backup solution will often look like it’s doing its job. From manual solutions like tape to more sophisticated automated data backup servers, the data backup application will often indicate that the process is a success or failure. But no matter what the application tells you, you don’t know that it works until you test it.

Error #2: Not testing all the backed up data.

Calling up a few files such as PDFs from the data backup storage is not testing. When a disaster hits, you will need to be fully operational with your databases, software applications, website, email, and documents. For example, will your account system work from a backup copy? When you test, test everything. Simulate what would happen if an actual disaster hit.

Error #3: Develop a plan and document it.

Testing needs to be part of your overall disaster recovery and business continuity plan. The act of testing not only guarantees you will access the data but also allows you to practice how data recovery will work. Who does what? How fast will the data be restored? In what order? Where will you access the recovered data?

You want to run into issues during testing and deal with them in a simulation—rather than after a real disaster.

Uncertain about your data backup solution? Are you testing it at least quarterly? Reach out to us today.

Original Date: 4/11/2017