Who this page is for
IT leaders, administrators, executives of smaller companies and anyone who wants an honest view of their recovery capability.
Why backups matter
Backups are often the last line of defence. With ransomware, hardware failure, accidental deletion or misconfiguration they decide whether an incident is resolved in hours or weeks.
The 3-2-1 rule
Three copies of the data on two different media, with one off-site. The rule is old but still solid and can be extended by an extra offline or immutable copy.
Offline and immutable backups
Offline backups are physically or logically disconnected from production after writing.
Immutable backups protect copies against change and deletion for a defined retention. Both make backups much more resistant to ransomware.
Restore tests
A backup never restored is not a proven backup. Regular restore tests verify that data can be brought back within an acceptable window. Only a successful restore proves real resilience.
Backups are not a substitute for prevention
Relying on backups alone means costly recovery with long downtime. Prevention through MFA, patch management and awareness reduces incidents materially.
Checklist
- 3-2-1 rule or better in place
- At least one copy offline or immutable
- Backup accounts separate from production directory
- Regular restore tests with documented results
- RTO and RPO defined
- Backups integrated into incident response plan
Frequently asked questions
+How often should restores be tested?
At least yearly, more often for critical systems. Documenting the outcome matters.
+Are cloud snapshots enough?
They help but do not replace real backups. Anyone who compromises the same tenant can often delete snapshots too.
+Where should backups live?
In a different location and security context than production. Otherwise they share the impact of an incident.
Related topics
Ransomware remains one of the most expensive cyber risks. It is typically the result of a chain of weaknesses rather than a single click. This page covers typical patterns, effective controls and an orderly first response.
A security incident requires a clear process, rehearsed roles and prepared communication. Improvising during an incident wastes time and creates mistakes. This page covers the phases, responsibilities and common pitfalls.
A good incident response plan is short enough to be useful in a crisis and concrete enough to speed up decisions. This page describes a pragmatic structure and typical contents.
Effective enterprise security combines governance with concrete technical and organisational controls. This page shows what decision makers and IT leaders should focus on first - calm, practical and clearly prioritised.
SMEs do not need enterprise security architecture, but they do need the right basics. This page shows which measures deliver the most impact on a limited budget and which common mistakes are easy to avoid.