What is Backup and Recovery in Cybersecurity?

The 3-2-1 Backup Rule and Why It Matters in Ransomware

The 3-2-1 backup rule is the foundational backup strategy: maintain 3 copies of data, on 2 different media types, with 1 copy offsite. In the ransomware era, this rule has been extended to 3-2-1-1-0: 3 copies, 2 media types, 1 offsite, 1 offline (air-gapped or immutable), and 0 errors (backups are tested and verified). The offline or immutable component is the critical addition that ransomware has made necessary.

Ransomware specifically targets backup systems. Modern ransomware operators understand that organizations with good backups can recover without paying — so they prioritize identifying and encrypting or deleting backups before deploying the primary encryption payload. Ransomware that can reach backup storage through network connections will encrypt backup files alongside primary data. Backups that are immutable — where the data cannot be modified or deleted once written, enforced by the storage system itself rather than access controls that an attacker with compromised credentials can bypass — survive ransomware because the attacker cannot modify them regardless of the credentials they have obtained.

Backup Testing: The Critical Gap

A backup that has never been tested is a backup that may not work when needed. Backup failures — corrupted backup jobs, incomplete coverage, restoration procedures that do not function at scale — are discovered at the worst possible time: during ransomware recovery when the organization is already under maximum operational stress.

Recovery testing validates not just that backup data exists and is uncorrupted, but that the recovery process actually works end-to-end: the restoration procedures are documented and executable, the time required to restore systems at realistic scale matches the recovery time objective, and the restored data is usable — application configuration, database schema, and system dependencies are captured along with data. Table-based recovery tests — verifying that backup jobs complete successfully — are necessary but not sufficient. Practical recovery exercises that restore actual systems and validate functionality against known-good state provide the only reliable assurance that backup and recovery will function when needed.

Backup Architecture for Ransomware Resilience

Ransomware-resilient backup architecture combines multiple complementary capabilities. Frequency — backup intervals that limit maximum data loss to an acceptable recovery point objective. Immutability — backup storage that cannot be modified or deleted by even a fully compromised administrative account. Segmentation — backup infrastructure that is on a separate network segment not reachable from the primary environment, limiting ransomware's ability to reach backup systems. Encryption — backup data encrypted at rest to prevent the backup system from becoming a secondary source of data exfiltration. And offsite or cloud storage that ensures a physical failure or facility loss does not destroy all backup copies simultaneously.

Microsoft 365 cloud data is frequently misunderstood as automatically backed up by Microsoft. Microsoft maintains infrastructure availability and geo-redundancy, but it does not provide data backup in the traditional sense. Deleted Microsoft 365 data is recoverable within defined retention windows (typically 30-93 days for various item types), but items deleted outside those windows are gone. Malicious deletion of email, files, or Teams data by an attacker with access to the Microsoft 365 tenant may not be recoverable from Microsoft's retention if the deletion is not discovered within the retention window. Third-party Microsoft 365 backup solutions provide true backup capability for Microsoft 365 data.

Real-World Example: City of Baltimore — $18M Because Backups Weren't Tested

In May 2019, Baltimore's municipal government was hit by RobbinHood ransomware that encrypted thousands of government computers and demanded approximately $76,000 in Bitcoin. Baltimore refused to pay. The recovery cost approximately $18 million in IT remediation and lost or deferred revenue — over 200 times the ransom demand. A significant portion of this cost was attributable to inadequate backup coverage for critical systems and the absence of tested recovery procedures. Some systems took months to restore because the backup data existed but the restoration procedures had never been tested and did not function as expected. The ransom would have been the cheaper option; tested backups would have been cheaper still.