Backup and Recovery: Planning for Hurricane Season

Jun 14, 2018 | Insights, Managed Services

Blog business continuity

Ensuring you have a backup and recovery plan in place before the season’s hurricanes hit is essential for companies worried about business continuity. The last thing you want is to permanently lose data, or to experience several hours or days of downtime due to a power outage. If you don’t already have a backup system in place, there’s no time like the present to get started. Read our blog post on choosing a backup strategy for more information on how to begin. If you have a backup strategy, keep reading to see if your plan is sufficient to properly restore your systems and applications in the event of a local disaster. Just because you regularly perform backups does not necessarily mean your systems will be properly restored when the time comes.

Understand Backup Locations
The first thing to consider is the location of your backups. Are they being backed up to a Gulf Coast or East Coast data center? If so, consider backing up your files to another data center that is further inland during hurricane season, or using a managed backup service or cloud provider (provided their data center is in a safe location). Consider that some backups may be stored in your primary data center while others are stored offsite in a safe location. Be sure to address these backups and re-route them during hurricane season, or at least have a plan to do so in the event a major storm is predicted to hit the area.

Put Someone in Charge
Put someone in charge of the backup and recovery process. The best way to ensure you have a cohesive plan is to give someone ownership of the overall process. If you don’t have a team that manages backup, and your organization manages a significant amount of data, consider contracting a managed backup service provider. Once your disaster recover backup plan is in place, make sure more than one person knows the recovery procedure and how to implement it, no matter how small your organization.

Create Documentation
Documenting your backup and recovery process is the best way to ensure your staff understands the process and knows how to recover data and in what order. Certain files and business processes will need to be available faster than others. If your company already has a backup system in place, you should know your Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for each application. Be sure these objectives are recorded within this documentation.

Also document which servers are backed up and at what interval so there isn’t any misunderstanding about protection levels or retention periods. You may follow different backup methods for different systems. For instance, some databases may be backed up to another data center location while certain VMs may be backed up in the cloud. On the other hand, the company may decide to use a comprehensive managed backup solution, such as Commvault, where all VMs, databases, applications, file servers, email and storage arrays can be backed up using the same tool.

Whatever the plan, make sure everyone who works on backup and recovery has access to this documentation and knows where to find it in the event of an incident. Review the documentation with any new team members.

Test Your Backup and Restore Plan
Testing your backup plan is the only way to ensure that files and applications can be properly restored, and it’s the only way to ensure you can meet your RTO for each application. Backup and restore testing should be conducted regularly. Some recommend testing applications on a monthly basis, but comprehensive testing should be done especially after an application has undergone significant changes, such as a major update or a large data import. When testing your backup plan for disaster recovery, simulate an outage at your coastal location. Bring servers and applications back online in the order of importance you have outlined in your documentation. The first time you test your backup plan, you are likely to experience some errors and/or not meet your RTO objectives for some applications. Record results, correct and retest until you get it right.