Implementation phases

Assessment

Preliminary phase of the project. In this phase, we analyze the needs and set the conditions of the service (RTO, replication mechanisms, etc). The assessment determines:

• The best replication mechanism for each application (hypervisor, agent, mechanisms of the application itself).
• The minimum consistency for all applications to begin their services on the contingency site (crash, file, application).
• The expected RTO of the whole plan based on the applications and volumes of data that make up the protected platform.

Installation and launch

This phase covers the configuration of hypervisor-based replications, the cabinet and, if necessary, the installation of servers for the specific replication of any application that so requires (e.g., Exchange 2010 replication). This phase also includes:

• Creation of scripts and necessary reconfigurations (network, nomenclature, DNS) for proper operation of the recovery plan.
• Performance of first recovery tests and setting of reference RTO.
• Drafting of a Disaster Recovery Plan. This document is agreed with the client and sets down:

o    The protocol for the formal declaration of a disaster and procedure for activating the contingency site. This includes contact telephone numbers, authorized persons, etc.
o    The results of the first recovery tests, which will determine the RTO and RPO to be used in future tests (and which will be recorded in the SLA of the service).
o    If third parties are involved (developers, client application managers), the protocols for service delivery will be set to determine the responsibilities of each party in the periodic tests and in the event of a disaster.

Service management

After the project has begun, periodic tests will be performed to ensure an optimal response in case of disaster.

• By using virtualization on the contingency site, we can perform recovery simulations without involving the protected site.
• This reduces the risk of failures during the necessary recoveries. The test simulates the total recovery of the services and detects any discrepancy between the recovery plan and the changes made on the protected site. This ensures that the recovery plan is always up to date.
• The recovery tests are conducted bimonthly, unless additional testing is required.
• Regular tests help us to detect changes in the RTO and take corrective action.
  

Packages

Virtual Raas

• All devices on the primary site to be protected are virtualized (NEXICA VMWare platform).
• There are no dedicated network devices, or these can be omitted in the replication.
• The minimum consistency required is crash consistency.
• The RPO can be just hours.

Cloud RaaS

Same features as the Virtual RaaS, but on the vCloud Director platform and when additional settings are required to replace non-replicated Cloud features (network isolation, NATs, etc.).

Hybrid Raas

• Physical servers or network devices must be protected.
• Site Recovery Manager is always used for replication (there is no application-level replication).
• The minimum consistency required is crash consistency (although the guarantee often extends to files or applications).
• The RPO can be just hours (i.e. the client agrees to the loss of a few hours of data).

Hybrid Raas

Any scenario in which replications are required at application level to ensure consistency at application level and an RPO of minutes or seconds. for example:

• Exchange 2010 (native replication).
• Oracle RAC (Data Guard).
• Active Directory (native replication).

*The RTO will depend on numerous factors, including the number of protected servers, the volume of information to recover, the time taken to report the disaster, etc.
**For applications replicated by their own mechanisms, the RPO is minutes or seconds. For the rest of the platform, it will be hours.