it-Select-a-Best-Fit-DR-Solution-Phases-1-3

Info-Tech Research Group 1Info-Tech Research Group 1
Info-Tech Research Group, Inc. is a global leader in providing IT research and advice.
Info-Tech’s products and services combine actionable insight and relevant advice with
ready-to-use tools and templates that cover the full spectrum of IT concerns.
© 1997-2015 Info-Tech Research Group Inc.
Headline/SubheadVerticalSpacing
V4
Select a Best-Fit DR Solution
Evaluate deployment models from in-house or co-lo DR sites, to managed services, to cloud-
based DR in order to determine the best fit for your DR environment.

Table of contents
Understand the implications and possibilities of DR solutions
Blueprint and guided implementations overview
Project phases:
1. Conduct requirements gathering
2. Evaluate potential DR solutions
3. Design a best-fit DR strategy
Summary, related research, and references

Follow Info-Tech’s DR Solution Development Workflow to
determine your best-fit DR solution
This workflow enables you to determine a best-fit DR
solution from the use of in-house or co-lo DR sites to
managed services (e.g. DR service providers) to cloud-
based DR. The phases in this workflow are outlined below:
Click on this link to reference the DR Solution
Development Workflow.
Phase 1: Conduct Requirements Gathering
1. Review Planning Process
2. Business Impact Analysis
3. Risk Catalog
4. Current State SWOT Analysis
Phase 2: Evaluate DR Solutions
5. DR Solutions Overview
6. DR Solution Cost Models
7. Force Field Analysis
8. Decision Matrix
Phase 3: Determine and Communicate DR Solution
9. Example DR Solutions
10. Document the DR Solution
11. Executive Communication Tool
Call your account
manager to schedule a
Guided Implementation.

This Research is Designed For: This Research Will Help You:
This Research Will Assist: This Research Will Help You:
This Research Is Designed For: This Research Will Help You:
This Research Will Also Assist: This Research Will Help Them:
Determine an appropriate DR solution to meet your recovery
requirements and organizational constraints
IT infrastructure management and other senior
IT managers who are responsible for selecting
and implementing a DR solution.
Organizations that are trying to identify a
viable DR solution under resource constraints.
Organizations seeking to optimize or validate
an existing DR solution.
Conduct a thorough requirements gathering
process which balances cost and strategic
needs.
Evaluate a wide range of DR solutions and
identify pros/cons of each option.
Integrate key learning points from real-world
case studies and avoid common pitfalls.
Executives looking to be involved in the
planning and execution of a DR solution
selection.
Members of the BCM and crisis management
teams who need to incorporate the DR
solution into their own recovery processes.
Establish a process for selecting and
implementing long-term infrastructure projects.
Scope the requirements necessary to develop
a DR solution.

Resolution
Situation
Complication
Info-Tech Insight
Executive summary
• Your current DR solution does not meet business requirements – you
either lack a DR site or it is insufficient.
• You need to find a solution that balances budget and DR requirements.
• There is a wide range of DR options, from a co-lo site to managed DR
services, and it is difficult to find the best solution.
• The CEO is pushing cloud for DR, but you know many of your workloads
are not a good fit.
• Define a comprehensive set of requirements at the start of the project. DR solutions are long-term commitments, and
mistakes in planning will be amplified during implementation.
• Analyze the pro/cons of each DR option and identify a DR solution that balances your budget and DR requirements.
• Avoid common pitfalls by integrating key insights from a variety of organizations that have implemented a DR solution.
1. Balance budget and DR requirements
by finding the right mix of DR solutions.
For example, use a hybrid co-lo/IaaS to
reduce hardware costs while ensuring
appropriate capacity when needed.
2. Don’t assume cloud is cheaper. Cost
will depend on your specific workloads
and use case.
3. The cost of downtime is rising across
the board. Improve the resilience of
your organization with a best-fit DR
solution.

Info-TechInvolvementInfo-Tech offers various levels of support to best suit your
needs
DIY Toolkit
Guided
Implementation
Onsite
Workshop
Consulting
“Our team has already
made this critical
project a priority, and
we have the time and
capability, but some
guidance along the way
would be helpful.”
“Our team knows that
we need to fix a
process, but we need
assistance to
determine where to
focus. Some check-ins
along the way would
help keep us on track.”
“We need to hit the
ground running and
get this project kicked
off immediately. Our
team has the ability to
take this over once we
get a framework and
strategy in place.”
“Our team does not
have the time or the
knowledge to take this
project on. We need
assistance through the
entirety of this
project.”
Degree of Customization
Diagnostics and consistent methodologies throughout all four options

A pre-existing DR environment (e.g. a DR site) is critical to
reducing recovery time and the cost of downtime
If you don’t have a DR environment when failure occurs, expect to face weeks of downtime and
exponentially rising costs while you design and implement a solution.
The impact of downtime increases significantly over time, as illustrated for lost
revenue in the graph to the left. An existing DR solution (whether that’s a DR site
or cloud-based DR or both) that you can activate quickly is critical to minimizing
downtime and business impact.
If you do not have an existing DR solution, your organization is gambling on being
able to define and implement a recovery strategy during a time of crisis. At the
very least, this means extended downtime—potentially weeks or months—and
substantial business impact.
Potential Lost Revenue
Adapted from: Rothstein, Philip Jan. Disaster Recovery Testing: Exercising Your Contingency Plan (2007 Edition).
Delay in recovery causes exponential
revenue loss
Cost of Downtime for the Fortune 1000 Info-Tech Insight
The cost of downtime is rising across the
board, and not just for organizations that
traditionally depend on IT (e.g. E-commerce).
Downtime cost increase since 2010:
• Hospitality: 129% increase
• Transportation: 108% increase
• Media organizations: 104% increase
Cost of unplanned apps downtime per year: $1.25B to $2.5B
Cost of critical apps failure per hour: $500,000 to $1M
Cost of infrastructure failure per hour: $100,000
35% reported to have recovered within 12 hours.
17% of infrastructure failures took more than 24 hours to recover.
13% of application failures took more than 24 hours to recover.
Source: Elliot, Stephen. DevOps and the Cost of Downtime: Fortune 1000 Best Practice Metrics Quantified. IDC, 2015.

Understand the range of possible solutions for your DR
environment
This blueprint is designed to help you define your requirements and then select a solution that best
meets your requirements. Below is a sampling of possible DR solutions:
• In-House or Co-Lo DR Site: This is the traditional approach of setting up a secondary site that mirrors the primary site (at
least for critical applications).
• Mutual Aid Agreements / Reciprocal DR Sites:
◦ If you have two or more primary data centers (e.g. for two separate divisions), each location can function as a DR site
for the other, depending on available capacity. This saves the cost of building out a dedicated DR site.
◦ Similarly, two or more separate organizations (usually related – e.g. two colleges) can enter into the same type of
reciprocal DR agreement.
• Commodity Cloud-Based Solutions (i.e. using IaaS): Depending on your workloads and requirements, some or all of
your primary environment can be recovered to a commodity cloud-based environment such as AWS or MS Azure.
• Hybrid Co-Lo/IaaS Solutions: Leverage co-lo vendors that not only provide space and infrastructure for your physical
standby equipment, but also offer IaaS. This can reduce costs by limiting the amount of hardware that needs to be
deployed at the DR site.
• DR Service Providers: DR vendors that provide a DR site/environment, including hardware, and DR support services.
Depending on the vendor, they may also include options to leverage IaaS as part of your solution.
• Pure Cloud-Based DR / DRaaS: This ranges from configuring a DR environment in a public cloud using standard
offerings to leveraging vendors who offer managed DR services using an IaaS model.
Note: The term “DRaaS” is also used by some vendors to refer to their traditional DR services.
• Combined DR Solution: A combination of more than one solution may be required depending on your needs.

All DR solutions consist of one or more of the following
deployment models which vary based on the level of control
In-House DR Site IaaSCo-Lo DR Site
Managed/DR
Services Provider
Application
Virtual Machine
Server
Storage
Facilities
Application
Virtual Machine
Server
Storage
Facilities
Application
Virtual Machine
Server
Storage
Facilities
Application
Virtual Machine
Server
Storage
Facilities
Organization has
control
Organization and
vendor share control
Vendor has control
An effective DR solution can consist of a range of deployment models. Part of your decision criteria will
be the desired level of control in addition to cost and workload requirements.

Build your DR solution to address both minor and major
events to provide day-to-day service continuity
Large natural disasters grab headlines. However, your DR solution needs to also address more
common incidents such as hardware/software failures and network/power outages.
45% of service interruptions that went beyond
Maximum Downtime guidelines set by the business
were caused by software and hardware issues.
45% Total
Natural Disaster
5%7%
Building is
Inaccessible
(e.g. due to a
local hazard)
5%
Power Outage
18%
External
Network Failure
19%
Isolated
Hardware
Failure
21%
Software Failure
24%
CausesofUnacceptable
Downtime
Source: Info-
Tech Research
Group; N=87
Only 12% of incidents were caused by major
destructive events.
Does this mean I don’t need to worry about natural disasters? No. It means DR planning needs to focus
on overall service continuity, not just major disasters. If you ignore the more common, but less dramatic
causes of service interruptions, you will suffer the proverbial “death from a thousand cuts.”
Equipment
Damage (e.g.
due to fire, roof
collapse, etc.)
12% Total

