In IT, the following terms come up frequently:
- Backups
- Replication
- High Availability
- Fault Tolerance
- Disaster Recovery
In this post, I will explain what each one means, why they exist, and when to use them, using simple language and real‑life examples.
An important thing to remember is that these are not competitors, they work together.
A good setup often uses:
Backups → recover from mistakes, corruption, or attacks (get my data back)
Replication → keep data in sync between locations (supports faster recovery)
High Availability → reduce or avoid downtime (stay online during failures)
Fault Tolerance → keep running even if something fails (no interruption)
Disaster Recovery → survive major outages and disasters (recover from the worst)
Let’s start in the following order: Backups, Replication, High Availability (HA), Fault Tolerance and then Disaster Recovery (DR).
Backups
What is a backup?
A backup is a saved copy of your data from the past. If something goes wrong, for example, files are deleted, corrupted, or a system fails, you can use a backup to restore your data to an earlier point in time.
Backup Example 1:
You regularly copy your important files (documents, photos, work files) from your laptop to an external hard drive and then disconnect it. If your laptop is lost, damaged, or the hard drive fails, you can plug in the external drive and restore your files. The backup is a separate copy created earlier, so even if the laptop is gone, the data still exists.
Backup Example 2:
A small business stores customer records, invoices, and reports on a company server. Every night, these files are backed up to a secure off‑site location. One day, ransomware encrypts the main server. The business wipes the server and restores the data from the previous night’s backup, allowing work to continue. The business is able to restore data from a safe, unchanged copy created before the incident. This protects against accidental deletion, cyber attacks, and system failure.
Note: Ransomware attack
An attacker encrypts your files so you can’t access them and then demands a payment (usually money) in exchange for unlocking or decrypting the data.
Backup Example 3:
A company backs up its database every night. If someone deletes data by mistake, IT restores yesterday’s backup.
Summary of when backups are used
Backups are used when data needs to be recovered from a previous safe copy, such as in the following situations:
- Accidental deletion – “Oops, I deleted the wrong file”
- Ransomware attacks – Data is encrypted or made unusable, and systems must be restored from a backup created before the attack.
- Data corruption – Files or databases become damaged or unreadable due to software issues, hardware failure, or crashes.
Pros of backups
- Backups are usually less expensive than High Availability or Disaster Recovery solutions.
- Protects against human mistakes – Helps recover data after accidental deletion or overwriting.
- Allows point‑in‑time restore – You can restore data from a previous state (for example, yesterday or last week).
Cons of backups
- Systems may be unavailable during restore – Services can be down while data is being recovered.
- Recent changes may be lost – Any data created after the last backup is not included in the restore.
- Recovery is not instant – Restoring data can take time, especially when large amounts of data are involved.
Replication
What is replication?
Replication means automatically copying data to another location so that changes are copied continuously or near real time. Once replication is set up, it usually runs automatically in the background. When data changes on the main system, the same change is sent to the replica without manual action.
Replication Example 1:
You type notes on your laptop and they quickly sync to another laptop. If you delete a sentence on one device, it disappears on both. Replication keeps copies in sync, so any change, good or bad, is automatically copied to all replicas.
Replication Example 2:
A database is continuously replicated to another server, creating a live duplicate. The second server is kept up to date, even if no failover has happened.
Replication Example 3:
An online store uses replication to keep a second copy of its database up to date. A staff member accidentally deletes thousands of customer orders from the main database. Because replication copies every change, the deletions are also applied to the second server. As a result, both databases are missing the orders.
Replication Example 4:
A company has a file server in one data centre and continuously copies changes to a second server in another location. When a file is updated on the primary server, the same change is automatically copied to the second server after a short delay (depending on replication configuration).
When replication is used
- To reduce downtime by keeping a ready to use copy available if the primary system fails.
- Replication is commonly used in high availability designs and disaster recovery strategies to improve resilience.
Pros
- Fast recovery – Systems can switch to a replicated copy quickly when a failure occurs, reducing recovery time.
- Minimal data loss – Data is copied in near real time
Note: A small amount of data loss may occur if the latest changes were not able to replicate before the failure. - Supports business continuity – Replication reduces downtime and helps businesses continue operating during outages or infrastructure failures.
- Systems stay current – Replicated systems remain up to date with ongoing changes.
Cons
- Replicates mistakes and corruption – If data is accidentally deleted or becomes corrupted, replication copies the same problem to all replicas. Replication improves availability, but backups are still required to recover from mistakes or data corruption.
- Does not protect against human mistakes – Actions such as accidental deletions, overwriting data, or running the wrong command are replicated automatically and cannot be reversed using replication alone. Some platforms combine replication with snapshots or point‑in‑time recovery, which allows rollback, but this capability comes from the snapshot or recovery layer, not from replication itself.
- More expensive than backups – Replication typically requires additional infrastructure, storage, networking, and management, making it more costly than traditional backup solutions.
High Availability (HA)
What is High Availability (HA)?
In today’s world, smooth operations of applications is crucial for businesses, but issues to those applications can pose challenges. High Availability helps IT systems stay available during common failures and periods of heavy usage. It is designed to keep services running for long periods with minimal downtime, often by automatically switching to healthy components when something fails. Many platforms also allow planned manual switchovers during maintenance or upgrades.
High Availability and replication work together, but they are not the same thing.
Replication is commonly used in High Availability, especially for data (like databases), but High Availability also uses things like load balancers and multiple servers to keep services running. High Availability focuses on keeping services online, while replication ensures that data already exists on another system. When a failure happens, High Availability mechanisms (often automatic failover) can switch to the replicated copy, allowing the system to continue operating with minimal or no downtime.
In short, High Availability keeps a service running by having another copy ready. For websites, that can mean multiple servers behind a load balancer. For data (like a database), it often means keeping a second copy of the data in sync so the system can switch over quickly.
HA Example 1:
A supermarket has multiple checkout tills. If one till breaks, customers are redirected to another till, so the shop continues operating without closing.
HA Example 2:
A shopping website runs on multiple servers at the same time behind a load balancer. If one server fails, incoming traffic is automatically redirected to another server, so customers can continue shopping as normal.
HA Example 3:
A hospital system runs patient records on two servers at the same time. If one server fails, the service continues with minimal downtime, so doctors and nurses can still access patient information.
HA Example 4:
A company uses two internet connections from different providers. If one internet connection goes down, traffic automatically switches to the other, so staff can continue working without noticing any outage.
Note: Load balancer
A load balancer distributes traffic across multiple servers so the service stays available.
When High Availability is used
- Public websites and apps
- Banking and payment systems
- Online shopping platforms
- Any service that must always be on
Pros
- Minimal downtime
- Automatic failover when failures occur (common in many HA setups)
- Better user experience
Cons
- Typically requires more infrastructure and can cost more than backup alone
- More complex to design and manage
- Does not protect against accidental data deletion (backups are still required)
Fault Tolerance (FT)
What is Fault Tolerance (FT)?
Fault Tolerance is related to High Availability, but it goes a step further. It is the ability of a system to continue operating during a failure, often with very little or no noticeable interruption, depending on the design. This usually requires duplicate components already running in parallel, so if one component fails, another can take over immediately. Because fault tolerance requires extra redundancy, it is usually more complex and more expensive than high availability.
Fault Tolerance Example 1:
A server has two power supplies connected to separate power sources. If one power supply fails, the server continues running on the other one, and users don’t notice any disruption.
Fault Tolerance Example 2:
A storage system uses RAID. If one disk fails, the system continues running and data remains available while the failed disk is replaced.
Fault Tolerance Example 3:
A critical service runs on two identical systems in parallel. If one system fails, the other continues processing without needing a restart, so users do not experience any downtime.
Fault Tolerance Example 4:
A network has two separate network paths (for example, two switches or links). If one path fails, traffic automatically switches to the other path and the connection stays up.
Fault Tolerance Example 5:
A company uses a Standard (zone‑redundant) Azure Load Balancer with virtual machines deployed across multiple Availability Zones. If one Availability Zone has an issue, the load balancer automatically routes traffic to the healthy zones, allowing the service to continue running.
Fault Tolerance Example 6:
A company stores important files in an Azure Storage account. Azure Storage automatically keeps multiple copies of the data to improve durability and availability during hardware, power, or network failures. The level of resilience depends on the redundancy option chosen, such as copies within one datacentre, across Availability Zones, or in a secondary region. Check out the following diagram to learn more about Storage account replication options in Azure: Storage_Replication_Options.
When Fault Tolerance is used?
Fault tolerance is used when a system must keep working even if something breaks.
Instead of waiting for someone to fix the problem, the system is designed with redundancy so another component can keep things running.
Fault tolerance is used when:
- Even a short outage is unacceptable (downtime has a serious impact).
- The service must continue operating even if a server, disk, or network component fails.
- The system is considered mission‑critical (for example, payment processing or critical business systems).
Fault tolerance is achieved using techniques like redundancy and failover, so the system can continue operating even when a failure occurs.
Pros of Fault Tolerance
- No interruption during failures, users don’t notice the issue
- Very resilient to component failures because redundancy is already running
- Best option for systems where downtime is not acceptable
Cons of Fault Tolerance
- More expensive – requires extra duplicated components running in parallel
- More complex to design and manage (because systems need to stay in sync)
- Does not replace backups – if data is deleted or corrupted, fault tolerance can keep the service online, but you still need backups to restore a clean copy.
- Disaster Recovery (DR) is still required for datacentre‑level or regional disasters.
High Availability (HA) is not always Fault Tolerance (FT)
A company runs two web servers behind a load balancer, so if one server fails, the other can keep the website online. However, both servers are placed in the same rack or share the same power or network equipment. If that rack fails, both servers go down and the website becomes unavailable. To make the system fault tolerant to a rack failure, the company places the servers in separate racks with separate power and network paths. Now, a single rack failure won’t take out both servers at the same time. Fault tolerance isn’t about having two servers, it’s about making sure the two servers don’t fail for the same reason.
Disaster Recover (DR)
What is Disaster Recovery (DR)?
Disaster Recovery is a plan and setup used to restore systems and data after a major failure or disaster, such as a data centre outage, cyberattack, or natural disaster.
Unlike High Availability, which tries to keep systems running, Disaster Recovery assumes a major outage can happen and focuses on how to bring everything back after a serious incident. For example, a complete data centre/region failure, such as a natural disaster, flooding, tornado, something which takes the entire region offline. You will declare a disaster and initiate a failover from your primary site to your secondary site. You could attempt to recover all of the data in the secondary site from backups but this could take a long time.
HA = stay running through smaller failures
DR = recover after a major outage that high availability alone cannot handle
Note: DR failover can be manual or automated depending on the tools used, but it usually involves a planned process and may take longer.
Why Disaster Recovery is different from High Availability
High Availability (HA) aims to prevent downtime by switching to healthy systems when something fails, often without users noticing. It is designed for small, common failures, such as a server crash or hardware fault.
Disaster Recovery (DR) is used when HA is not enough, for example when an entire site or region is unavailable. DR focuses on restoring services and data after a major outage, and it can take longer than HA.
Disaster Recovery follows planned recovery steps (which can be manual or automated) to bring systems back online after a serious incident. High Availability focuses on keeping systems running, often automatically, and often without users noticing, during smaller failures. They are different, but they work together. High Availability reduces everyday downtime, and Disaster Recovery provides a fallback when a major disaster occurs.
DR Example 1:
Your office burns down, so you move work to a backup building that was prepared in advance. This is an example of Disaster Recovery.
DR Example 2:
An organisation has two data centres: a primary and a secondary. The secondary data centre is used for Disaster Recovery. Data is continuously replicated to the secondary data centre. If the primary data centre goes offline, failover to the secondary site is performed as part of the Disaster Recovery plan.
DR Example 3:
A company’s file server is taken offline after a cyberattack. The Disaster Recovery (DR) plan is activated to rebuild the server and restore business operations. As part of the DR plan, data is restored from backups, and work resumes after recovery is complete.
DR Example 4:
A ransomware attack encrypts an organisation’s systems. The affected systems are wiped and rebuilt, and clean data is restored from backups. This is an example of Disaster Recovery.
When Disaster Recovery is used
- Data centre failure
- Cloud region outage
- Floods, fires, or cyber attacks
Pros
- Protects against large‑scale disasters
- Covers entire systems and services, not just data
- Can combine replication and backups for faster recovery and data protection
Cons
- More expensive than backups alone
- Recovery is not always instant and may involve downtime
- Requires careful planning, documentation, and regular testing. The right test frequency depends on the organisation and workload, but disaster recovery plans should be practiced regularly.
Why do all these matter and when should an Organisation consider them?
Many organisations don’t think about backups, replication, high availability, or disaster recovery until something breaks. But when a system goes down, the impact can be serious: work stops, customers can’t access services, revenue can be lost, and trust can be damaged. For some systems, there can also be compliance or legal consequences. That’s why it helps to decide in advance what level of downtime and data loss is acceptable, then choose the right approach based on that.
A simple way to choose between these options is to understand two terms:
- RTO (Recovery Time Objective): the maximum time you can tolerate the service being unavailable after an outage. In other words: “How long can we be down before it becomes a real problem?”
- RPO (Recovery Point Objective): the maximum amount of data loss you can tolerate, measured in time. In other words: “If we have to restore, how far back in time can we rewind without major impact?”
Think of it like this: the faster you need to be back online (low RTO), the more you move towards HA/replication. If you mainly need to get data back (even if it takes longer), backups matter most.
I hope you found this post useful. Please feel free to share any feedback or comments below. Thank you
