Last time on the GovCyberHub, we explored the first four steps of our seven-step guide that your government agency can use to inform your organization’s data backup strategy, going over how to effectively evaluate and assess your data, risks, goals, and the tools that will assist in realizing those goals.
This week, we will go over the final three steps that will cover how to build, document, and test your federal agency’s data backup strategy:
5. Build an offsite data backup strategy
In part one, we went over the 3-2-1 rule. Part of the 3-2-1 rule is storing your data somewhere off site and secure. Think of your second-site options in terms of temperature:
- Cold, like tape storage. Again, tape is inexpensive, and a valuable defense against ransomware, but it comes with long recovery times.
- Warm, like secondary backup onto a service provider’s disk storage.
- Hot, like replicating an entire data center. While it’s expensive, it allows you to fail over with everything already in place and running.
Again, your decisions about backup systems are driven by how the people who own the data want you to recover it for them. In other words, to what extent do you duplicate your primary solution set? How far down do you scale what you have in your data center?
Note that cloud backup is becoming increasingly viable for off-site storage. You can perform simple recovery from cloud storage if things go horribly wrong, or you can subscribe to disaster recovery as a service (DRaaS). The cloud offers readiness with a big cost advantage: you don’t have to pay for infrastructure until you start using it. Recovery is slower than if you had duplicated your entire solution set, but it’s quicker than having to rebuild everything from scratch, given lead times on hardware.
Your data backup strategy is about more than just retaining and securing data. It’s also a matter of being ready with the recovery technology best suited to the type of risks and data described above. The conversations you have with your managers inform the recovery technologies you invest in for data readiness.
6. Document your plan
To cap off all of the effort that you put into planning for recovery, it’s important to document it. Your written recovery plan spells out your data backup strategy, how you back up, how long you keep which kinds of data and your SLAs back to the agency.
IT administrators often get stuck here because they spend years thinking, “I back up our data,” but they don’t think any further. As described above, the recovery piece is what matters most to the organization, so that’s where your plan must focus.
Without a documented disaster recovery/agency operation continuity plan in place, you could expect to face long recovery time.
If you hadn’t planned an order for recovering applications and data — including the process and time to recover them — then it could take you days or weeks to recover. You’d be lost without an understanding of system dependencies. You’d run from pillar to post trying to get everything working, without regard to the right order and to the higher-level priorities of the agency. Without a plan, you’ll spend more money and more time, with collateral damage to things like your mission goals.
With a documented plan in place, on the other hand, your risk and recovery time would start to fall. More planning would position you to be able to recover applications and data in the order in which the agency needs them. Consequently, you would spend less money and time recovering from disaster, with a lesser likelihood of reputational damage.
7. Test your data backup plan
It’s important to point out that the biggest mistake agencies make is neglecting to test, or challenge, their data backup strategy.
They trust their backup solution implicitly, but, like any other kind of software, it can have bugs or do unexpected things. For that matter, they may have configured it incorrectly. They say, “It backs up every day of every week and it runs smoothly — no error messages.” Then, when they have an outage and try to restore, there’s nothing there.
So test to make sure you can restore data and use it as well. Have you tried to mount a database so you know whether it’s corrupted? You might have a file back, but can you use it?
Testing always seems like too much work, but it’s always less work (under less stress) than scrambling to recover with a backup set that is less perfect than you thought. Consider automating some testing — the way Engineering does — to add coverage. You can perform automated recovery as well.
Finally, build your data backup strategy into the IT planning cycle. That means that everything you put in place for your government agency to use has a relevant backup that meets the restoration requirements. Remember that the goal of backing up is to restore data and it’s part of the whole IT planning cycle.
Conclusion
The moral of the foregoing seven steps is that, if you can’t back it up and recover it, then you shouldn’t put it into production. To do so is to put your federal agency at risk.
When managers in the agency want to introduce a new technology, application or data set, you’ll have the same conversations with them about risks, data, and goals. Set a policy of not deploying anything new until you can protect it properly and put it into the recovery plan.
Once that plan is in place, and you’ve documented and tested it, you can then say that your data backup strategy is sound, and that your applications and data are protected and can be restored according to your predicted SLAs.
This article originally appeared on Quest’s official blog, HERE.
To read Part One of this data backup and recovery series, click HERE.
