Data replication is the process of electronically copying data from one storage location to another. If your business unexpectedly faced an outage and you needed to recover, data replication allows for the effortless resumption of operations after an incident minimal loss or corruption of data.
The primary purpose of data replication in a Disaster Recovery Plan is to ensure that business applications and their relevant data stores are always available after an incident has crippled or destroyed an organisation’s IT environment.
Data replication on its own does not represent a Disaster Recovery Plan, but rather, it should rather form part of a comprehensive Disaster Recovery and Business Continuity plan.
The 3 primary replication technologies
There are three main replication technologies which provide data replication services in an IT environment.
These range from technologies that are designed to replicate data at the hardware storage level through to technologies that operate at the hypervisor or virtual machine (VM) level.
1. Array-Based Replication
Array-Based Replication is enabled by software that runs on hardware based storage controllers. This software replicates an entire storage set to a target replication environment. This software is designed for and operates at the physical level and is of little to no benefit in virtualised environments.
2. Agent-Based Replication
Agent-Based Replication is facilitated by a software agent that needs to be installed on every physical and virtual server.
It’s more portable than an array-based replication solution but has a very high management and maintenance overhead as each server must have the agent deployed and maintained. The management overhead of installing and managing multiple agents limits the scalability of this form of replication solution.
3. Hypervisor-Based Replication
Hypervisor-Based Replication is a technology that is designed to enable the full benefits of virtualisation. Software is deployed directly into the virtual hosting infrastructure where all writes are captured at the virtual machines’ disk format level and replicated to the recovery site hypervisor layer.
This enables it to be more efficient, accurate and responsive.
The 3 primary replication deployment models
There are three deployment models available for organisations that have chosen their replication technology platform which range from models with real-time replication to scheduled replication at a point in time.
1. Synchronous Replication
Synchronous Replication ensures all data is written in the source and target storage simultaneously. Error checking is performed by waiting for acknowledgement from each storage location that data has been written successfully.
Synchronous Replication is dependent on identical hardware and networking interfaces to ensure reduced latency and efficient performance.
2. Asynchronous Replication
Asynchronous Replication in a virtualised environment uses virtual machine snapshots that are taken at a point in time and then sent to a recovery site.
The backup frequency is set on a schedule of hours and is dependent on the number and frequency of snapshots the infrastructure, network and application can tolerate.
3. Near-Synchronous Replication
Near-Synchronous Replication is constantly replicating only the changed data to the recovery site. This is done as close to real time as possible and is usually within seconds.
This gives the organisation running near-synchronous replication an ‘always replicating’ solution. Asynchronous replication does not need to be scheduled, does not use snapshots and writes to the target storage without the need to error check.
What are Snapshots?
A snapshot is the state of system at a point in time. Virtual Machine Snapshots are differential copies of the changes of a virtual machine since its creation or since the last snapshot was taken.
There two main types of snapshots, VM-Level Snapshots and Storage-Level Snapshots.
1. VM-Level Snapshots
VM-Level snapshots are created in the hypervisor hosting the VM and create a large performance impact on the hypervisor hardware infrastructure and the VMs running on the infrastructure.
Due to the high maintenance and management overhead it is not recommended to create, remove or leave VM-Level snapshots in production working hours.
2. Storage-Level Snapshots
Storage-Level Snapshots incur less performance impact than VM-Level Snapshots. These snapshots utilise processing power in the storage controller and at scale can still result in a performance degradation.
This potential performance degradation limits the frequency with which storage-level snapshots can be created.
Are snapshots backups?
Backup solutions use snapshots to create copies of data sets at a regular pre-determined point-in-time. Unless snapshots are copied to some form of redundant secondary storage, snapshots are not true backups.
Backups are an integral part of a Disaster Recovery Plan but fall short when it comes to Business Continuity and High-Availability.
Backups alone do not have the low Recovery Time Objective needed for seamless business continuity in the event of a service disruption or outage.
How does continuous data protection compare to snapshots?
Continuous data protection (CDP) utilises change-block tracking at the hypervisor layer to constantly replicate data as it is written to storage. The impact on performance is negligible when compared to VM-Level and Storage-Level snapshots since only the changes are continuously replicated and not the entire VM, host or storage array.
Hypervisor-based CDP utilises journal technology which tracks and keeps a log of all changes that occurred during a specific time frame. This allows for point-in-time recovery in increments of a few seconds giving organisations the option of rolling back to multiple points in the past.
This ‘always replicating’ service offers considerably lower Recovery Point Objectives (RPO) than traditional snapshot based backup solutions since organisations suffer significantly less data loss in the event of a service failure. In addition, the journaling technology offers multiple benefits positively affecting point-in-time recovery options beyond simply the sheer number of checkpoints available.
Can backups be considered Disaster Recovery?
The short answer is no. Backups form part of a Disaster Recovery but are not the entire Disaster Recovery Plan.
Organisations should approach a Disaster Recovery Plan by first cataloguing all their IT services and then setting Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for each service.
Once this is complete the organisation can then do some research around the replication options available to them to meet the stated RTOs and RPOs goals for each service.
The most innovative and affordable solution on the market is SecondSite powered by Zerto.