System Resilience and High Availability

System resilience and high availability. This lesson keeps two ideas apart that people love to confuse: keeping a system running through a failure, and recovering it after a disaster. And it contains one of the most important points in the domain.

The scene. The infrastructure team is proud of the new setup: mirrored disks, clustered servers, real-time replication to a second array. When you ask about backups, the answer is that they are not really needed anymore, everything is replicated, so nothing can be lost. A week later a user deletes a critical folder, and the deletion replicates to the mirror in seconds. There is nothing to restore it from.

Resilience, and its goal of high availability, is about keeping a system operating through component failures. It is achieved by removing single points of failure, so that when one component fails, another carries on and many incidents never become outages. It is built-in tolerance, acting continuously, in advance.

How is it built. First, redundancy: duplicate components, power supplies, network paths, disks, so no single one stops the system.

Second, failover and clustering: a standby component or node takes over automatically when its partner fails.

And third, load balancing and RAID: work is spread across multiple servers so the loss of one is absorbed, and RAID gives disk redundancy so a failed drive does not lose the data or stop the system. A disk dies and its mirror carries on; a server fails and the cluster picks up the load.

Now the crucial point, and the exam loves it. Redundancy is not backup. Redundancy protects against a component failing. It does not protect the data.

Why not. Because redundancy and replication faithfully copy whatever happens to the data, good or bad. If a file is deleted, the deletion replicates. If data is corrupted, the corruption mirrors. If ransomware encrypts the files, the encryption is dutifully written to the redundant copy too, often within seconds. RAID keeps you running when a disk dies; it does nothing when the problem is the data itself.

A backup is different in kind. It is a separate, point-in-time copy that a live change cannot reach. That is exactly what lets you go back to before the deletion or the corruption. So resilience and backup solve different problems, and one never substitutes for the other. When a scenario proposes replacing backups with RAID or replication, that deletion-and-corruption gap is the answer.

The domain also pairs resilience with disaster recovery, and the exam checks you distinguish them. Resilience is built-in tolerance that keeps the system running through a failure, so many incidents never become outages. Disaster recovery, the next lessons, is what restores service after a disruption large enough to overwhelm that tolerance, a site loss, a fire, a major failure.

So the distinction is withstand versus recover. Resilience reduces how often you need to invoke recovery; it does not remove the need for it. A resilient system still needs a D-R plan for the disaster that redundancy cannot absorb, and it still needs backups for the data that redundancy cannot protect.

So carry this away. RAID and replication protect against hardware failure, not against deletion, corruption or ransomware, which propagate to the redundant copy instantly. Only a separate backup can undo those. And resilience, withstanding failure, is not the same as disaster recovery, recovering from it.