Simple definition
Replication maintains a secondary copy of data, storage volumes or virtual machines on another system. The goal is to keep a version available for continuity or disaster recovery. The copy may lag behind the source and is not necessarily a historical backup: deletions and corruption can also be replicated.
Technical definition
Synchronous replication generally waits for confirmation from the destination before considering a write complete, creating latency and availability constraints. Asynchronous replication transfers changes after they commit on the source, allowing a gap between copies. Systems may track changed blocks, application logs or storage writes. Data consistency depends on implementation and whether related volumes or applications are handled together.
What is it used for ?
Reduce recovery time after hardware or site failure, prepare workload failover and support continuity requirements. Replication forms part of a disaster recovery strategy but does not by itself provide network failover, application startup order or independent backups.
Practical example
A company replicates a business-application VM to another site every fifteen minutes. When the primary site fails, staff validate the replica's consistency and start it according to the recovery plan. Unreplicated changes may be lost and restoring user access, DNS and related services still takes time.
Common issues
- Insufficient bandwidth causing replication lag.
- Corruption, encryption or accidental deletion propagated to the target.
- Inconsistent states across multiple interdependent applications or disks.
- Untested failover with missing destination networking or DNS.
- Split-brain when two copies accept changes independently without coordination.
Synchronous versus asynchronous replication
Synchronous replication aims to minimize divergence between source and target but depends strongly on latency and destination availability. Depending on policy, a link failure can delay or prevent writes. Asynchronous replication tolerates greater distance and fluctuating networks, at the expense of some potential data loss since the last successfully transmitted changes.
Replication lag is not the same as service recovery time. RPO represents an acceptable amount of lost work measured in time, while RTO represents the acceptable restoration delay. Both must be tested against real business workloads.
Failover, failback and application dependencies
A replica must have sufficient compute resources, compatible networking and correct application configuration. A failover plan considers VM boot sequence, IP addresses, DNS, remote-user access and security controls. It must also prevent two isolated copies from accepting conflicting writes to the same logical dataset.
After the primary system returns, reverse synchronization and failback require a clear procedure. Starting an outdated source without identifying the latest authoritative data can cause additional data loss.
Replication is not a substitute for backup
Fast replication can distribute deleted files or ransomware-encrypted data to the second site almost immediately. Replica version history may reduce this risk, but does not automatically provide the isolation of an independent backup. Backup systems retain recoverable points in time and can protect copies against immediate deletion.
For valuable business data, replication, protected backups and recovery drills solve complementary resilience needs.
Related terms
Key takeaway: replication helps maintain a quickly usable secondary copy for disaster recovery. Currency depends on the replication mode; independent, tested backup history remains necessary.