Ransomware has transformed backup from an IT operational concern into a critical security control. This guide covers modern backup strategies designed to survive destructive attacks and enable rapid recovery.
The ransomware backup challenge
Why traditional backups fail
| Attack technique | Impact on backups |
|---|
| Backup deletion | Attackers target backup systems first |
| Encryption of backups | Backups unusable without key |
| Credential theft | Admin access to backup infrastructure |
| Extended dwell time | Backups contain only infected data |
| Cloud sync exploitation | Ransomware syncs to cloud backups |
Modern backup requirements
| Requirement | Purpose |
|---|
| Immutability | Cannot be modified or deleted |
| Air gap | Network isolation from production |
| Rapid recovery | Minimize downtime |
| Integrity verification | Ensure backups are clean |
| Retention depth | Recover from extended compromises |
The 3-2-1-1-0 backup rule
Evolution from 3-2-1
| Rule | Meaning |
|---|
| 3 | Three copies of data |
| 2 | Two different media types |
| 1 | One copy offsite |
| 1 | One copy immutable/air-gapped |
| 0 | Zero errors after verification |
Implementation example
| Copy | Location | Type |
|---|
| Production | Primary storage | Live data |
| Local backup | On-premises backup system | Near-line |
| Cloud backup | Cloud provider | Offsite |
| Immutable copy | Air-gapped or immutable cloud | Protected |
Immutable backup strategies
Immutability options
| Method | Implementation |
|---|
| WORM storage | Write-once, read-many media |
| Object lock | Cloud provider immutability |
| Air gap | Physical or logical isolation |
| Backup appliance | Vendor-enforced immutability |
| Tape | Physical offline storage |
Cloud immutability
| Provider | Feature |
|---|
| AWS S3 | Object Lock (Governance/Compliance) |
| Azure Blob | Immutable storage |
| Google Cloud | Bucket Lock |
| Backblaze B2 | Object Lock |
Object Lock modes
| Mode | Characteristics |
|---|
| Governance | Can be overridden with special permissions |
| Compliance | Cannot be overridden by anyone, including root |
Recommendation: Use Compliance mode for ransomware protection—Governance mode can be bypassed by compromised admin accounts.
Air-gapped backup architecture
Physical air gap
| Component | Implementation |
|---|
| Tape library | Offline tape storage |
| Removable media | Rotated offsite |
| Isolated network | No connectivity to production |
| Manual transfer | Sneakernet for critical data |
Logical air gap
| Component | Implementation |
|---|
| Separate credentials | Unique accounts for backup |
| Network segmentation | Firewall isolation |
| Unidirectional gateway | Data diode |
| Pull-based replication | Backup system initiates |
Hybrid approach
| Tier | Method | Recovery time |
|---|
| Tier 1 | Online immutable | Hours |
| Tier 2 | Isolated network | Hours-days |
| Tier 3 | Offline/tape | Days |
Backup infrastructure security
Credential protection
| Control | Implementation |
|---|
| Separate accounts | Backup-only credentials |
| MFA required | Hardware tokens preferred |
| No domain join | Standalone or separate domain |
| Privileged access | PAM for backup admin |
| Service accounts | Managed, rotated |
Network security
| Control | Implementation |
|---|
| Dedicated VLAN | Isolated backup network |
| Firewall rules | Minimum required ports |
| No internet access | Air-gapped from internet |
| Encrypted transit | TLS for all backup traffic |
| Microsegmentation | Limit lateral movement |
Access control
| Principle | Implementation |
|---|
| Least privilege | Role-based access |
| Separation of duties | Multiple approvers for delete |
| Just-in-time access | Temporary elevation |
| Audit logging | All access logged |
| Alerting | Unusual activity notifications |
Recovery time objectives
RTO/RPO definitions
| Term | Definition |
|---|
| RTO | Recovery Time Objective - acceptable downtime |
| RPO | Recovery Point Objective - acceptable data loss |
Tiered recovery
| Tier | Systems | RTO | RPO |
|---|
| 1 | Critical business | <4 hours | <1 hour |
| 2 | Important | <24 hours | <4 hours |
| 3 | Standard | <72 hours | <24 hours |
| 4 | Archive | >72 hours | <7 days |
Recovery capability testing
| Test type | Frequency |
|---|
| Backup verification | Daily (automated) |
| File restore | Weekly |
| System restore | Monthly |
| Full DR exercise | Annually |
| Tabletop exercise | Quarterly |
Ransomware recovery planning
Pre-incident preparation
| Task | Purpose |
|---|
| Document recovery procedures | Step-by-step guides |
| Identify critical systems | Prioritize recovery order |
| Test restore procedures | Validate capability |
| Store procedures offline | Accessible during incident |
| Establish clean room | Isolated recovery environment |
Recovery decision tree
| Scenario | Action |
|---|
| Immutable backup available | Restore from clean backup |
| Unknown infection date | Restore oldest clean backup |
| All backups encrypted | Engage recovery specialist |
| Cloud sync infected | Restore from versioning |
Clean room recovery
| Requirement | Purpose |
|---|
| Isolated network | Prevent reinfection |
| Clean media | Known-good OS images |
| Verified tools | Integrity-checked utilities |
| Fresh credentials | New accounts, no reuse |
| Staged restoration | Verify before reconnecting |
Cloud backup considerations
SaaS backup (M365, Google Workspace)
| Challenge | Solution |
|---|
| Limited native retention | Third-party backup |
| Ransomware sync | Point-in-time recovery |
| Accidental deletion | Extended retention |
| Compliance requirements | Immutable archive |
SaaS backup vendors
| Vendor | Key features |
|---|
| Veeam | Broad coverage |
| Druva | Cloud-native |
| Commvault | Enterprise |
| Spanning | Google focus |
| Backupify | M365/Google |
IaaS/PaaS backup
| Platform | Native options |
|---|
| AWS | EBS Snapshots, AWS Backup |
| Azure | Azure Backup, Site Recovery |
| GCP | Persistent Disk Snapshots |
Backup testing and validation
Automated verification
| Test | Frequency |
|---|
| Backup completion | Every job |
| Checksum validation | Every job |
| Restore test (sample) | Daily |
| Malware scan of backups | Daily |
| Integrity verification | Weekly |
Manual testing
| Test | Frequency |
|---|
| Single file restore | Weekly |
| Application restore | Monthly |
| Full system restore | Quarterly |
| DR failover | Annually |
Testing documentation
| Document | Content |
|---|
| Test plan | Scope, objectives, schedule |
| Test results | Pass/fail, timing, issues |
| Lessons learned | Improvements needed |
| Updated procedures | Revised based on testing |
Metrics and reporting
Backup health metrics
| Metric | Target |
|---|
| Backup success rate | >99% |
| RPO compliance | 100% |
| Backup window | Within schedule |
| Storage utilization | <80% |
| Restore success rate | >99% |
Recovery metrics
| Metric | Measurement |
|---|
| Actual RTO | Time to recover |
| Actual RPO | Data loss in recovery |
| Recovery reliability | Successful restores |
| Mean time to recover | Average recovery time |
Vendor selection criteria
Key capabilities
| Capability | Importance |
|---|
| Immutability support | Critical |
| Air gap options | Critical |
| Ransomware detection | High |
| Rapid recovery | High |
| Cloud integration | High |
| Compliance features | Medium |
Leading vendors
| Vendor | Strength |
|---|
| Veeam | Versatility, immutability |
| Rubrik | Zero trust, simplicity |
| Cohesity | Data management |
| Commvault | Enterprise, compliance |
| Druva | Cloud-native |
| Veritas | Legacy integration |
| Dell/EMC | Hardware integration |
Implementation roadmap
Phase 1: Assessment (Month 1)
| Task | Deliverable |
|---|
| Data classification | Criticality tiers |
| Current state analysis | Gap identification |
| RTO/RPO requirements | Business alignment |
| Vendor evaluation | Shortlist |
Phase 2: Design (Month 2)
| Task | Deliverable |
|---|
| Architecture design | 3-2-1-1-0 implementation |
| Security controls | Access, network, encryption |
| Recovery procedures | Documented runbooks |
| Testing plan | Validation schedule |
Phase 3: Implementation (Month 3-4)
| Task | Deliverable |
|---|
| Deploy backup infrastructure | Production ready |
| Configure immutability | Verified protection |
| Implement monitoring | Alerting active |
| Train staff | Operational capability |
Phase 4: Validation (Month 5-6)
| Task | Deliverable |
|---|
| Recovery testing | Verified RTO/RPO |
| DR exercise | Full failover test |
| Documentation | Complete runbooks |
| Continuous improvement | Ongoing optimization |
Key takeaways
- Immutability is mandatory - Backups attackers can delete are worthless
- Air gap critical data - Network isolation prevents ransomware reach
- Test recovery regularly - Untested backups are hopes, not plans
- Separate credentials - Backup systems need unique admin accounts
- Extend retention - Long dwell times require deep recovery points
- Verify integrity - Scan backups for malware before restore
- Document everything - Procedures must be accessible during crisis
Backup is your last line of defense against ransomware. Design it assuming attackers will target it specifically—because they will.