Understand recovery point and recovery time terminology for
DR planning
• Recovery Point: Refers to how much data would
be lost if you had to revert to your backup data
(i.e. how old is your most recent backup?).
• Recovery Point Objective (RPO): Refers to the
organization’s maximum tolerance for data loss.
An RPO of 4 hours means you are committing to
ensuring that your most recent backup data is
never more than 4 hours old – i.e. running a
backup every 4 hours or less.
• Recovery Time: Refers to how long it takes to
restore IT services. If a server goes down and it
takes 30 minutes of troubleshooting and another
15 minutes to failover to a standby server, the
recovery time is 45 minutes.
• Recovery Time Objective (RTO): Refers to the
organization’s maximum tolerance for downtime.
An RTO of 4 hours means you have the
technology and processes in place to restore IT
services within 4 hours. The term “Maximum
Tolerable Outage (MTO)” is also used to refer to
the same general concept.
Last good image Data is back online/
app is up and running
Incident
weeks
days
hours
minutes
seconds
seconds
minutes
hours
days
weeks
RPO =
0 – 1 hr
RTO =
0 – 4 hrsTier 1 (Gold)
RPO =
1 – 4 hrs
RTO =
4 – 24 hrsTier 2 (Silver)
RPO =
4 – 24 hrs
RTO =
24 – 48 hrsTier 3 (Bronze)
Recovery TimeRecovery Point
Recovery Point and Recovery Time Examples
Disaster recovery timeline objectives are typically measured as Recovery Point Objective (RPO) and
Recovery Time Objective (RTO). These terms are described and illustrated below.

Your DR solution is a long-term commitment; define a
comprehensive set of requirements to get this decision right
Use this blueprint to clearly define your requirements, understand the available options, and select the best
fit that meets your requirements. Considerations that you will evaluate through this blueprint include:
Considerations Example
Recovery time requirements Do you need a hot, warm, or cold site?
Recovery point requirements Do you need synchronous or asynchronous replication?
Available budget What is your tolerance for both capital and operational costs?
Level of DR expertize To what extent do you need vendor assistance to manage and execute DR?
Organizational constraints
What is your organization’s readiness or tolerance for using cloud-based
services?
Risk exposure
What types of risks are you currently exposed to? Which ones are you willing to
tolerate, and which ones must be mitigated through a DR solution?
A DR solution will have both short and long-term impacts on your overall IT infrastructure. Make sure you do it right
the first time, and avoid headaches down the road.

Best-Practice
Toolkit
1.1 Determine the DR requirements of
critical applications through a BIA
analysis.
1.2 Determine risks and opportunities
of the current IT environment.
2.1 Analyze the benefits and
drawbacks of a variety of DR options.
2.2 Conduct a thorough cost analysis
for each DR option.
2.3 Identify how each DR option
impacts your organization.
2.4 Prioritize and rank each DR option.
3.1 Apply insights from case studies to
develop your own DR solution.
3.2 Document your DR solution.
3.3 Define the requirements for a
bulletproof DR solution.
3.4 Communicate the results of the
planning process to management.
Guided
Implementations
Call 1: Determine RTOs/RPOs for
processes and their dependencies.
Call 2: Assess the risks that your DR
solution needs to be able to mitigate.
Call 1: Overview of each DR option
and determine the Total Cost of
Ownership for each DR option.
Call 2: Conduct a Force Field
Analysis for each DR option.
Call 3: Prioritize and rank DR options.
Call 1: Integrate case study insights
and document your DR solution.
Call 2: Define the need and
requirements for a bulletproof DR
solution.
Call 3: Create the executive
communication deck.
Onsite
Workshop
Module 1:
Define requirements of the DR solution.
Module 2:
Evaluate potential DR solutions.
Module 3:
Design the best-fit DR strategy for your
organization.
Phase 1 Outcome:
• Identify a comprehensive set of
requirements for your DR solution.
Phase 2 Outcome:
• Evaluation of each option and
determination of the optimal solution.
Phase 3 Outcome:
• Design a DR solution that balances
cost and strategic needs.
1. Conduct requirements
gathering
2. Evaluate potential DR
solutions
3. Design a best-fit DR
strategy
Develop a best-fit DR solution – project overview

Pre-workshop Day 1 Day 2 Day 3 Day 4
Preparation Workshop Day Workshop Day Workshop Day Working Session
Workshop Preparation
• Gather current DRP
documentation.
• Determine available
resources for the DR
solutions project.
• If applicable, review
internal SLA between IT
and the business.
• Determine current
backup and recovery
process.
Morning Itinerary
• Discuss current need for
a DR solution.
• Review Business Impact
Analysis.
• Determine risk
scenarios to determine
risk-based requirements
for your DR solution.
Afternoon Itinerary
• Prioritize your risks in a
Risk Catalog and
analyze the rank results.
• Conduct a SWOT
analysis and discuss the
current state.
Morning Itinerary
• Discuss different DR
options and how it
applies to your
organization.
• Discuss Total Cost of
Ownership for each DR
option.
Afternoon Itinerary
• Conduct a Force Field
Analysis for in-house
and co-lo options.
• Document the
discussion points from
the previous discussions
in the Decision Matrix.
Morning Itinerary
• Complete a Force Field
Analysis for Managed
DR Services and IaaS.
• Complete the Decision
Matrix and review DR
solution ranking.
Afternoon Itinerary
• Review a variety of case
studies and identify
relevant insights.
• Document your DR
solution.
• Discuss the need for a
bullet-proof DR solution.
Workshop Debrief
• Conduct a final Cost of
Ownership analysis.
• Engage with
management and
discuss the results of the
workshop and the
thought process behind
the DR solution.
Next Steps
• Establish a vendor
management strategy or
determine data-center
build/renovate
requirements.
Workshop overview
This workshop can be deployed as either a four or five day engagement depending on the level of preparation completed by
the client prior to the facilitator arriving onsite.
The light blue slides at the end of each section highlight the key activities and exercises that will be
completed during the engagement with our analyst team.
Contact your account representative or email Workshops@InfoTech.com for more information.

PHASE
Conduct requirements gathering
1

Phase 1: Conduct requirements gathering
Evaluate potential DR
solutions
Design a best-fit DR
strategy
Phase 2: Phase 3:
Conduct requirements
gathering
Phase 1:

Phase 1 outline
Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-
3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.
Guided Implementation 1: Conduct a thorough requirements gathering process
Proposed Time to Completion (in weeks): 4 Weeks
Step 1.1: Business Impact Analysis Step 1.2: Requirements Gathering
Start with an analyst kick off call:
• Discuss the current DR solution and drivers behind the
project.
• Review BIA analysis and incorporate any necessary
updates.
Review findings with analyst:
• Discuss the risks that your current IT environment is
exposed to. These risks will become requirements of your
DR solution.
• Overview the SWOT Analysis process.
Then complete these activities…
• Review the current RTO and RPO needs of Tier 1
applications.
• Document the gaps between desired and achievable RTO
and RPO and Tier 1 applications.
• Conduct the Risk Scenarios exercise.
• Document the identified risks into the Risk Catalog.
• Conduct a SWOT analysis to establish the current state.
With these tools & templates:
DR Solution Risk Catalog
Phase 1 Results & Insights:
• Define the requirements of your DR solution based on a comprehensive analysis of your DR needs. DR solutions are long-term commitments;
make sure your planning process is comprehensive by following Info-Tech’s requirements gathering strategy.
Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

Start the process by identifying your key requirements
Refer to the DR Solution Development Workflow
for an expanded view.
Phase 1: DR solutions are long-
term commitments with high
switching costs. The resource, time,
and cost commitments need to be
carefully planned before execution.
Start by gathering a comprehensive
set of requirements to focus your
efforts on solutions that have the
best chance to meet your needs.
The first step in finding a best-fit DR solution is to
determine what my requirements are. I am not going
to start vendor research or anything else until I
determine what my needs are.
– Paul Kirvan, FBCI, CISA, Independent IT Consultant/Auditor,
Paul Kirvan Associates

Focus your DR solution planning by starting
with Tier 1 applications
Your DR solution needs to be able to prioritize and protect your Tier 1 applications first. Identify
your Tier 1 applications/systems through a comprehensive BIA analysis.
Follow these high-level steps to determine your Tier 1 applications:
1. Identify applications and dependencies to be assessed.
2. Define the scales that will be used to measure criticality, business impact, and risk.
3. Determine the impact of downtime and define desired and achievable RTOs/RPOs.
4. Based on the above analysis, determine which applications are Tier 1, Tier 2, Tier 3, or Tier 4.
5. Review RTO and RPO gaps (the gap between desired and achievable) to determine which applications
are currently not meeting the desired standards and need to be prioritized in the DR solution.
Use the following BIA tool DRP Business Impact Analysis Tool which is described in more detail in the
blueprint Create a Right-Sized Disaster Recovery Plan.
DRP Business Impact Analysis Tool
Once you have gone through the DR solution planning process for Tier 1 applications, you can apply the same
methodology for Tier 2 and 3 applications. In this second iteration, consider integrating the less critical
applications into your Tier 1 DR solution or create a new environment that is more appropriate.
1.1: Business
Impact
Analysis

Review risk considerations for your primary site to
determine risk-based requirements for your DR solution
Establish Risk Scenarios
Identify risk considerations for your primary site that will also need to be
considered for your DR solution. This includes:
• Areas of low risk tolerance. For example, in organizations dealing
with sensitive data, there is low tolerance for risk of security breaches
or data leakage. Solutions that promise higher levels of security will be
required.
• Areas of existing or potential risk. For example, if your IT
department struggles with maintaining consistent IT operations in your
primary site, can they maintain an external site and keep it in sync?
• Location-based risks. For example, if you are located in an area
where natural disasters occur with some regularity, this will affect the
location of your DR site.
Purpose of this Activity
Timeline for this activity Duration: 4~6 hours Level of difficulty: Medium
Activity Outputs
 1.2: Establish Risk Scenarios and Events • Risk Catalogue (Prioritized list of Risk Events, which will
act as selection criteria for your DR solution)
Prepare risk scenarios and
proper courses of action?
Yes, in terms of disaster
recovery, twice a year (and)
look at nature, power, and
also cyber aspects.
- Glenn Poplawski, Service
Portfolio Director, State of
North Carolina, Office of
Information Technology
Services
1.2:
Requirement
Gathering

