Bekker's Blog

Blog archive

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


  • Image of a futuristic maze

    The 2024 Microsoft Product Roadmap

    Everything Microsoft partners and IT pros need to know about major Microsoft product milestones this year.

  • SharePoint Embedded Becomes Generally Available

    After a six-month preview, SharePoint Embedded, an API-based version of SharePoint that developers and ISVs can use to embed Microsoft 365 capabilities into their apps, is now generally available.

  • Copilot in Microsoft 365 Getting Agents, Extensions and Team (Not Teams) Support

    Microsoft is adding more functionality to its Copilot AI assistant aimed at improving business collaboration, processes and workflows for Microsoft 365 users.

  • Microsoft Giving Startups Templates To Build AI Apps

    A new perk for businesses enrolled in the Microsoft for Startups Founders Hub program aims to fast-track their ability to build AI-powered applications.