Is Your Disaster Recovery Plan Prepared for an Ice Storm?

As the United States enters the winter months, large portions of the country can potentially be impacted by severe weather before Spring arrives. Heavy snowstorms that cripple the transportation system may be what immediately comes to mind. While a foot of snow is no joke to move aside, some of the most destructive winter weather events are ice storms. They pack a one-two punch that can result in devastating and long-term problems.

The problem with ice storms is that they affect transportation and driving conditions while also posing a greater risk of power outages than does a snowstorm. Freezing rain falls and accumulates on tree branches and power lines, often resulting in lengthy outages. Everywhere from Texas to Maine has been hit with a major ice storm in the past. It can be days or weeks before power is fully restored in the wake of a major ice storm. 

Do You Have a Disaster Recovery Plan?

The risk of ice storms and their associated power issues can make it hard for corporate executives to sleep at night. A viable disaster recovery plan should alleviate some of the concerns that lead to sleepless nights. The lack of a plan should be addressed immediately. Failure to do so risks losing your business to the unpredictability of the weather. 

A functional disaster recovery (DR) plan is made up of several equally important components and needs to be put together methodically. Let’s take a look at what is required to develop a DR plan that works when needed.

  1. Inventory hardware and software assets and prioritize them into recovery tiers. 
  2. Define the recovery time objective (RTO) and recovery point objective (RPO) for each system or tier. These values are determined based on your company’s tolerance for data loss and downtime. 
  3. Identify the personnel responsible for performing various actives during recovery and ensure that there are backups assigned for all critical roles.
  4. Create a communication plan that addresses contacting employees in the event of a disaster. It needs to provide information on where to go and how to access systems during a recovery.
  5. Make sure all SLAs with outsources such as cloud providers address disasters. 
  6. Determine how sensitive data will be handled during a disaster. The same stringent data privacy requirements need to be implemented during disaster recovery.
  7. Conduct regularly scheduled disaster recovery tests and use the results to make any necessary modifications to the plan. 

Disaster Recovery Testing Methodologies

Though it is the last entry in the list of necessary DR plan components, testing is one of the most critically important activities an organization can perform in preparation for disaster recovery. If the first time your team attempts to execute the plan is during a real disaster, your chances of success are substantially diminished. Testing should be a priority both to validate the current plan and make adjustments based on an evolving environment and results from previous tests.

There are five basic ways in which a disaster recovery plan can be tested. They are listed here in their order of complexity and their utility in ensuring the computing environment is adequately protected if a disaster strikes.

  • Paper test - This type of test involves the DR team reading, annotating, and verifying the policies and procedures that will be put in place when necessary.

  • Walk through test - Teams conducting a walk through test are expected to identify issues with the plan that need to be resolved.  This is essentially a deeper and more detailed paper test.

  • Simulation test - A simulation test allows teams to practice the steps of the plan in a realistic situation. These types of tests are often conducted by individual departments and are an excellent way to find and close gaps in the plan.

  • Parallel test - Recovery systems are tested during a parallel test while production systems continue to process work for the organization. This kind of test provides a true indication of the plan and can be used to verify or tailor RTOs and RPOs. 

  • Cutover test - A cutover test takes the final step and disconnects primary systems to ensure the test environment can handle the load. Organizations employing a cutover test need to be very confident in their plan and have thoroughly tested it in a parallel setting.

All enterprises should strive to conduct regular simulation or parallel tests at a minimum. The risks involved in a cutover test may be more of a gamble than some organizations want to take, but simply relying on paper and walk through tests can be a recipe for failure. No testing at all is not recommended. 

Recovery Requires Backups

Backups are a necessity when performing a disaster recovery. Infrastructure may be constructed from scratch to emulate production systems, but the same cannot be said for data resources. If you don’t have relevant data backups, your organization will take a hit even if all systems can be made operational. In many cases, different systems within the environment need to use dedicated backup tools to provide full data protection.

If your environment includes SQL Server databases, SQL Safe Backup is the right tool for keeping valuable data resources protected. Its advanced features significantly reduce the amount of time required to back up and restore SQL Servers. Compression and multi-threading help backups complete quickly and multiple recovery options are available including instant restore. 

Cutting-edge encryption protects data resources with a negligible performance degradation of less than 0.5%. Backup can be mirrored and integrated with enterprise storage for long-term retention to meet regulatory standards. The tool lets you define backup policies for your entire SQL Server environment and can be used to backup virtual cloud instances.

The inclusion of SQL Safe Backup in shops running SQL Server is a great addition to the recovery tools available to address a disaster. Make it a part of your DR plan and make sure you have tested its recovery functionality before faced with a real disaster scenario that puts your organization at risk. 

Anonymous