Backup Strategy

A resilient backup strategy is the last line of defense against data loss caused by ransomware, hardware failures, natural disasters, human error, data corruption, or malicious attacks that destroy production systems - without adequate backups, an incident that could be resolved with a restore of a few hours can turn into permanent loss of critical data, downtime of days or weeks, and potentially business failure. The fundamental 3-2-1 rule (3 copies of the data, on 2 different types of media, with 1 copy offsite) remains valid but needs to be expanded for modern environments with concepts such as immutable backup for anti-ransomware protection (backups that cannot be deleted or modified, not even by administrators, during the retention period), regular restore tests to validate that backups actually work when needed (many organizations discover that backups are corrupted only when they need them in an emergency), clear definition of RPO (Recovery Point Objective - how much data we can lose, measured in time since the last backup) and RTO (Recovery Time Objective - how long we can stay offline until the system is restored), separation of backup credentials from the main domain to prevent an attacker who compromises Active Directory from also destroying all backups, and automation of backup processes with monitoring and alerts to ensure that backups happen as expected. A common mistake is to treat backup as "set and forget" - backups require continuous attention, validation, updating of procedures as infrastructure evolves, and above all: an organizational culture that values data protection as much as the production of new features.

3-2-1 Rule: Redundancy Fundamentals

The 3-2-1 rule establishes that you should keep 3 copies of your data (production + 2 backups), on 2 different types of storage media, with 1 copy offsite, geographically separated. For example: production data on a SAN (Storage Area Network), primary backup on a NAS (Network Attached Storage) in the same datacenter, and secondary backup on cloud storage (S3, Azure Blob) in a different region. Media diversity protects against technology-specific failures - if you have all backups on magnetic tapes and discover that your tape drive has stopped working, you may be unable to restore even though you have the tapes. The offsite copy protects against localized disasters (fire, flood, theft, physical attack on the datacenter) - if all backups are in the same building that burned down, you have lost everything. The modern evolution of 3-2-1 is 3-2-1-1-0: 3 copies, 2 media, 1 offsite, 1 immutable, 0 errors (validated by restore tests). To implement: configure backup software (Veeam, Commvault, Bacula, Acronis, AWS Backup, Azure Backup) to create daily snapshots of critical systems, replicate those backups to local storage (first copy), send a copy to the cloud (second offsite copy), and mark cloud copies as immutable with Object Lock (S3) or Immutable Blobs (Azure). Calculate the required storage based on: data size × retention period × change rate - if you have 10TB of data, want to retain backups for 30 days, and 10% of the data changes daily, you will need approximately 10TB + (10TB × 0.1 × 30) = 40TB of storage for backups. Use deduplication and compression to reduce costs, but be careful with crypto ransomware that can make data appear random and reduce dedupe efficiency.

Immutable Anti-Ransomware Backup

Modern ransomware not only encrypts production data but actively searches for and destroys backups to maximize pressure on the victim to pay the ransom - attackers use compromised administrative credentials to delete snapshots, disable backup services, corrupt backup catalogs, and even encrypt the backups themselves. Immutable backup (also called WORM - Write Once Read Many, or air-gapped backup) prevents this by making backups impossible to delete or modify during the defined retention period, even by administrators with maximum privileges. Implementations: AWS S3 Object Lock in Compliance mode (not even the root account can delete objects before the expiration date), Azure Blob Immutable Storage with legal hold or time-based retention policies, tape backups physically removed and kept in an offsite vault, and backup appliances with WORM mode (Dell EMC Data Domain, Cohesity). Configure an appropriate retention period - usually 30-90 days depending on your RPO and how long you need to keep historical versions. IMPORTANT: immutability prevents deletion but does not prevent the creation of new corrupted backups - if an attacker compromises a system for weeks before triggering ransomware, your immutable backups may contain already-infected data. Solution: keep multiple versions of backups (not just the most recent), use backup validation that detects anomalies in the data (a sudden increase in entropy may indicate encryption), and consider a physical "air gap" where backups are periodically copied to storage completely disconnected from the network. Test recovery of immutable backups regularly, since some systems have bugs where immutability prevents even legitimate restore operations.

Restore Tests and Validation

