Disaster Recovery Failback - WST

Many financial institutions have developed extremely detailed disaster recovery (DR) / business continuity (BC) plans. Those plans normally outline the tasks that need to be completed, based on the specific type of disaster that occurred. Do you have a documented plan to return your IT infrastructure and operations back to your original site? That process is known as "failback."

Once the business has been recovered to the DR/BC site(s), you need to be diligently planning on restoring the infrastructure back to the production site(s). Be sure to thoroughly document any infrastructure changes made in the DR infrastructure that will have to be made in your replacement infrastructure. Since the failback won't be a surprise, you can really get into the details of the process and make the failback seamless to your business. You will likely have the luxury of time, which could allow you to make changes to your infrastructure architecture, such as moving from physical servers to a fully virtualized environment; moving from direct-attached storage to shared storage devices (SAN or NAS); or potentially moving some or all components to a cloud environment.

Typically, DR events are caused by hardware failure, Internet service provider failure, or a natural disaster (fire, flood, wind, or earthquake). Each of those scenarios will impact your failback process. For example, if you experienced a hardware failure, you'll have to ensure your timeline includes the time it takes to procure hardware and software licensing, build the new server(s), install all necessary components, test the servers, and test your failback processes. You'll also have the option to failback one server at a time or all servers at once.

Just as with disaster recovery plans, planning and testing are the key elements of successfully completing a failback process and returning to your normal business operations. Testing failback can induce significant risk. If technical testing isn't feasible, tabletop scenario discussions may provide a suitable testing alternative. Failback checklists can also be a useful tool to include within the DR plan.

Authored by: Bill Wallen, Security+