Analysis: The 3 Most Overlooked Business Continuity Steps

Business continuity is a huge and mature opportunity for the channel. Much of the selling process centers on technology questions and setup. Doing that part right is critical, but the opposite end of the process often gets overlooked.

Time and again, it's lack of attention to three final steps that leads to a data disaster when recovering from a physical disaster.

1. Scheduling a Full Disaster Rehearsal
Planning and installing a business continuity solution is time-intensive and exhausting. Once the system appears to be up and running, there's temptation on both the partner and customer sides of the deal to move on. The revenues are booked, and backups look like they're occurring correctly. This is no time to quit.

Bringing business systems back online is a complex process. Servers have startup dependencies that require other software to be loaded in the right order. Scripting the sequence can be tricky. No matter how thorough the planning, the customer may not realize a certain essential business database isn't covered until after a restoration. Every plan must be tested as completely as possible. Real-world disasters throw unique complexities into the system. Getting as many of the regular complexities as possible ironed out of the process beforehand frees partners and customers up to deal with only the novel issues that a real disaster might present.

Smart partners also know that getting a full business continuity system in place is an iterative process. Listing and addressing the issues that emerged in the disaster rehearsal is only part of the process. Running the disaster test again and again until no issues emerge is the end of the process.

2. Testing Fail-Back
If the test shows that the mission-critical application server fails over successfully to the backup server, that's an essential element of the business continuity solution. There's another critical piece that sometimes falls through the testing cracks. Will the system fail back to the original server gracefully without losing data the secondary system accumulated while it was handling the workload? It's important to not only consider, but also to test, how fail-back works. A key wrinkle is that the system might be returning to a production server that's no longer identical to the one that originally ran the system.

3. Scheduling the Next Test
The initial set of full-recovery rehearsals are absolutely critical. But they can't be the last rehearsals. In addition to ensuring that backups occur on schedule, it's important to develop a schedule to retest recovery scenarios at regular intervals. Things change fast in business. Server hardware gets replaced, business critical applications and databases get upgraded, important applications move in or out of the cloud. The business-continuity solution has to be retested to make sure it's still capturing the full current environment

Posted by Scott Bekker on March 05, 2013