Implementing a Disaster Recovery Solution Can be as Easy as Flipping a Switch
The road to recovery is a journey that more organizations are embarking upon as they start to look beyond just successfully backing up their data and instead focus on cost-effectively recovering their business. Yet as organizations begin this journey, they find that that the road to recovery is strewn with obstacles and is neither well-traveled nor well-marked. This was the dilemma that recently confronted Dr. James Tu, the Information Security Officer at a real estate services company, who was seeking to carve out an affordable and workable enterprise-wide disaster recovery solution from an uneven landscape of replication products.
The impetus behind Tu's need to create a better disaster recovery and business continuity solution was predicated upon his company's needs to create new revenue streams as well as renew contracts with its existing clients. His company had existing DR contracts with IBM and Sungard so in the event something occurred at its primary data center the company had a location where it could recover its application. However those contracts only provided for 48 - 72 hour recoveries which no longer met its business requirements and it now wanted a solution that could ideally provide for recoveries in 4 hours or less.
To accomplish, Tu did a business analysis impact so he could begin to understand what sort of solution he needed. To arrive at the correct conclusion, he documented what kind of applications his company had in house, the financial impact that an outage would have on the organization and how well the current DR solution worked.
Once he had gathered this information, he determined that this was still not enough information to make a decision about what course of action he should take as he was missing a critical piece of information: the data change rates of the application. Without this data he could not appropriately size or budget for the LAN or WAN links between the primary and secondary sites that would carry the replicated data.
Adding to the complexity, his application servers used direct attached storage (DAS), network attached storage (NAS) and storage area networks (SANs). To capture the data change rates on all of these different servers, he needed a software tool that would non-disruptively capture all of that information and then someone who could help him interpret the data and make recommendations as to how to proceed.
To assist him in performing that task, he hired a consulting company that assisted him in performing the assessment. It brought in the software that collected the data they needed to understand the data change rates across all of the company's different type of application server so they could appropriately size the network infrastructure for replication.
Once Tu had this data, he set forth the following requirements in terms of selecting a solution that would serve as the DR highway for his company:
Due to all of these struggles, he re-evaluated his criteria for selecting products and decided to remove the requirement for the vendor to be a publicly traded company since there does not exist a great number of publicly traded companies that do replication. Having removed this requirement, he went back to the consulting firm and asked what new options this created for him. The consulting firm suggested he use the same software they used to collect the data change rates in his DR environment, InMage Systems' Scout.
It turns out that the software the consulting firm had installed on all of his application servers was a slightly scaled down version of InMage System's Scout called Profiler. It performed all of the preliminary steps necessary to replicate the data up to the point of replicating the data in order to collect the data necessary to do the assessment. However its replication features could be turned on by simply flipping a switch in the Profiler software that turned it into InMage Systems' fully functioning Scout replication software.
In part 2 of this 2-part series with Dr James Tu, Tu discusses some of the unexpected benefits his company realized from using Scout and how these new benefits contributed to cost-justifying the introduction of Scout into his environment.
The impetus behind Tu's need to create a better disaster recovery and business continuity solution was predicated upon his company's needs to create new revenue streams as well as renew contracts with its existing clients. His company had existing DR contracts with IBM and Sungard so in the event something occurred at its primary data center the company had a location where it could recover its application. However those contracts only provided for 48 - 72 hour recoveries which no longer met its business requirements and it now wanted a solution that could ideally provide for recoveries in 4 hours or less.
To accomplish, Tu did a business analysis impact so he could begin to understand what sort of solution he needed. To arrive at the correct conclusion, he documented what kind of applications his company had in house, the financial impact that an outage would have on the organization and how well the current DR solution worked.
Once he had gathered this information, he determined that this was still not enough information to make a decision about what course of action he should take as he was missing a critical piece of information: the data change rates of the application. Without this data he could not appropriately size or budget for the LAN or WAN links between the primary and secondary sites that would carry the replicated data.
Adding to the complexity, his application servers used direct attached storage (DAS), network attached storage (NAS) and storage area networks (SANs). To capture the data change rates on all of these different servers, he needed a software tool that would non-disruptively capture all of that information and then someone who could help him interpret the data and make recommendations as to how to proceed.
To assist him in performing that task, he hired a consulting company that assisted him in performing the assessment. It brought in the software that collected the data they needed to understand the data change rates across all of the company's different type of application server so they could appropriately size the network infrastructure for replication.
Once Tu had this data, he set forth the following requirements in terms of selecting a solution that would serve as the DR highway for his company:
- Had to be vendor neutral. Tu did not want to be tied to a specific hardware solution that was storage-centric.
- Had to be application independent. He could not afford to have a dedicated replication solution for each application in his enterprise either from a cost or management perspective.
- Could not be solely a file-based solution. Tu had to replicate all of the data on entire server volumes and only tracking changes at the file system level would not work.
- Preferred to use a company listed on the NASDAQ or NYSE. Since his company was a large company, he wanted to select a solution from a company that was financially viable.
Due to all of these struggles, he re-evaluated his criteria for selecting products and decided to remove the requirement for the vendor to be a publicly traded company since there does not exist a great number of publicly traded companies that do replication. Having removed this requirement, he went back to the consulting firm and asked what new options this created for him. The consulting firm suggested he use the same software they used to collect the data change rates in his DR environment, InMage Systems' Scout.
It turns out that the software the consulting firm had installed on all of his application servers was a slightly scaled down version of InMage System's Scout called Profiler. It performed all of the preliminary steps necessary to replicate the data up to the point of replicating the data in order to collect the data necessary to do the assessment. However its replication features could be turned on by simply flipping a switch in the Profiler software that turned it into InMage Systems' fully functioning Scout replication software.
In part 2 of this 2-part series with Dr James Tu, Tu discusses some of the unexpected benefits his company realized from using Scout and how these new benefits contributed to cost-justifying the introduction of Scout into his environment.
Leave a comment