Backup and fault tolerance of infrastructure
How to protect a business from downtime and data loss with backups, fault tolerance, RPO, RTO, SLA and recovery testing.
Contents
A few hours of infrastructure downtime can cost a business more than its annual protection budget. Let’s clarify the difference between backup and fault tolerance, and how to build infrastructure that survives a failure.
Backup and fault tolerance are not the same
These are two different tasks that are often confused:
- Backup protects against data loss: you have a copy you can restore.
- Fault tolerance protects against downtime: the system keeps working even if some components fail.
One does not replace the other. Backup without fault tolerance is recovery after downtime, not the absence of it.
Key metrics: RPO and RTO
Two metrics define reliability requirements:
- RPO (Recovery Point Objective) — how much data you can afford to lose (say, the last hour).
- RTO (Recovery Time Objective) — how fast the system must recover.
The lower the acceptable RPO and RTO, the more expensive the infrastructure. The goal is to balance them against real business needs.
Principles of reliable infrastructure
- Regular automatic backups with restore testing.
- Storing copies separately from the main system.
- Redundancy of critical components (power, channels, servers).
- Monitoring and incident alerts.
- A recovery procedure proven in practice.
The 3-2-1-1-0 principle is a useful baseline: three data copies, two media types, one off-site copy, one immutable or isolated copy and zero undetected errors after verification. Isolation matters during ransomware incidents because storage reachable from the same administrative domain may be damaged together with production.
Full, incremental and differential backups serve different recovery windows. Choose the mix by data volume, backup window and recovery target. Our comparison of IaaS and an in-house data centre explains the related hosting and responsibility choices.
The role of SLA
An SLA (Service Level Agreement) fixes the provider’s availability guarantees — for example, 99.99%. This is not marketing but a commitment: clarify what exactly the SLA covers and what compensation applies if it’s breached.
A common mistake
The most common mistake is backups that no one has ever restored. A copy you can’t restore from is useless. Restore testing should be a regular procedure, not something you do during an outage.
Conclusion
Reliability combines backup and fault tolerance with clear RPO, RTO and SLA targets. A provider covers only the agreed part of the stack; application redundancy, access control and restore validation often remain customer responsibilities.
A minimum readiness test
Run a recovery exercise for one service, measure actual RPO and RTO, assign an owner to every action and repeat it on a schedule. NIST SP 800-34 Rev. 1 is a useful structural reference for a recovery plan, adapted to your architecture and local requirements.
Repeat testing after migrations, platform updates, access-model changes and serious incidents. For regulated environments, map backup controls and logs to the threat model and the applicable FSTEC requirements.
