Business continuance (BC) and disaster recovery
- Information privacy, data protection and data retention are in the spotlight
- Any business is at risk, not just large enterprises
- The risks and threats to security, including cyber attacks
- Regulatory and compliance requirements (HIPAA, SOX, etc.) are increasing
- The amount of data and its value continues to grow.
- Data is being retained for longer periods of time and in more locations.
- More critical data exists outside of traditional mainframe environments.
- Time for recovery, restoration and restart continues to shrink if not already non-existent.
- Your entire business (e.g., all applications).
- Specific applications and business functions.
- Different types of data for a given application or location.
Understand what the applicable threats are to your system and categorize your applications, data and storage to enable the appropriate level of protection to counter those threats. Different applications and data have different threats and protection needs, thus requiring tiered data protection. Align the proper RTO and RPO to the specific business function, application, data and storage. Understand your data availability, accessibility and retention requirements, as well as their interdependencies upon other applications and technologies.
BC and DR storage related tips include:
- Leverage fault isolation to contain faults and prevent them from spreading into a rolling disaster resulting from a chain of events. This includes eliminating single points of failure and combing various data protection and availability techniques to achieve resiliency.
- Update your DR and BC plans, documentation and associated procedures on a regular basis as part of change control management.
- Communicating the aspects of the plan to the key people involved -- updates on their roles and responsibilities, who to contact when, how the plan will be invoked, as well as how to protect the plan and documents. These items need to be readily accessible to whomever needs them.
- Your documentation should include inventories of the assets (technology) you have, where they are located, how they are configured and who the applicable suppliers are. In addition, maintain information about software licenses and applicable software keys for technology that you may need to recover, restore and restart your environment.
- Leverage multiple techniques and technologies for a 'belt and suspenders' approach to BC and DR. For example, clustering combined with remote replication along with some form of backup technique. This could include leveraging disk-based backup to tiered storage combined with point-in-time copy and snapshots integrated with applications and database systems.
- Look at the overall RTO and RPO from a business, application, server and storage perspective as the true RTO and RPO are the same for all components, not just the time required to recover your storage.
- Distance is a friend and a foe of storage with respect to BC and DR. From a positive standpoint distance enables survivability and continued access to data. The downside is the cost penalty in terms of expense, performance and complexity.
- Data consistency and integrity is important so make sure that your data is copied intact and that it is still consistent and in the proper sequence.
- Test and audit your BC and DR plans, procedures, polices and implementations.
- Include your key partners, suppliers and customers as part of your plan.
Some additional suggested reading pertaining to BC and DR in general as well for storage include other SearchStorage tips and "The Resilient Enterprise" ISBN 0-9744578-0-9 (A community project including SearchStorage experts Evan Marcus and Greg Schulz); "Blue Prints for High Availability" (Wiley) ISBN 0471356018 by Evan Marcus and Hal Stern; "Resilient Storage Networks" (Elsevier) ISBN 1555583113 by Greg Schulz.
For more information:
About the author: Greg Schulz is senior analyst at the independent storage analysis and consulting firm StorageIO as well as author of "Resilient Storage Networks."
This was first published in January 2006