What would happen if you went to work today to find that your data center was hit by a major power outage and you couldn’t access your servers? Or that a hacker had installed malware, corrupting your data? What would you do in these database disaster situations? Do you know? 

Most people think backing up data is the answer. They’re not wrong, because that is important. But simply having data backed up doesn’t do much if you don’t know how to bring systems back online, haven’t tested processes or haven’t kept all departments in the loop about the disaster recovery plan. 

Let’s discuss some best practices for disaster recovery, so you rest assured that your data is protected. 

Have a Plan

Making a disaster recovery plan is the first and most important step in safeguarding your data in the event of a disaster. The plan should be well-documented and include these important elements: 

• Information about where the backups are located and how to access them.
• Step-by-step instructions for bringing servers back up and enabling access to them.
• Identification of key employees and departments involved in the disaster recovery process. 
• Details about which data is essential to bring up as soon as possible and which data can become accessible later.

The plan and its documentation must be updated regularly and department specifics should be managed by each department, with at least one employee who serves as a backup and is knowledgeable about the plan. If a new server is added as the company grows, that server’s disaster recovery must be integrated. Similarly, if the process changes after testing (yes, you must test the process), the documentation must reflect that. 

Set Expectations

No one wants to lose data, but the reality is, most companies can afford to lose some in the event of a disaster. What’s more, most companies can’t afford to insist on not losing anything, because with these expectations comes the need for more resources and, in turn, higher costs. Likewise, the sooner companies need data restored, the more resources are required. Let us explain. No, this will take too long; let us sum up.

Your recovery point objective, or RPO, is how much data you can afford to lose, and it’s typically measured in time. If you’re a smaller company with fewer incremental changes made to your data daily, maybe you can afford to lose one day’s worth of data. In other cases, companies may put that RPO at a couple of hours or even measure it in minutes. 

Your recovery time objective, or RTO, is how quickly you need data to be restored. This may vary with different tiers of data. For example, you may need sales and inventory data restored and available in a couple of hours, but the payroll database may be able to wait a few days. A certain server may contain key data that needs to be accessed more quickly, while another contains data that’s needed less frequently. 

RPO and RTO are highly variable from company to company, but it’s important to consider and spell out what these variables are, and also to understand that, the less data you’re willing to lose and the quicker you need it back up, the more expensive it’s going to be. 

Depending on the size of the company, setting these goals or expectations will likely require collaboration with multiple departments and key players. In some cases, these variables may be part of client contracts.  

Communicate and Collaborate

While the information technology department typically has the most responsibility for data disaster recovery, it’s important to obtain buy-in and cooperation from other departments. After all, everyone in the company needs to access data, so understanding how it’s backed up and what to do when it’s not available is important for everyone. 

If possible, develop a disaster recovery team that includes not only IT professionals but representatives from other key departments and upper management. The more people understand what goes into disaster recovery, the more smoothly the plan will run when and if a disaster occurs.

Consider Leveraging “The Cloud”

Cloud services like Microsoft Azure, Amazon Web Services, Google Cloud Platform and others get a lot of hype these days, but they can be an inexpensive way to help cover your bases in the event of a disaster without spending huge sums of money on a secondary data center. Most of these providers have methods to allow you to store your backups directly in their systems and allow for scripted deployment of resources. While this may not meet the needs of every department, it can offer an affordable way to handle less critical systems, as well as a highly reliable option in case all else fails.

Test, Test, Test

Plans and documentation are important, but it’s even more important to test your disaster recovery process. This means simulating a disaster and testing the process used to make data accessible again. This will test the accessibility of your backed up data, any anomalies that occur when data is brought back up, the speed of the recovery and more. It also provides tremendous opportunities for learning and collaboration among departments. Newer hires can run through the process with senior folks supervising. Discuss where things commonly break down, why certain processes are necessary, and what can be done to speed things up.

Depending on the amount of data you have, you may choose to test portions of your data regularly and do one large-scale test of your entire system once a year. Either way, it’s important to have all the key employees involved in the testing process and to evaluate how well it works. That way, you can revise your plan accordingly.  

Have a Backup of Your Backups

No good disaster recovery plan is useful without some additional redundancy.  Sometimes this means taking a printed copy home with you. Sometimes it just means having it stored in more than one location, like on the company network and on Microsoft OneDrive, Google Drive or Dropbox, and accessible by key staff members.

Contact SQL Tailor Consulting Today

Whether you already have a detailed database disaster recovery plan, are just getting started or just need to hone your process, SQL Tailor Consulting can help. We have decades of experience with disaster recovery plan development and testing, so we can help tweak your existing plan or start from scratch if that’s what is needed. Give us a call at (248) 919-8086 for a free consultation.