Why Theoretical Redundancy Often Fails in Reality
Many companies invest in redundancy. We deploy two firewalls, two internet links, two VPN tunnels, two domain controllers… And on the diagram, everything looks perfectly solid.
Yet, when a real incident occurs, we too often discover that redundancy did not work as intended.
Why? Because in practice, much of this redundancy remains purely theoretical. It exists on paper, but not in reality.
The Most Common Problem: Untested Redundancy
This is the most widespread case.
We configure automatic failover, we place two devices "in high availability", and we consider the matter settled.
Except we have never validated this scenario under real conditions.
Result:
- The failover configuration is incomplete or outdated
- The two devices are not running the same version
- Firewall rules are not properly synchronized
- No one masters the manual failover procedure
Other Forms of Redundancy That Fail
1. Half-Implemented Redundancy
We deploy two firewalls, but only one actually handles critical traffic. We have two internet links, but the second is too slow or poorly configured to ensure effective recovery.
2. Redundancy That Hides Another Single Point of Failure
We have two firewalls in a cluster… that depend on the same core switch. We have two VPN tunnels… that transit through the same operator.
In these cases, we haven’t eliminated the point of fragility: we’ve simply moved it.
3. Outdated Redundancy
Environments evolve constantly. We add applications, we modify flows. But the redundancy configuration is not updated. After a few months, the theoretical failover no longer works.
4. Redundancy Based on Undocumented Procedures
Even with flawless technical infrastructure, if no one knows how to activate failover in an emergency, redundancy remains vulnerable.
How to Build Redundancy That Really Works?
Here are the elements that make the difference:
- Regularly test failover scenarios (even partially)
- Clearly document manual failover procedures
- Verify that both sides are properly synchronized (versions, configurations)
- Identify remaining points of fragility
- Train multiple people on redundancy operations
Many companies believe they are well protected because they have "implemented redundancy". However, the real question is not "have we deployed two devices?", but rather:
In the event of a real problem, are we able to failover quickly and without major impact?
It’s often at the critical moment that we realize redundancy wasn’t as robust as we imagined.