• Vendor selection
• Vendor management
• Contract termination
Level set on the terminology for the Risk Scenario
exercise
These are terms that will show up throughout the exercises. As a group, ensure
everyone understands each definition.
Risk Scenario: Distinct from a risk event, a scenario is an abstract profile of
risk. It represents a common group of risks. For example, you can group certain
types of risks under the Risk Scenario of IT Operations Risks.
Risk Event: Specific risk situations that fall under a particular Risk Scenario. For
example, a hurricane hits your organization. That is a Risk Event that falls under the
Risk Scenario of Acts of Nature.
VendorRelations
Risk
The next page shows Risk
Scenarios and the Risk
Events that can fall under
them.
Risk Scenario Risk Events
Example:
1.2:
Requirement
Gathering

Ensure that your DR solution mitigates areas of high
risk and impact through a targeted risk catalog
• Hardware maintenance errors
• Software maintenance errors
• Capacity planning errors
• Operational errors
The Risk Scenario headings are in blue, with examples of Risk Events in the grey boxes. Beneath each,
write the examples you determine as a group (some are featured here).
IT Operations Risks
• Vendor selection
• Vendor management
• Contract termination
• Acts of nature (hurricane, etc.)
• Fiber network performance
• Political and social stability
• Regulatory compliance
• Data sensitivity
• Externally originated attacks
• Internally originated attacks
Vendor Relations RisksRegional Risks
Compliance & Security
Risks
Establish Risk Scenarios: Each scenario should take approx. 30-45 minutes
1.2:
Requirement
Gathering
During my requirements gathering process, we were looking for a DR
solution that wasn’t exposed to the same vulnerabilities as our primary
data center. Our primary site was in a high-rise on an aging power grid,
did not have emergency power, and it was also exposed to potential water
supply and cooling issues. Our DR solution could not be exposed in the
same way.
- Steve Tower, Management Consultant, Steve Tower, Disaster Recovery
Plans & Assessments

Identify risk scenarios and establish risk
considerations for your DR solution
How this exercise should look in practice:
Note: Some
of these labels
differ from the
ones used in
the Risk
Catalogue.
This is an
example
taken from a
beta
workshop and
the Risk
Scenario
labels have
since
changed.
Remind participants that these risk scenarios and their subsequent
examples will be used in an upcoming tool that will allow them to create
their risk profile. Keep tying it back to the real reason they’re
brainstorming all of these examples, besides just getting into the right
frame of mind for the workshop.
1.2:
Requirement
Gathering
Info-Tech Insight
Consider each risk as a
site-wide incident which
will cause you to activate
your DR solution. The
risk catalog is designed
to identify key risks and
be considered when you
are developing your
requirements.
Draw on the
information from your
introduction
discussion to
anticipate some
examples that will
help get the group
thinking in the right
direction.
Image source: Info-Tech
Research Group

Populate the Risk Catalog and determine your
criteria priority for selecting a DR solution
Follow these steps to populate the DR Solution Risk Catalog:
1. Review the “Scoring Criteria” tab and verify that the descriptions are consistent with the DR
methodology of your organization.
2. On the “Risk Scoring” tab, document the Risk Event and Risk Scenarios from the “Establish Risk
Scenarios Activity” that you just completed.
3. For each identified risk, provide a score between 0-4 for the “likelihood of risk” occurring. Base your
scoring on the “Scoring Criteria” tab.
4. For each identified risk, provide a score between 0-4 for the “threat of risk” occurring. Base your
scoring on the “Scoring Criteria” tab.
DR Solution Risk Catalog
Results Analysis
• Every risk that is identified as having both high likelihood as well as high threat needs to be the focus of your DR
strategy. Your DR solution needs to directly address each of these risks by either mitigating or avoiding them.
o E.g. If your organization is likely to experience natural disasters and cannot tolerate them, then that
means your DR site needs to be in a distant location that is not susceptible to the same regional risks.
• For the remaining risks, make sure that stakeholders are aware of them. Discuss the necessity of mitigating the
risks based on business need and cost/benefit.
o E.g. The impact of a political uprising can be devastating; however, your location is extremely politically
stable. There is a low need to protect against this threat.
1.2:
Requirement
Gathering

Evaluate the current state of your DR environment by
conducting a SWOT Analysis
Discuss characteristics of your current DR solution that will
inhibit your ability to improve resiliency. Brainstorm how
these weaknesses will inhibit project goals.
• E.g. Currently, our IT infrastructure is heavily dependent
on non-commodity hardware. As a result, this limits the
potential DR solutions that are available to us.
• E.g. IT-Business alignment has consistently been weak in
our organization, and getting executive buy-in is difficult.
Weaknesses
Summarize and discuss the results of the risk analysis. Are
there any risks that deserve special attention? Which risks
are the most relevant and require immediate attention?
• E.g. Our organization is not tolerant of a regional disaster;
however, our current DR site is in such a close vicinity that
it does not protect our organization against regional risk.
• E.g. Data integrity has been an issue in the past, and data
loss cannot be tolerated.
Threats
Discuss characteristics of your current DR solution that will
promote your ability to improve resiliency. Brainstorm how
these strengths can help you achieve project goals.
• E.g. Your IT personnel is extremely skilled and is capable
of managing a wide variety of DR sites.
• E.g. Your DRP documentation is very comprehensive and
regular updates are made to the documentation.
Strengths
Brainstorm ways in which you can improve your current DR
environment. Try to discuss a wide range of options,
regardless of constraints such as budget.
• E.g. After outsourcing the majority of our data center to a
co-lo, there is now additional space in our production
facility that can be repurposed to act as the DR site.
• E.g. Our environment is highly virtualized, which makes it
a good fit for cloud solutions.
Opportunities
Conduct a SWOT Analysis – Duration: 1 hour
1.2:
Requirement
Gathering

Situation Design Takeaways
• A global manufacturing firm
recently completed its project of
building a Tier 3 data center to
act as its primary data center.
• Its data center and its
manufacturing environment is in
the same location.
• Next on the roadmap, it plans on
building a similar data center 30
miles away. This data center will
be the secondary site, which will
act as its DR solution.
• The firm is heavily reliant on its IT
systems. If the systems are down,
it can no longer manufacture.
• The firm designed the secondary
site to be close to its primary
since its applications demanded
for extremely low RTOs/RPOs. It
needed to be able to failover and
recover with near zero downtime.
• Its DR solution is built for service
continuity. If a regional event
occurs, both the manufacturing
environment as well as the DR
site can be down. In such a
scenario, extended downtime is
expected.
• The manufacturing firm arrived at
the conclusion that it was very
tolerant of regional disasters; if its
manufacturing facility was
impacted, then it does not matter
if IT capabilities are recovered.
• In addition, the close proximity of
the data centers allows the firm to
achieve synchronous replication
and satisfy its needs for near zero
RTO/RPO.
• A thorough understanding of your
requirements is critical to
selecting the best-fit DR solution.
A global manufacturing firm decides that it is highly tolerant
of regional disasters
CASE STUDY
Industry
Area Served
Manufacturing
Worldwide

Determine whether your DR solution needs to be
bulletproof based on downtime tolerance
If the conclusion from your analysis indicates that your systems cannot afford downtime, then
consider an end-to-end solution to maximize availability for mission critical systems.
It cannot be emphasised enough that a bulletproof solution is not meant for everyone. Not only are the costs
to implement normally very high, but exit costs/switching costs will also be prohibitive. The decision to pursue
bulletproof needs to be based on a comprehensive understanding of the business impact of downtime.
What is Bulletproof?
The decision for a bulletproof DR strategy will dictate the high-level configuration of your DR solution. Bulletproof will
also influence the level of redundancy within each data center.
Configuration: The configuration of your DR solution (e.g. a bulletproof strategy may have 2 DR sites: one nearby
site for high availability and another distant DR site for regional events.) A bulletproof configuration will protect your
organization against all possible threats from the Risk Catalog.
Data Center Redundancy: The level of redundancy in each data center (e.g. a bulletproof DR strategy at a minimum
leverages Tier 3 data centers, with Tier 4 data centers being ideal). Tier 4 data centers will have multiple distribution
paths and fully fault-tolerant components. This level of redundancy is capable of mitigating many of the service
continuity issues that can cause downtime.
1.2:
Requirement
Gathering

Situation
• Its primary IT environment includes:
o A small in-house data center with File & Print servers and non-critical Virtual Machines
(VMs) to support clothing design tasks, as well as network infrastructure to enable
access to its cloud-based systems. It also has a legacy Unix system that will soon be
phased out, so it is not being considered for DR (it should be phased out in another
month; less than 5% is still on Unix).
o A hybrid co-lo/cloud vendor that hosts its finance and administration systems (it’s fully
virtualized, and running on VMware).
o Amazon Web Services (AWS) is used to host its ERP, Warehouse Management System
(WMS), and Analytics/BI site.
• There was no DR site or DR environment at the start of this project.
Mamiye Brothers, Inc. determined its DR solution requirements
based on risk tolerance, business impact, and budget limitations
CASE STUDY
Industry
Headquarters
Mid-sized clothing designer and manufacturer
New York City
Continue
onto the next
slide

