I recently wrote a blog where I examined how implementations of disaster recovery (DR) might differ between SMBs and the enterprise. Before jumping into the DR fray, though, what is the first step that companies should consider before embarking on the route to a more resilient business infrastructure?
Management Buy-In Is Crucial
Many small and medium-sized businesses fail to realize that a key barrier to a successful SMB DR implementation is hardly about the technology, be it the hardware or software. The ability to create a robust architecture to survive natural disasters or large-scale failure has to start with what I personally term the "heartware." I define the heartware as the commitment of the management and senior executives to make the project happen.
Because aspects of implementing a robust DR strategy might entail a number of procedural or process changes, the less than enthusiastic cooperation from departments failing to see the big picture can severely limit the effectiveness of any DR plan.
As Michael Bilancieri, the senior director of products of Marathon Technologies Corporation noted, "One way to ensure your DR plan isn't fully implemented or isn't adequate is to try to do it without all the necessary parties on board and giving their full support." On the other hand, "Build[ing] a cross-functional team that can participate in defining and validating the [proposed] solutions" will go a long way to ensure that all DR requirements and objectives are met.
Establish DR Objectives Before Starting
Let's assume that the CEO and key stakeholders are firmly committed to implementing DR. What's next? What would be a key criterion for determining an optimal DR plan? On this front, Bilancieri advises SMBs to first identify what they need to accomplish, ahead of calling up any vendors.
While this piece of advice might seem intuitive, establishing objectives prior to starting is especially crucial from a DR point of view. This is because implementing incorrect or incomplete solutions can result in time and resources being completely wasted.
Objectives to define in advance include the recovery time objectives (RTO), which is the amount of time a specific application can be unavailable. Recovery point objectives (RPO), or the amount of data that can be lost when a recovery is required, should also be factored into the equation.
It is important to remember that the RTO and RPO values are likely to vary for different departments, or even between disparate applications within the same department. As such, it is imperative to first check with your users (or clients) to determine their requirements as well as any service level agreements or compliance laws that must be met.
Obviously, while I would consider the above two pointers to be of high importance, the challenges to implementing disaster recovery can vary greatly between SMBs. Where necessary, it might be prudent to consider the services of a consultant for organizations with complex or interrelating needs.