We put the IT in city®

CitySmart Blog

Tuesday, February 21, 2017
Nathan Eisner, COO

Nathan EisnerWhen is offsite data backup not offsite data backup? The following story offers an example—and a warning—to cities.

A city was already backing up its data onsite using an extra server. If the server failed at city hall, the other one would take over to restore the city’s data. However, some department heads urged the city to also consider an offsite data backup plan in case of a major disaster. The city manager researched some options and brought in a few IT experts to talk about possible solutions.

After some outside IT experts reinforced and reiterated the idea of creating both an onsite and offsite data backup plan, the city took a shortcut. The city manager didn’t like the idea of sending data off to a data center. He viewed it as unnecessarily expensive. Plus, he wanted control—to “see” the data when he wished. And so the city nixed the idea of offsite data backup located far away from the city.

As a result, the city worked around these parameters to build an “offsite” data backup plan. Working with their local IT vendor, the city set up a backup server in a building they owned located just down the block from city hall. The city manager argued that this building was separate from the city hall building and, thus, “offsite.” If something destroyed city hall, this server would contain all their data. Problem solved.

Or was it?

One day, a huge EF3 tornado descended upon the city. With winds upward of 150 miles per hour, the tornado destroyed many buildings in a swath of downtown. As the city assessed the damage, they discovered that the tornado destroyed not only city hall but also all buildings on that block—including the “offsite” building that stored the city’s backed up data.

With its data permanently lost, the city found itself at a crippling disadvantage at the very moment when citizens needed city hall and public safety operating at full capacity as soon as possible after the disaster. And even beyond the disaster, the city would have to deal with permanent data loss affecting its operations for a long, long time.

Preventing This Disaster

Does this scenario seem unlikely? That’s what all cities, businesses, organizations, and people often think...until after the disaster strikes. With increasing numbers of tornadoes each year in the United States that grow bigger and more devastating, it’s not unlikely that your city may face this threat—or any other similar threat.

Let’s look at the errors in our story and how your city can avoid them.

Error #1: The city’s definition of “offsite” is not really offsite.

Offsite does not mean down the block. It does not even mean two blocks away. True offsite data backup means many many miles away. When your data is stored in a geographic location far away from your city, it’s likelier to be protected from a localized disaster such as a tornado.

We often recommend that you send offsite data to at least two data centers (for example, one on the East Coast and one on the West Coast). It takes some time to set up the technology and the automated data transference to these data centers. But once set up, the offsite data backup runs without the city having to do much of anything. And if a city block is destroyed, your data is safe and accessible from multiple data centers. Your city can start operating within hours of the disaster while you are in the process of ordering new servers.

Error #2: An improper risk assessment focused too much on cost instead of the cost of a disaster.

Sure, it might be cheaper to set up another server in a building down the block. It’s also cheaper to buy health insurance with high deductibles that don’t cover serious medical conditions. In each case, the costs are astronomical when a disaster hits. Cheaper isn’t better and it’s a poor tool to judge a data backup solution’s ability to mitigate risk.

What’s the cost of losing your data? How will your community be impacted if all city records are lost? That’s the cost you should assess. From there, you can make a better case for investing in a disaster recovery solution that mitigates risks by storing data in a geographical location far from your city.

Error #3: A need to “see” the data and keep it close.

An ability to “see” and be near where your data is stored doesn’t mean it’s more secure. A server inside your city can lack the most basic security protection and be more open to hackers than your offsite data backup locked down with the highest security standards in a data center far away. Focus on security and an ability to recover from a disaster, not proximity to your data.

Error #4: A lack of a disaster recovery plan.

Clearly, this city did not think through the consequences of a disaster. They didn’t think through scenarios such as a tornado that can affect a wide area. Not prepared for a probable worst-case scenario, the city found itself completely without its data or a plan if it lost its data. Instead, it assumed that a disaster destroying both buildings was so unlikely that they didn’t have to worry.


For cities, a disaster recovery plan needs to include proper offsite data backup. We recommend that any offsite data backup plan considers:

  • A minimum of daily backups sent offsite.
  • Sending those backups to a data center in a distant geographic location.
  • A minimum of quarterly testing to ensure that your data backups are working.

Questions about your offsite data backup and disaster recovery plan? Reach out to us today.