Action Takeaways
• The organization conducted a business
impact analysis to determine its tolerance
for extended downtime.
• The BIA identified that the organization’s
ERP, WMS, and Finance systems were
mission critical.
• The BIA also established a target RTO of
2 hours for its ERP, WMS, and Finance
systems, and 8 hours for remaining
mission critical systems.
• In addition, regional disasters are a
concern, especially since Hurricane
Sandy, as well as more common events
such as power and network outages and
hardware failures.
• Through the current state assessment
methodology, the organization was able
to clearly articulate its DR requirements.
The DR site had to satisfy the following
criteria to be considered viable:
o Low cost due to budget
considerations.
o Capable of protecting against
regional events.
o Able to meet RTOs for critical
systems (near-zero downtime /
high availability is not
necessary).
CASE STUDY
Industry
Headquarters
New York City
Mamiye Brothers, Inc. determined its DR solution requirements
based on risk tolerance, business impact, and budget limitations

The following are sample activities that will be conducted by Info-Tech analysts with your team:
Book a workshop with our Info-Tech analysts:
If you want additional support, have our analysts guide
you through this phase as part of an Info-Tech workshop
1.1
1.2
• To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-
Tech analyst team.
• Info-Tech analysts will join you and your team onsite at your location or welcome you to
Info-Tech’s historic Toronto office to participate in an innovative onsite workshop.
• Contact your account manager (www.infotech.com/account), or email
Workshops@InfoTech.com for more information.
Determine which of your applications are Tier 1, 2, or 3. Define the RTO and RPO
requirements for each application, and evaluate whether your current DRP is
sufficient in meeting the needs of the business.
Conduct a Business Impact Analysis
Conduct a risk scenarios exercise where you identify the relevant risks to your
primary site. These risks will become considerations for your DR site. This includes
areas of low risk tolerance, areas of existing or potential risk, and location-based risk.
Establish risk scenarios and create a risk catalog

PHASE
Evaluate potential DR solutions
2

Phase 2: Evaluate potential DR solutions
solutions
strategy
Phase 2: Phase 3:
gathering
Phase 1:

Phase 2 outline
Guided Implementation 2: Evaluate potential DR solutions
Proposed Time to Completion (in weeks): 3 weeks
Step 2.1: Overview and TCO Step 2.2: Force Field Analysis Step 2.3: Decision Matrix
• Overview each DR solution with
pros/cons and use cases.
• Discuss TCO Models and how to
create your own TCO model.
• Review the results of the overview
and TCO analysis.
• Identify key areas of concern to
work through in the Force Field
Analysis.
Finalize phase deliverable:
• Analyze the results of the Force Field
Analysis.
• Interpret the results of the DR
Solution Decision Matrix.
• Document the Total Cost of
Ownership for each DR solution
based on the needs of your
organization.
• Conduct a Force Field Analysis for
each DR solution.
• Walk through a hotwash at the end
of the exercise and review key
insights.
• Document the results of the Force
Field Analysis into the Decision
Matrix.
• Analyze the heat maps of each DR
solution.
DR Solution TCO Comparison Tool
DR Solution Force Field Analysis
Examples
DR Solution Decision Matrix
• Evaluate the compatibility of each DR solution from a variety of perspectives. Determine the best fit DR solution based on a Force Field
Analysis as well as a Decision Matrix.

Review the pros and cons of different deployment models with
respect to DR solutions
Use our DR Solution Development Workflow.
This section will review key considerations for each
deployment model:
• In-House DR Site: Setting up a DR site in one of
your own facilities.
• Co-Lo DR Site (including hybrid co-lo/IaaS
solutions): Using a co-lo vendor for your DR site.
If you use a co-lo vendor who also offers IaaS,
then you can also leverage a hybrid solution that
includes on-premise servers/storage plus IaaS for
additional capacity when needed.
• Managed Services – specifically vendors
offering DR services: Leverage the vendor’s
facility, hardware, and DR expertise to set up a
DR site.
• IaaS: Leverage commodity cloud (e.g. AWS) or
enterprise cloud vendors (i.e. co-lo vendors
offering IaaS) to set up a DR environment
primarily using IaaS.

Cons
Pros
Compare the pros and cons of an in-house DR site
The trend of infrastructure outsourcing will continue. However, an in-house DR site may still be a good fit depending on your
current available facilities and required level of control.
• Complete control: Location, plant layout, hardware, software, processes, vendors, etc.
• Guaranteed capacity: There’s no risk of oversubscribed services as you might incur when using a vendor’s facility.
• Less vendor management: While outsourcing can save on facility costs, it does require due diligence around vendor
selection as well as ongoing vendor management. An in-house DR site avoids that potential challenge, at least with
respect to facility vendor management.
• Capital investment: If you have to build a new data center for DR, it’s hard to justify this expense when there are cheaper
alternatives.
• Operating cost: If you are using an existing facility, capex impact is lower. However, you will still incur facility and staffing
costs to maintain your DR site.
• Facility management: In addition to the cost of maintaining the facility, also consider the effort, time, and attention you
need to spend on operating a second site—especially if it’s only used for DR and is otherwise an idle site. You don’t have
the potential challenges of vendor management, but you also aren’t able to offload facility management.
As organizations continue to outsource infrastructure, there’s an opportunity to reclaim in-house data center
facilities for DR. The facility and core infrastructure already exists, so this can be cheaper than using a co-lo
vendor for your DR site, and you get the “control” benefits of an in-house solution. In effect, your outsourced
environment (e.g. a co-lo site) becomes your primary site, and your in-house data center becomes your DR site.
2.1: DR
Solution
Evaluation

Explore options to utilize your in-house data center
for day-to-day operations and avoid idle time
An in-house DR site that sits idly is difficult to justify and you run the risk of the site falling out of
sync with your primary site. Below are two approaches to better utilize the DR site.
• Increase your utilization of your DR
environment by using it for testing and
development.
• In effect, you reduce the capex and opex that
would have been spent on test/dev systems
in your primary environment, which helps
offset the cost of your DR site.
• In addition, since your systems are not sitting
idly at your DR site, you can have better
confidence that those systems are functional,
and they are more likely to be kept up to
date.
Set up a DR site that can also be utilized for
testing and development
• Typically this solution is used when an
organization needs high availability:
o You are essentially operating a load-
balanced environment.
o Each location operates under 50%
capacity.
o If one site fails, the other can take on the
full workload if necessary.
• The organization can have much greater
confidence in its DR site since it is, in fact,
running in production mode all the time.
• This solution also reduces downtime for
maintenance, since you can intentionally take
one site down at a time to perform
maintenance activities while the other site
stays in service.
Split workloads between primary and
secondary sites
2.1: DR
Solution
Evaluation

Cons
Pros
Compare the pros and cons of a co-lo DR site
• More robust network and facility infrastructure: A co-lo vendor typically will have much greater network and power
redundancy than an in-house data center. Ensuring uptime is critical to their business. They can leverage economies of
scale to invest in greater redundancy.
• Potential for hybrid co-lo/IaaS solution: If the vendor offers IaaS, you can reduce hardware costs by using a mix of on-
premise equipment where this is the best fit plus IaaS for additional capacity when needed, rather than replicating your full
primary site’s environment.
• Reduced facility costs: The co-lo option can save facility capex and opex costs compared to an in-house DR site.
• Limited control and access: Access must be scheduled – for example, to deploy new equipment or conduct testing.
• Vendor management challenges: An outsourcing vendor is in effect an extension of your IT operations team. To avoid
surprises such as vendor maintenance that inadvertently results in downtime, you will need to maintain a close working
relationship to keep both parties informed of any activities that may affect IT operations.
• Vendor SLAs that are not comprehensive: Vendor SLAs often focus on availability/uptime and don't include a well-
rounded set of metrics to assess overall service, such as frequency of outages and downtime for maintenance. You will
need to keep your own metrics to assess service levels as well as validate performance reports provided by the vendor.
Understand that when you outsource, you trade control for benefits such as greater redundancy. Review and
adjust processes where agility is an issue. For example, provisioning might require more lead time and planning
with the vendor. Conversely, forcing vendors to expedite their processes could impact reliability.
A co-lo site trades facility control for facility cost savings. Below are more pros and cons to consider.
2.1: DR
Solution
Evaluation

Leverage a co-lo solution to retain control without
the facility capex and opex overhead
Within the co-lo market, there is a range of services available from just renting facility space (with possibly some basic IT
maintenance services) to vendors that offer co-lo services plus IaaS and possibly some level of managed services. The
examples below illustrate this range.
Of organizations, 42% are not satisfied with their outsourcing arrangement. Typically, a minimum of three months
of planning and due diligence is necessary to ensure your outsourcing arrangements meet your expectations.
Don’t rush this decision. Follow the process outlined in Info-Tech’s blueprint Outsource IT Infrastructure to
Improve System Availability, Reliability, and Recovery.
• You deploy and control server/storage hardware,
while the co-lo vendor manages the facility including
network, power, and cooling infrastructure.
• You conduct hardware maintenance and application
administration remotely from your primary site.
• Depending on the vendor and your agreement, you
may be able to leverage the vendor’s staff for basic
hardware maintenance tasks that must be done
onsite.
• In a disaster scenario, you may need to travel to the
co-lo site to execute recovery procedures, depending
on your setup.
Pure co-lo solution with basic services
• Optimize your deployment to reduce hardware costs.
For example:
o Deploy hardware for storage and mission critical
systems that require near-zero RTO.
o Pre-configure VMs to leverage the vendor’s IaaS
for workloads that are a good fit for IaaS. Those
VMs are activated only when needed.
o Your hardware footprint is much smaller, so costs
are reduced.
o Commodity Cloud (e.g. AWS) potential issues
such as latency are not an issue because the IaaS
environment is in the same facility. In addition,
more direct vendor support is available.
Hybrid co-lo/IaaS solution
2.1: DR
Solution
Evaluation

