Why Backups Are Your Last Line of Defense Against Ransomware
Ransomware is straightforward in concept and devastating in practice. An attacker gains access to your environment, deploys software that encrypts your files, and presents you with a demand: pay, or lose your data. The entire leverage of the attack rests on one assumption: that you don’t have a clean copy of your data that you can restore from.
A properly designed backup strategy removes that leverage entirely. It doesn’t prevent the attack, but it determines whether the attack succeeds.
Why Most Backups Fail Against Ransomware
The existence of a backup doesn’t guarantee a successful recovery. Ransomware operators are well aware that businesses keep backups, and modern ransomware is specifically designed to find and encrypt them along with everything else. A backup stored on the same network as your primary data, accessible through the same credentials, is not a backup in any meaningful sense. It’s a second copy of the same liability.
Beyond targeted destruction, there’s the problem of timing. Ransomware frequently sits dormant in an environment for days or weeks before triggering, quietly replicating across systems and sometimes infecting backup sets in the process. By the time encryption occurs, your most recent backups may already be compromised. The clean restore point may be older than you expect, and restoring from it means accepting a corresponding amount of data loss.
There’s also the question of whether backups have been tested. A backup that has never been restored from is a backup of unknown reliability. The only way to know whether your recovery process works is to run through it before you need it, under controlled conditions, not under the pressure of an active incident.
What Ransomware-Resistant Backups Look Like
Immutability is the most important property of a ransomware-resistant backup. An immutable backup, once written, cannot be modified or deleted, even by someone with administrative access to your systems. Ransomware that encrypts everything it can reach cannot touch an immutable backup stored in a location it can’t access with the credentials it has compromised.
The 3-2-1 rule remains a sound baseline for backup architecture: three copies of your data, on two different types of media, with one copy stored offsite. In practice, this often means a local backup for fast recovery, a secondary copy on a separate system or appliance, and a third copy replicated to an offsite or cloud location. Each layer serves a different purpose, and the combination ensures that no single failure, whether hardware, ransomware, or physical disaster, takes all copies simultaneously.
Frequency matters too. A backup that runs once a day means your maximum potential data loss is 24 hours of work. For some businesses that’s acceptable. For others, particularly those processing transactions or updating records continuously, it isn’t. Recovery Point Objective, the maximum acceptable data loss, should drive backup frequency, not the other way around.
Microsoft 365 and Google Workspace Are Not Backed Up by Default
This surprises many business owners. Microsoft and Google maintain the infrastructure that runs their platforms, but they are not responsible for backing up your data in a way that supports point-in-time recovery. Their retention and recycle bin features provide limited protection against accidental deletion, but they are not a substitute for a proper backup.
If a ransomware attack compromises your Microsoft 365 tenant, or if a departing employee deletes files before leaving, or if data is corrupted through a third-party integration, the recovery options available through Microsoft or Google alone may be insufficient. A separate backup of your cloud data, maintained independently of the platform itself, closes that gap.
Recovery Is the Goal, Not Just Protection
The purpose of a backup is recovery. That sounds obvious, but it has practical implications for how backups are designed and tested. A backup that protects your data but takes three days to restore from may not meet your business needs, even if it’s technically sound. Recovery time should be defined, planned for, and tested as a core part of your backup strategy.
When a ransomware incident occurs, the businesses that recover quickly and with minimal data loss are the ones that made deliberate decisions about their backup architecture before the attack happened. The ones that struggle are the ones that assumed their backups would work without ever verifying it.