An untested backup is an unreliable backup - there are countless documented cases of companies that performed backups religiously for years and discovered during disaster recovery that backups were corrupted, the configuration was wrong, the media was degraded, or the restore process simply did not work. Implement a formal backup testing program: a full production restore in a test environment monthly (full system restore), a restore of critical VMs/databases weekly (partial restore), and validation of backup job logs daily (verifying that backups completed without errors). Automate tests using scripts that: start a restore in an isolated environment, verify the integrity of the restored data (checksums, database consistency checks), measure restore time (validating whether you can meet RTO), and generate reports with metrics. For databases, use the DBMS's own backup restore validation: SQL Server RESTORE VERIFYONLY, MySQL mysqlcheck, PostgreSQL pg_restore --list. For application backups, restore and run automated smoke tests that verify critical functionality. Document each test: date, systems tested, result (success/failure), elapsed time, issues found, and corrective actions. Treat restore test failures as P0 incidents - if a backup test fails, you assume you do not have a functional backup until you fix it. Consider running "surprise restore drills" where you tell the team without notice that they need to restore system X within Y hours, simulating a real emergency. In addition to validating backups, these drills train the team in recovery procedures and identify gaps in documentation or automation.

RPO and RTO: Defining Recovery Objectives

RPO (Recovery Point Objective) is the maximum amount of data you can lose, measured in time - if your RPO is 4 hours, you need to perform backups at least every 4 hours, and in case of a disaster you may lose up to 4 hours of transactions. RTO (Recovery Time Objective) is the maximum time a system can be offline until it is restored - if your RTO is 2 hours, you have 2 hours from detection of the incident until the system is operational again. RPO and RTO must be defined by business requirements (how much lost data and downtime the business tolerates) and dictate the backup architecture: critical tier-1 applications may require RPO=0 (zero data loss via synchronous replication) and an RTO of minutes (high availability cluster), tier-2 applications may tolerate RPO=1h (hourly incremental backups) and RTO=4h, tier-3 applications may have RPO=24h (nightly backups) and RTO=8h. Calculate cost vs. risk: a smaller RPO requires more frequent backups (more storage, more performance overhead), a smaller RTO requires more sophisticated recovery systems (hot standby, automated failover). Example architecture for different tiers: Tier-1 (ERP, Payment Processing) - synchronous replication to a DR site + 15-min snapshots + daily immutable backup, RPO under 15 min, RTO under 1h; Tier-2 (CRM, Email) - hourly incremental backups + daily full backup, RPO=1h, RTO=4h; Tier-3 (File Shares, Logs) - daily backup, RPO=24h, RTO=8h. Document RPO/RTO for each system in the Disaster Recovery Plan, obtain sign-off from business stakeholders (to ensure alignment of expectations), and monitor whether you can meet the defined objectives (track actual recovery times in incidents).

Separation of Backup Credentials

An attacker who compromises Active Directory with Domain Admin privileges can potentially access and destroy all backups if the backup system uses credentials from the same AD - this is a common vector in ransomware attacks where the attacker first establishes persistence in AD, then maps out the entire backup infrastructure, and finally destroys backups before triggering encryption. Mitigate with credential segregation: create a separate domain or standalone workgroup for the backup infrastructure, use local service accounts instead of domain accounts where possible, configure backup appliances with their own authentication independent of AD, implement MFA for access to the backup console and storage, and use API keys with restricted permissions for cloud backups instead of credentials with broad access. For Veeam environments, implement a "hardened Linux repository" where the backup server is Linux (outside the Windows AD), accessible only via SSH with key-based auth and with no possibility of deleting backups via the Veeam console (immutability enforced at the Linux filesystem level). For AWS backups, use a cross-account backup vault where backups are sent to a separate AWS account controlled by a different team with non-shared credentials, and configure Vault Lock to prevent deletion. Apply the principle of least privilege: the account that performs backups only needs read access in production and write access in the backup destination, it does not need delete permissions. Monitor access to the backup infrastructure as a high-value target - any access attempt outside of backup windows or from unexpected IPs should generate a security alert. In extreme cases, consider an "offline backup admin" where backup administration credentials do not exist in digital form - they are stored in a physical vault and only accessed in emergencies.