Cons
Pros
Compare the pros and cons of Managed Services
– specifically DR Service Providers
DR service vendors can provide a DR site, hardware, and expertise – a good option for organizations that don’t have the
expertise or resources to set up their own DR solution.
• More robust network and facility infrastructure: As with a co-lo vendor, the DR Service Provider’s facilities will have
much greater network and power redundancy than an in-house data center.
• Quicker deployment: You are using the vendor’s facility, hardware, and expertise, minimizing the time required to build
out your own DR solution.
• DR experience: You can leverage the vendor’s experience to help you plan your DR solution.
• Cost: Using a DR service provider is typically more expensive over time than setting your own DR solution using options
such as a hybrid co-lo/IaaS vendor. You are paying for managed services as well as the use of their facility and hardware.
• Limits to duration of use: There is often a limit to how long you can use the DR facility, or conversely surcharged
depending on the length of stay, adding significant costs if the damage to your primary site is longer-term.
• Limited access for testing: Depending on the agreement, you might be limited to one annual test.
The lines have been blurred between traditional DR vendors (e.g. SunGard) and co-lo/MSP vendors who have
added DR services to their offerings. Be aware that there is a wide range of support, experience, and capabilities,
so exercise due diligence when evaluating DR services.
2.1: DR
Solution
Evaluation

Understand the spectrum of vendors offering DR
services
The level of services can range from vendor support to execute DR (i.e. so you don’t have to travel to the DR site for
any hands-on work) to full DR support (provides the DR site, hardware, and DR expertise).
• Vendors that started as a co-lo/MSP vendor and
added DR support as a supplementary service.
o The co-lo/MSP vendor will market similar
types of services as a Traditional DR vendor.
However, not all services are created equal.
E.g. DR services from co-lo/MSP vendors
usually require more involvement from your
own team. It is rare for a co-lo/MSP vendor to
completely manage and execute your DR.
• Price should not be your only consideration when
evaluating the DR service providers. Make sure all
your services are documented in an SLA and test
the solution regularly to verify capabilities.
Co-lo/MSP vendors that are now offering
DR services
Use of a DR services vendor does not need to be all or nothing. For example, organizations running non-
commodity hardware (e.g. mainframes) might use a DR vendor such as SunGard or IBM who can support non-
commodity hardware but use other cheaper DR solutions for their commodity hardware environment—from the
same vendor if they have a range of offerings or from other vendors.
• Vendors such as SunGard started as DR vendors
and can offer full DR support that includes:
o Hosting your DR site.
o Servers/equipment that you lease for DR.
o DR consulting services (including planning
your DR to executing DR).
• Traditional DR vendors are very experienced and
capable of offering comprehensive and reliable
service. However, be prepared to pay for the added
reliability.
Traditional DR vendors
2.1: DR
Solution
Evaluation

Compare the pros and cons of using IaaS for DR
IaaS through either a Commodity Cloud or Enterprise Cloud vendor provides your organization with
recovery capability on an “as needed” basis. Below are some pros and cons to consider.
• On-demand: Using the cloud means that you don’t have to maintain redundant infrastructure that sits
idle most of the time. You only pay the provider for when you use their services.
• DR testing: By automating the disaster recovery process, DR testing becomes significantly easier to
provision and execute since it can be performed non-disruptively.
• Contract flexibility: Relative to traditional outsourced DR models, cloud DR contracts offer more
flexible terms and less time-based contract restrictions.
• Performance: Every cloud provider is not created equally. While large providers may be able to
consistently meet your DR needs, smaller providers may struggle under certain situations. Consider a
regional disaster: many clients will be demanding recovery of their applications and the small
provider’s compute resources will be heavily strained.
• Workload discriminant: Oftentimes, if your organization is still dependent on legacy applications,
then it may not work in today’s cloud architecture.
Pros
Cons
2.1: DR
Solution
Evaluation

Understand the range of cloud-based DR and IaaS
options
The level of services can range from fully do-it-yourself (commodity) to a white-glove support package which
includes full support from the vendor in setting up your cloud environment (enterprise).
• A commodity cloud provides cloud computing
capabilities by leveraging “one-size-fits-all”
commodity infrastructure.
• A commodity cloud is suitable for
organizations that have technical engineers
who are capable of deploying and managing
the cloud with minimal support from the
vendor.
• Due to the multi-tenant nature of this
environment, issues such as security will
often be exasperated.
• On the other hand, the cost of a commodity
cloud will often be lower than the enterprise
cloud.
Commodity Cloud
• An enterprise cloud provider will help you
deploy and manage your cloud solution.
• Organizations who lack the internal expertise
to execute a cloud-based DR solution should
consider the enterprise cloud as the vendors
will offer more support.
• Due to the customized nature of this solution,
it is a good fit for organizations who want to
leverage the cloud but still retain some
ownership and control of the type of
infrastructure that they are using.
• The cost of enterprise cloud is normally
higher than commodity cloud.
Enterprise Cloud
2.1: DR
Solution
Evaluation

Situation Result Takeaways
• Amazon Web Services (AWS),
one of the world’s largest cloud
providers, experienced 59
minutes of downtime on August
25th 2013.
• The cause of the outage was due
to connectivity issues in the US-
EAST-1 region.
• This region was one of the most
used regions due to its
competitive pricing.
• While the outage was only 59
minutes long, it had affected a
number of organizations who
relied on AWS. The list includes:
o Vine
o Instagram
o Airbnb
o Flipboard
• Outages similar to this have
shown to have tremendous
financial cost. For example, the
August 19th 2013 AWS and
Amazon.com outage was
estimated to cost $1,100 in net
sales per second.
• When you outsource your IT
infrastructure, you are still
responsible for your own DR
capabilities. Do not assume that
your vendor will take care of you
during a disaster.
• In recent years, cloud vendors
have shown significant
improvement in their ability to
maintain uptimes. However,
outages will still occur, and it is in
your best interest to acknowledge
the possibility of downtime and
plan accordingly.
Outsourcing does not guarantee zero downtime; have a plan
for when your vendor goes down
CASE STUDY
Company
Area Served
Amazon Web Services (AWS)
Worldwide
Source: zdnet, Amazon Web Services suffers outage, takes down Vine, Instagram, others with it

Disentangle the security stigma of the public cloud
Security is often cited as the number one concern for many organizations against using the public
cloud. However, should this concern prevent your firm from using the cloud for DR?
Organizations are constantly talking about security concerns of the public cloud. However, recent surveys
suggest that the majority of cloud providers’ controls are as good if not better than your in-house solution.
Info-Tech Insight
The decision to use the public cloud needs to ultimately come back to finding a solution that fits your organization’s needs.
If your organization believes that security is a critical concern, then do not leverage the cloud for your most sensitive data.
Place non-business sensitive data onto the cloud to enjoy its benefits, while providing a more secure platform for your
most sensitive data.
Security should definitely be an item of discussion with vendors as you are going through the RFP process.
Include it in your Service Level Agreements so that you can ensure Cloud providers are constantly improving
their security capabilities. In many cases, the provider has more stringent security controls than you do
internally. For example, providers such as Amazon Web Services recently became compliant to FedRAMP
security standards. Learn more about cloud security in an IaaS environment in Info-Tech’s Ensure Cloud
Security in IaaS and PaaS Environments blueprint.
Make sure to discuss security with your vendor
2.1: DR
Solution
Evaluation

Understand when it is appropriate to leverage
a public cloud for DR
While there are many benefits of a cloud-based DR solution, not everyone can or should leverage it.
• Consider cloud if:
◦ Your applications are already virtualized and running from consolidated storage.
◦ You are not capable of provisioning for an in-house or co-lo site due to capital constraints.
◦ You only need to back up and restore a relatively small amount of data.
◦ Your network is capable of supporting your cloud solution.
• Small to medium companies tend to benefit most from a cloud solution. Over 85% of DRaaS customers are
SMBs with only 3~6 production applications, 5~60 VMs, and under 10TB total storage.
Verify whether your organization is ready for the cloud
• Not all applications are suitable for the cloud. Verify and evaluate the readiness of
each service. Refer to the Evaluate Opportunities and Cloud Readiness slide deck
from Info-Tech’s Cloud Strategy blueprint for further guidance.
• Determine cloud readiness for each application. Complete the Cloud Readiness and
Service Value Workbook in the Cloud Strategy blueprint to determine which
applications are appropriate for the cloud.
Info-Tech Insight
While there are potential cost
saving opportunities, do not
assume that the public cloud is
cheaper. Depending on how
much data you store, it can cost
you more than other options.
2.1: DR
Solution
Evaluation
Our systems were very unique, and no one else was managing anything else like it. There was no price
advantage to going with an IaaS vendor.
- Steve Tower, Management Consultant, Steve Tower, Disaster Recovery Plans & Assessments

Conduct a thorough cost of ownership analysis
The success of your IT DRP will be evaluated based on how well your DR plan works. Provisioning
for DR solutions that do not improve your ability to recover is a waste of resources.
The DR solution decision is often restricted due to cost constraints. Alleviate this issue by conducting a
thorough cost evaluation that demonstrates the long-term value of a tailored DR solution.
Cost Analysis:
• Compare the costs of operating your DR solution for each deployment model.
• Estimate your costs over a minimum six-year period, the typical contract duration. Covering the entire
outsourcing contract duration will result in a more accurate cost analysis.
• Pay attention to the flow of costs within the time period – certain options will require a larger upfront
investment than others.
• Remember that your organization will still incur the costs of the original data center upkeep if you decide
to outsource, even if it’s empty.
You can select more than one deployment method. Many organizations mistakenly believe they must select
the one most cost-effective method. However, depending on the criticality and the sensitivity of your applications,
you may choose to have a mix of different deployment models.
Total Cost of Ownership Analysis
2.2: TCO
Analysis

