Disaster recovery
A disaster recovery involves the procedures and policies for data recovery and retrieval following a natural or human-induced disaster.
Disaster recovery solutions
The possible disaster recovery solutions for IXIASOFT CCMS deployments are:
- Using hypervisor with a virtual
machine
When using a hypervisor with a virtual machine:
- All complexities (procedures to retrieve the data) are hidden by the hypervisor and the exact capabilities are defined by the hypervisor.
- Procedure for installing the CCMS is standard.
- The process of data replication between data centers is hidden by the hypervisor.
- Once the CCMS server is restored, the end user just needs to reconnect.
- Cold standby with manual data
synchronization - Cold standby is a redundancy method in which the
secondary (or backup) system is called upon when the primary system fails.
When disaster recovery is implemented using cold standby with manual data
synchronization:
- The installation procedure is standard for both primary and secondary sets of machines.
- Upgrades or updates should be performed on both primary and secondary sets of machines.
- The customer is responsible for copying the data between sites (with either backup or snapshot); depending on the delay between the copies, it is possible to lose data.
- The domain name system (DNS) alias pointing to the primary server needs to be remapped to point to the new disaster recovery secondary machine, thus allowing the end user to reconnect without a problem.
- The replicated data needs to be restored manually before it can be accessed by the end users.
- Once the CCMS server is restored, the end user only needs to reconnect.
- Once the primary server is restored the entire process needs to be redone.
- This configuration might incur additional licensing costs. For information, contact IXIASOFT Sales.
- Warm standby with replicated docbase - Warm standby is a redundant method in which
the secondary (i.e. standby) server runs and receives replicated data from
the primary server. Since the data is replicated to the standby server at
regular intervals, there are times when the servers do not contain the exact
same data. In addition to the disaster recovery implementation requirements
of the cold standby with manual synchronization,
implementation using warm standby with a replicated
docbase has the following
characteristics:
- Data is replicated automatically to the other site; some data may be lost depending on the transmission speed, the amount of data being copied to the site, and the time or delay between replication cycle and the disaster event.
- The scenario is more complex to manage and requires monitoring.
- A good network connection between the primary and secondary sites is required to make sure that the transaction logs are sent in a timely fashion.
- Additional steps are required to bring the replicated content online before the end users can access it.
- The process to bring the primary site online after a disaster is more complex than the simple file copy that the cold standby scenario offers.
- This configuration might incur additional licensing costs. For information, contact IXIASOFT Sales.
- Secondary site with replicated docbase - In disaster recovery using
a secondary site with a replicated docbase, data is replicated automatically to the other site. In addition to the
implementation requirements of the warm standby with a
replicated docbase,
implementation using a secondary site with a replicated
docbase has the following
characteristic:
- The end user can connect either to the primary server or to the secondary server.
Combining disaster recover with high availability
You can deploy a solution that provides both disaster recovery (replication) between primary and secondary sites and high availability within each site by using the following structure:
| Primary Site | Disaster Recovery | Secondary Site |
|---|---|---|
Choose either:
|
Deploy site replication | Choose either:
|