Building costs and IT operational costs are the major
cost drivers of operating in-house IT infrastructure
Maintaining and operating an in-house data center is typically more expensive than
outsourcing.
To calculate your cost owning in-house IT infrastructure, remember to include the following costs below:
Building costs: building lease, facilities site management fees, janitorial, and landscaping.
Site infrastructure costs: fire detection systems, alarms, mechanical systems, standby power for generators and UPS, and
physical security.
IT infrastructure costs: point of presence/carrier access.
IT operational costs: server refreshes, electricity, and server admin (level 1).
Other costs: standby power renovations and power renovations.
Below is an example of the typical costs to operate a 1000-square foot Tier III facility in USD.
Total Cost of Ownership Analysis (Click on link below for detailed cost breakdown)
2.2: TCO
Analysis

Co-location eliminates most of your site infrastructure
costs
By storing your IT infrastructure at a provider’s facility, you eliminate site
infrastructure costs and add co-location costs based on the number of racks
needed.
Below is a breakdown of Info-Tech’s co-location scenario snapshot, taken at a point in time. Since these prices are dynamic
and will fluctuate over time, speak with an Info-Tech analyst to get the most recent numbers.
See the DR Solution TCO Comparison Tool for a detailed cost breakdown.
Total Cost of Ownership Analysis (Click on link for detailed cost breakdown)
2.2: TCO
Analysis

Pricing for managed services varies widely from
engagement to engagement
Managed services eliminates your site infrastructure costs and some of your
IT operational costs (i.e. server refreshes).
Vendor pricing for managed services varies widely based on many factors, such as geographical location, services
in scope, reporting, and the division of roles and responsibilities between the vendor and customer.
Below is a breakdown of Info-Tech’s managed services scenario snapshot, taken at a point in time. Since these prices are
dynamic and can vary drastically from organization to organization, speak with an Info-Tech analyst to get the most updated
numbers for your context.
2.2: TCO
Analysis

Outsourcing to the cloud can drastically reduce your IT
infrastructure costs
Below is a breakdown of Info-Tech’s cloud scenario. Since these prices are dynamic and can vary drastically from
organization to organization, speak with an Info-Tech analyst to get the most updated numbers for your context.
The cloud scenario modelled below is a pure cloud scenario. Most “cloud” infrastructure outsourcing scenarios that Info-Tech
has seen are not pure cloud contracts – they often incorporate many aspects of managed services, which drive up costs.
Outsourcing to the cloud can provide further cost savings due to improved elasticity.
2.2: TCO
Analysis

Determine if you need a hot, warm, or cold standby
based on your RTO
*High availability (E.g. near-zero RTO and near-zero RPO) is a subset of a Hot Site Solution.
Hot Site Solution: A hot site provides the highest level of service continuity. All critical systems are duplicated at the DR site,
including relevant centralized storage. All that is required is reconfiguring the network to point to the DR site.
Warm Standby Solution: All critical systems are replicated at the DR site but are not necessarily up to date. There will still
be some level of data restore and/or system updates necessary to activate the DR site.
Cold Standby Solution: The DR site has the basic core infrastructure (e.g. power, cooling, network connectivity, etc.).
Necessary system hardware might also be present, but requires a bare metal restore. Other hardware might need to be
procured at the time of disaster.
Rule of Thumb
Application RTO Demand Type of DR Solution
RTO is short (e.g. 0 to 4 hours) Hot Site Solution*
RTO is moderate (e.g. 4 to 24 hours) Warm Standby Solution
RTO is extended (e.g. more than 24 hours) Cold Standby Solution
The rule of thumb represents a situation where your organization has the resources to provide a hot site for the
applications that demand near zero RTO. Regardless of which DR site you choose, it is critical that IT and
management are both aware of the downtime implications of the decision.
2.2: TCO
Analysis

Determine if you need synchronous or asynchronous
data replication based on your RPO
Synchronous Replication (synchronous): Data is written to both your primary as well as secondary storage arrays. In
doing so, the data remains completely current at the secondary. Synchronous is best used for low volume writes and high
bandwidth/low latency situations. Since the I/O requires acknowledgement from both the primary and the secondary, if your
network cannot keep up with synchronous, your applications may suffer performance issues.
Asynchronous Replication (asynchronous): Data is first written to the primary and then it is committed for replication to
the secondary source which is scheduled to arrive at internals (anywhere from minutes to hours). In an asynchronous
scenario, the primary may have committed transactions that have not been written to the secondary. In a disaster, you may
experience data loss due to the data latency. Since the I/O does not require acknowledgement from both the primary and the
secondary, asynchronous minimizes the impact on application performance.
Rule of Thumb
Application RPO Demand Type of Replication
Zero data loss (e.g. RPO of 0) Synchronous replication
Minimal data loss (e.g. RPO of 30 minutes)
Asynchronous replication with data arriving at the
replication target frequently
Moderate data loss (e.g. RPO of 4 hours)
Asynchronous replication with data arriving at the
replication target every few hours
Replication choice will ultimately come down to business requirement and the capabilities of your network. A best-
fit DR solution will ensure that the replication method is matched with the criticality of your application.
2.2: TCO
Analysis

Conduct a Force Field Analysis to identify which DR
solution will best meet the needs of your organization
Force Field Analysis - Duration: 3 Hours
• Whiteboard/Flipchart
• Markers
Materials
• Conduct a Force Field Analysis for In-House, Co-lo, Managed DR Services, and IaaS scenarios.
• Conduct the Force Field Analysis (Example on the following slide):
1. Describe the proposed DR site deployment option in a box in the middle of the whiteboard.
2. On the left-hand side, list all the forces that motivate your organization to pursue the option.
3. On the right-hand side, list all the forces that discourage your organization to pursue the option.
4. Assign a degree of magnitude (1 to 5) to the forces on either side. (1=low, 5=high)
5. Aggregate the magnitude values on both sides.
Info-Tech Insight
Provide a solid foundation for the go/no go decision by identifying all the factors that can potentially influence the decisions.
The best way to be mutually exclusive and collectively exhaustive is to include cross-functional stakeholders (e.g. members
from the IT and finance team). This will allow different perspectives to be discussed and verified.
• Include as many
stakeholders from
different departments
as possible.
Participants
• Analyze the Force Field Analysis (Example on the following slide):
1. The aggregated magnitude values are only there to act as a gut check and quick analysis.
2. The primary analysis starts by evaluating each of the motivating and discouraging forces. Think
how you can strengthen the motivating forces and how to weaken the discouraging forces.
3. Conduct a Force Field Analysis for the remaining deployment models.
4. Compare and contrast each option and decide on the main option to pursue.
2.3: Force
Field Analysis

Conduct a Force Field Analysis to organize your
decision-making process: Example
• The Force Field Analysis is
able to:
◦ Determine if the proposed
option can get support from
different stakeholders.
◦ Identify obstacles to the
potential options.
◦ Identify actions to reduce the
magnitude of the obstacles.
◦ Establish an objective and
holistic method to evaluate
potential options.
• Discuss the outcome of your Force Field Analysis (based on the example above).
◦ Currently, there are more forces against “moving all tier 1 applications into AWS.” This indicates that for this change to
occur, significant reduction in the forces against it is necessary.
◦ Reduce forces against it by hiring specialized RFP personnel to handle the proposal process as well as the vendor
management process. This will reduce the “manage vendor relationships” force.
◦ Reduce recovery risk by documenting vendor capabilities in an SLA.
Force Field Analysis - Duration: 3 Hours
2.3: Force
Field Analysis
Use Info-Tech’s DR Solution Force Field Analysis Examples document.

Conduct a DR Solution Decision Matrix to
shortlist the top options for your organization
After you have evaluated each potential deployment model through the Force Field Analysis,
document your discussions in Info-Tech’s Decision Matrix.
DR Solution Decision Matrix – Data Entry
1. Rank each selection criteria between 1-4.
(A 4 means that the deployment model is
best able to meet your criteria.)
2. Adjust the weight system to prioritize the criteria
that is more important to your organization.
E.g. Relative to the three other deployment
options, IaaS is best able to meet the Cost
Criteria. As such, it gets a 4.
E.g. Cost is the most important criteria for my firm,
thus the weight of the Cost Criteria will be higher.
2.4: Decision
Matrix
Use Info-Tech’s DR
Solution Decision
Matrix.

Analyze the DR Deployment Model Score Cards
and rank each DR solution
DR Deployment Model – Decision Matrix – Results
1. The Score Card will automatically rank
your scores from the previous tab. This
ranking is only a guide and you will still have
the opportunity to manually adjust the
rankings to fit your situation.
2. Use the Heat Map diagrams to identify the areas
of strength and the areas of weakness for each
deployment model.
The closer the dotted line is to the outer ring of the
heat map, the better the deployment model was
able to meet the decision criteria. E.g. The In-
House DR Site was able to meet your RTO/RPO
Needs, Performance, and Privacy criteria, but fell
short in Time to Deploy and Cost criteria.
2.4: Decision
Matrix

Situation Analysis
• The organization is already
using IaaS for most of its
primary systems so it is
familiar with managing cloud-
based services.
• None of its primary systems
are running on non-
commodity hardware (with
the exception of its Unix
system which is being phased
out), so it doesn’t have
technology compatibility
issues.
 In-House: The in-house option was quickly ruled
out. The organization does not have a
geographically distant data center or additional
server hardware that it can repurpose for DR. The
initial capital investment would have exceeded the
desired budget.
 Co-lo: A pure co-lo solution was also ruled out due
to required initial capital investment. Its hybrid co-
lo/cloud vendor was able to propose a solution that
was comparable in price to the AWS solution.
Mamiye Brothers, Inc. evaluated potential DR solutions, and
decided that a public cloud DR strategy was its best choice
CASE STUDY
Industry
Headquarters
New York City
Continue
onto the next
slide

Analysis
 Managed DR Service evaluation (SunGard):
Again, this was not considered due to cost
considerations, and it did not have any special
need (e.g. non-commodity hardware, or
inability to manage DR on its own) that
required the use of this type of service.
 Public Cloud: The organization has
experience with AWS. The public cloud is also
a good fit due to compatible technology
requirements (e.g. no non-commodity
hardware requirements), its desire to avoid
high capital costs, and a relatively small
amount of data that would need to be stored in
the cloud (and therefore manageable storage
fees).
Mamiye Brothers, Inc. evaluated potential DR solutions, and
decided that a public cloud DR strategy was its best choice
CASE STUDY
Industry
Headquarters
New York City
Result
 The organization decided to create its
entire DR environment in AWS due to
the following factors:
o Public cloud satisfied all of its
initial DR requirements (see
previous slide).
o Familiarity with Amazon meant
that there was going to be a
minimal learning curve for the IT
team.
o The scalability and the DR
testing capabilities of AWS were
additional benefits of the
solution.

The following are sample activities that will be conducted by Info-Tech analysts with your team:
Book a workshop with our Info-Tech analysts:
If you want additional support, have our analysts guide
you through this phase as part of an Info-Tech workshop
2.2
2.3
• To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-
Tech analyst team.
• Info-Tech analysts will join you and your team onsite at your location or welcome you to
Info-Tech’s historic Toronto office to participate in an innovative onsite workshop.
• Contact your account manager (www.infotech.com/account), or email
Workshops@InfoTech.com for more information.
Ensure that your DR solution is feasible in the long run. Conduct a thorough cost
analysis by estimating costs across a six-year period. Also capture the flow of costs
during this time (certain DR solutions require large upfront investments).
Assess the Total Cost of Ownership for each DR solution
Conduct a Force Field Analysis where each DR solution is evaluated across a variety
of considerations. Determine what the forces that are motivating you towards the
solution are and which forces are deterring you from the solution. Ensure that the
analysis is relevant and impactful by incorporating feedback from a wide range of
stakeholders.
Conduct a Force Field Analysis

PHASE
Design a best-fit DR strategy
3

Phase 3: Design a best-fit DR strategy
solutions
strategy
Phase 2: Phase 3:
gathering
Phase 1:

Phase 3 outline
Guided Implementation 3: Design a best-fit DR strategy
Proposed Time to Completion (in weeks): 2 weeks
Step 3.2: Solution Documentation Step 3.3: Bulletproof DR Solution Step 3.4: Executive Communication
• Review case studies and other
use cases for your DR solution.
• Discuss potential configurations
of your DR solution.
• Determine whether your organization
requires a bulletproof DR solution.
• Review the final TCO.
Finalize phase deliverable:
• Create the Executive Communication
Deck.
• Determine next steps based on your
DR solution.
• Document the best-fit DR solution
that meets your requirements.
• Review case studies and discuss
key insights.
• Determine the considerations for a
bulletproof DR solution.
• Review the TCO calculation from the
previous phase and make necessary
updates.
• Capture key insights from the DR
solution selection process and
present it to management.
• Obtain buy-in for necessary capital
investments.
DR Solution Executive Presentation
Template
• Design a DR solution that balances both strategic and cost requirements. Establish the next steps in the process, whether it is to build your own
data center or outsource it.

Phase 3: Design a best-fit DR strategy
Phase 3: A best-fit DR environment
caters specifically to the needs and
challenges of your organization.
See how other organizations have
created their DR solution and apply
their insights to your situation.
Click on this link to reference the DR Solution
Development Workflow.

Synthesize insights from real-world case studies
to your own situation
In-house DR site: The
DR site facility is
owned and operated by
your organization.
Managed DR services: The
vendor provides a managed DR
solution that uses the vendor’s
facility and hardware.
Primarily cloud-based DR: IaaS is used
to set up a DR environment – leveraging
a Commodity Cloud or Enterprise Cloud
provider.
Combined DR
solution: Uses
elements of two
or more
solutions (e.g.
co-lo plus IaaS).
Co-lo DR site: The DR site facility is owned
and operated by your co-lo vendor.
3.1: Example
DR Solutions

In-house DR Site Example: Active-Active
Primary Data
Center A:
Production
environment
Offsite
Backup
and/or Third
“Site” for DR
Primary Data
Center B:
Production
environment
25 miles
300 miles Info-Tech Insight
• An active-active, load balanced DR solution will provide a high level of
service continuity. Since the sites are both live environments, the RTO and
RPO is near-zero, making this an HA environment.
• Regional disasters or data corruption is a serious threat to this type of set-
up. Maintain at least an offsite backup to enable a rebuild or recovery, or a
third site/DR option to reduce recovery time if both primary sites fail.
Active-Active, Load Balanced
3.1: Example
DR Solutions
To increase the utilization of our DR solution and justify the expense, we are considering setting up an
active-active HA environment with our DR site as the second site. This will provide us with better day-to-
day service continuity and allow us to get value out of our DR site.
- Sam Shaabani, Infrastructure Services Manager, Corix Group of Companies

Co-lo DR Site Example: Active-Active
Co-located
Primary Data
Center A:
Production
environment
Offsite
backup at
your vendor’s
facility
Co-located
Primary Data
Center B:
Production
environment
25 miles
300 miles
Info-Tech Insight
• Similar pros/cons as the in-house active-active, load balanced solution.
o Low RTO and RPO
o Does not protect against regional disasters
• Work with the vendor to establish a DR solution in case both primary
sites fail. For example, leverage another of the vendor’s facilities to
establish at least a minimal DR environment and offsite backup location.
3.1: Example
DR Solutions
We were looking for a co-lo service where we would provide our own equipment and leverage the
vendor’s facility. We want to take advantage of their workspace, their hardened facility, and
communication diversity to help us speed up the process of recovery and testing.
- Steve Tower, Management Consultant, Steve Tower, Disaster Recovery Plans & Assessments

Co-lo DR Site Example: Active-Active with
a third site to protect against regional disasters
Co-located
Primary Data
Center A:
Production
environment
Co-located
DR Site: Tier
3 or 4 data
center
Co-located
Primary Data
Center B:
Production
environment
25 miles
300 miles Info-Tech Insight
• For local incidents, near-zero RTO and RPO is
achieved with the active-active environment.
• The third site provides protection against regional
events that incapacitates the active-active
environment. Recovery times using the third site will
depend on whether the DR site is a hot, warm, or cold
site and DR processes (including the vendor’s incident
response procedures).
3.1: Example
DR Solutions

Hybrid Co-lo/IaaS Solution Example: Leverage
IaaS to reduce hardware costs
Primary Site:
Co-lo or in-
house data
center
DR Site: Your
hardware where
necessary (e.g.
SAN, critical
systems) plus the
vendor’s IaaS for
additional
capacity
IaaS
Hybrid Co-lo/IaaS Solution
• Rather then deploying a full replica of your primary environment, deploy hardware at the co-lo site only where it
makes sense depending on workload, and leverage the vendor’s IaaS offering for additional “pay per use”
capacity.
• This model will incorporate many of the cost-benefits of a traditional IaaS since you will only pay for additional
compute power when you need it.
3.1: Example
DR Solutions

Situation
• A financial institution with three existing in-house Tier 4 data centers:
o Primary data center is approximately 25 miles from the head office, so network latency is not an
issue.
o The secondary data center is approximately 300 miles from the primary.
o The third data center is approximately 750 miles from the primary.
• DR solution requirements:
o The bank’s primary environment is fully replicated in each of its three existing data centers, so any
one of the three data centers can handle the workload alone if the others are unavailable. This
provides it with DR capability in the event of a regional disaster.
o The desire to seek an additional DR location was due to two additional risk concerns. The bank
was looking to protect against the possibility for a configuration error or a data corruption event to
wash through to the other DR sites or an unforeseen event that incapacitates all three sites.
o Before this client went through the DR solution analysis process, it considered all types of cloud-
based DR strategy to be a poor fit for the organization.
A multi-national bank goes through an evolution in thinking
and turns to IaaS for additional redundancy
CASE STUDY
Industry
Area Served
Banking
North America
Continue
onto the next
slide

Evaluation Summary
• There was no appetite to build another tier 4 data center at a
cost of approximately $1,200 per sq. ft. plus operating
expenses.
• The team responsible for evaluation of potential solutions
initially believed a co-location DR site was the best approach.
• A pure co-location solution would have required 35 racks of
servers and the Monthly Reoccurring Cost (MRC) year one
was $68k moving upwards to $141k per month by year six
when anticipated business growth over time was factored in.
• During the requirements gathering process it became clear
that the client had a solid workload profile to also leverage
IaaS, and therefore the potential to reduce costs. One
challenge here was the organizational mindset toward “cloud”
services and misconceptions about security with some cloud
deployment models, especially public cloud solutions.
• The ultimate solution chosen was a co-location
DR site hosted by a vendor that could also
provide IaaS (a hybrid solution). The DR site was
approximately 25 miles from the primary data
center, so this allowed for a high-availability
solution.
• The physical on-premise equipment that would
need to be co-located for DR was approximately 7
racks with an MRC year one of $10k moving
upwards to $22k per month by year six – much
lower than the pure co-location solution.
• The IaaS capability provides elasticity to allow a
burst in server workload capacity if needed for a
DR scenario. This was also more palatable to the
organization since IaaS would only be used
during DR and the organization was not using
“commodity” cloud services such as AWS.
and turns to IaaS for additional redundancy
CASE STUDY
Industry
Area Served
Banking
North America

and turns to the cloud for additional redundancy
CASE STUDY Hybrid Cloud Cost Analysis
$0
$20,000
$40,000
$60,000
$80,000
$100,000
$120,000
$140,000
$160,000
MRC MRC Yr2 MRC Yr3 MRC Yr4 MRC Yr5 MRC Yr6
Colocation 35 Racks
IaaS+colo Fully 'Bursted'
Steady State 7 Racks
(Monthly Reoccurring Cost)

Managed DR Services Example: Incorporate
other DR solutions to reduce costs
Primary Data
Center:
Mission
Critical
Applications
DR Services:
Vendor
manages DR
environment
IaaS
Managed DR Services with IaaS
• Managed DR services does not have to be all or nothing. For
example, if you have non-commodity hardware (e.g. a
mainframe), it can be cheaper to use a DR vendor that
supports this hardware vs. buying a second mainframe for
your DR site. However, you can reduce overall DR costs by
leveraging other DR solutions where it makes sense for the
workload.
• In this example, the organization is using managed DR
services for workloads that are not well suited to IaaS, and
using IaaS for remaining workloads. Often, the managed DR
services vendor will offer its own IaaS which can simplify
designing this solution.
3.1: Example
DR Solutions

Situation Design Takeaways
• A global design company shared
its current DR processes.
• The external DR vendor that this
organization leverages is
SunGard Availability Services.
• The current cost of the contract is
around $500,000 per year.
• The recovery time objectives for
all applications managed by
SunGard range from 48 to 96
hours. This recovery time
includes 24 hours necessary for
disaster declaration.
• The types of applications
SunGard manages are legacy
applications. These applications
do not have a high requirement of
RTOs and RPOs.
• The SunGard data center is over
800km apart from its primary
global data center.
• The SunGard data center is
connected to the primary global
data center via a high speed
network.
• Legacy applications that are
retired by the SAP will be moved
to a low cost data center and be
removed from SunGard.
• The cost of SunGard is often very
prohibitive. Service prices can
escalate very quickly as you add
functionality.
• Effective cost management
begins with being very specific
about what you put into SunGard.
• For SMBs there are often other
options to improve availability at a
lower cost.
• By successfully managing
SunGard, this global corporation
has passed all internal/external
audits since 2005.
Identify key insights from how a global corporation leverages a
managed services provider
CASE STUDY
Industry
Area Served
Design
Worldwide

Identify key insights from how a global corporation leverages a
managed services provider
CASE STUDY
Industry
Area Served
Design
Worldwide
Primary Data
Center:
Mission
Critical
Applications
Offsite Tape
Storage: Fully
Redundant
Underground
Bunker
DR Site:
Testing/Dev
and DR site
SunGard:
Legacy apps
with over 48h
RPO and 24h
RTO
8 miles
20miles

Cloud-Based/IaaS DR Example: Setting up your DR
environment in a public cloud
Primary Data
Center: In-
house or co-lo
Public Cloud – Region 1
Setting up the DR environment in a public cloud
• A DR environment is preconfigured in a public cloud IaaS environment, and data is backed up to
this environment so it is available for DR.
• In a normal state, your IaaS VMs are inactive, so you only incur storage fees. During a disaster,
you activate the pre-configured VMs in your DR environment.
• This can be the most economical solution, depending on the amount of data you need to store in
the cloud, due to the “pay-per-use” nature of this option.
Note: This solution is not a good fit for all workloads and all organizations. Use Info-Tech’s Cloud
Readiness and Service Value Workbook to evaluate whether this is a good fit for your organization.
IaaS DR
Solution
3.1: Example
DR Solutions

Cloud-Based/IaaS DR Example: Pure cloud solution
Production Environment DR Environment
Cloud DR Solution
Pure Cloud Solution
• A pure cloud model puts both your
primary as well as your DR
environment into the cloud.
• Since your entire environment is in the
cloud, you can potentially avoid
performance issues that “on-premise to
cloud” solutions may experience.
Info-Tech Insight
• Build in additional redundancy into your cloud solutions by
leveraging different regions and availability zones.
o Regions: Geographically distant environments which will not
be affected by the same regional disaster. If you require
geographic separation, then make sure to provision with your
provider to deploy your DR solution over separate Regions.
o Zones: Environments within each region that are connected
by low latency connections. Deploying your data in different
zones will provide redundancy for isolated failures.
Zone
Zone
Zone
Zone
Global
Region Region
3.1: Example
DR Solutions
Adapted From: Wheal, John. "What Are AWS Regions &
Availability Zones." Web log post. MyTechBlog

Decision Design Insight
• After analyzing a wide range of
potential DR solutions, the
organization decided to pursue
Amazon Web Services (AWS) as
its primary DR environment.
• Data would be backed up to this
DR environment so that it is
readily available for DR if needed.
• VMs would only be activated in
AWS during a DR scenario,
which reduces its AWS fees.
• To streamline the recovery
workflow, the VMs are pre-
configured so that they can be
activated in minutes.
• Using public cloud for DR can be
cheaper and a less complex
implementation versus setting up
an in-house or co-lo DR site.
However, it’s not a good fit for all
organizations and all workloads.
The fit depends on factors such
as the amount of data (which can
significantly increase the cost of
cloud-based DR services) and
integration requirements with
systems that can’t be hosted in
the cloud (e.g. non-commodity
systems, or systems that must be
hosted locally for performance
reasons).
Mamiye Brothers, Inc. designs a DR solution that leverages a
public cloud vendor for its entire DR environment
CASE STUDY
Industry
Headquarters
New York City

Situation Complication Resolution
• To implement its AWS-based DR
site solution, Mamiye Brothers,
Inc. first explored using a third-
party AWS plug-in that
streamlines and automates
creating the DR environment
based on the organization’s VM
configurations for its primary
systems.
• The third-party AWS plug-in was
dropped due to the impact it
would have on VMware licensing
costs. Specifically, the plug-in
would require a dedicated
vCenter to be running full time.
• Some workloads were running on
Windows 2000 (not supported by
AWS) and Windows 2003
(nearing support end-of-life).
• The organization is leveraging
Amazon’s Storage Gateway
service to pre-configure its AWS
VMs and execute activing those
VMs in a disaster. This option
requires more manual
configuration due to the lack of a
direct interface with VMware.
However, the end result is the
same (a pre-configured DR
environment in AWS).
• To resolve the Windows
2000/2003 compatibility issues,
the organization is planning to
upgrade those systems.
Mamiye Brothers, Inc. adapts to deployment issues when
trying to implement a cloud-based DR strategy
CASE STUDY
Industry
Headquarters
New York City

Combined DR Solution: Bulletproof DR Strategy
Configuration Example
Primary Site:
Co-lo or in-
house data
center
DR Site:
Closer to
primary to
allow for
replication
25 miles
IaaS
300 miles
Tertiary site:
Protect against
regional disasters
IaaS
Bulletproof configuration
• A bulletproof DR strategy will protect your organization against the day-to-day service continuity threats as
well as large regional disasters through the tertiary site.
• For additional DR capabilities, consider asynchronous replication to the tertiary site. This will protect the
organization against data corruption to both the Primary as well as the DR site.
Synchronous
Replication
Asynchronous
Replication
3.1: Example
DR Solutions

Finalize your DR strategy by documenting the DR
solution
• Based on the discussion and analysis from the previous phases, document your DR solution.
• The goal here is to provide clear documentation so that external (auditors) and internal (management) stakeholders can
easily reference the document and understand the DR solution.
• Feel free to leverage Info-Tech’s icons for your documentation.
Document the DR Solution – Duration: 1 hour
In-house Co-lo Managed DR
Services
IaaS
Key considerations during documentation
• When possible, document the distance between each DR solution.
• Group multiple solutions within a single premise. (E.g. If your Primary solution has an In-house data center as well
as a co-lo data center, then group them together.)
• Document the additional functions of each solution. (E.g. The co-located DR site is also a Test/Dev environment.)
Off-site Storage
3.2: Document
your DR
Solution

If you have decided that you need a bulletproof DR strategy, then following your configuration
decision, you need to select the appropriate data centers that will adequately host your data.
Consider the following 6 elements when selecting a bulletproof DR Strategy:
Security
Location
3.3: Bullet-
proof DR
Strategy

Location
Level of
Redundancy
Where to locate your data center revolves around 3 elements.
1. Risk of Natural Disasters: If your organization is willing to accept the risk of a local disaster,
then having a data center close to where your primary data center is would make sense.
However, if regional risk is an issue then make sure that your DR data center is not
susceptible to the same regional risk as your primary.
2. Digital Maturity: Each city differs in its digital maturity. Locations such as Dallas or Atlanta
are popular data center cities due to rich fiber options.
3. Business Climate: Depending on your location, this can have an impact on the total cost of
ownership. Incentives such as cheaper taxes and rates from local government and utilities are
strong factors to consider when deciding on where to locate your data center.
A data center can be categorized into 4 different tiers.
• Tier 1 – Basic data center with no redundant capacity components (single uplink and servers)
• Tier 2 – A tier 1 data center with redundant capacity components
• Tier 3 – A tier 2 data center with multiple distribution paths and dual powered equipment
• Tier 4 – A tier 3 data center with fully fault-tolerant components (uplinks, storage, HVAC
systems, servers, power, cooling)
• As you increase the level of redundancy at your data center, from low redundancy to complete
redundancy, naturally the cost will increase.
• This then makes delineating your applications that much more important, as ideally you would
place your mission critical systems in Tier 4 data centers, and your less important applications
on cheaper Tier 2 or 3 data centers.
Source: Uptime
Institute
3.3: Bullet-
proof DR
Strategy

it-Select-a-Best-Fit-DR-Solution-Phases-1-3

it-Select-a-Best-Fit-DR-Solution-Phases-1-3

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to it-Select-a-Best-Fit-DR-Solution-Phases-1-3

Similar to it-Select-a-Best-Fit-DR-Solution-Phases-1-3 (20)

it-Select-a-Best-Fit-DR-Solution-Phases-1-3