1 Overview
Ransomware does not simply encrypt the files on your laptop. Modern attacks move laterally through a network, locate shared drives, and hunt for the backup server itself. If your only protection is a copy that lives on the same network, the same domain, and the same set of credentials, the attacker can encrypt or delete it before you ever notice the intrusion. An offline copy is the difference between a bad week and a business-ending event.
This article explains why backup software alone is not enough and how to build a recovery plan that survives a determined attacker. The focus is on the 3-2-1 rule, recovery point and recovery time objectives, restore testing, and encryption. The goal is practical: help you design a backup system that still works when your primary environment is compromised, and help you prove it works before you need it.
Backups are not a product you buy once and forget. They are a process you operate, verify, and improve. The sections below walk through the threat, the strategy, the rule, the test, and the safeguards that keep your copies trustworthy.
2 What you are actually protecting against
Ransomware operators rarely strike in a single moment. They often gain access through phishing, exposed remote services, or stolen credentials, then spend days or weeks mapping the environment. During that time they look for backup repositories, catalog servers, and administrative accounts. If they can reach your backups with the same privileges they used to reach production, your recovery options disappear along with your data.
Other threats matter too. A fire, flood, or power event can destroy on-site hardware. A tired administrator can delete the wrong volume. A failed software update can corrupt a database. A disgruntled insider can wipe a share. Each of these scenarios has the same lesson: a copy that is always mounted, always writable, and always reachable is a copy that can be lost in the same incident as the original.
The core principle is separation. Your backup copy should not share fate with the system it protects. It should not be reachable using the same credentials, it should not be writable by normal accounts, and it should not depend on the same physical location. When you design around that principle, you protect against ransomware and against ordinary accidents at the same time.
3 Choosing a backup strategy
Start by defining what matters. Identify the systems whose loss would stop the business, then rank them by how quickly they must return and how much data you can afford to lose. Those two numbers, the recovery time objective and the recovery point objective, drive every other decision. A database that must be current within fifteen minutes needs a different approach than an archive of last year's contracts.
Next, choose a mix of backup types. Full backups give you a complete, self-contained copy. Incremental backups capture changes since the last run and are faster and smaller. Differential backups capture changes since the last full backup and sit between the two. Synthetic fulls combine existing data to create a new full without re-reading the source. A common pattern is periodic fulls with frequent incrementals, plus a separate archive copy for long-term retention.
Finally, decide where each copy lives and who can touch it. Production storage is convenient but fragile. A second media type, such as tape or object storage, adds resilience. An offline or immutable copy adds protection against deletion and encryption. Document the schedule, the retention window, and the owner for every copy. A strategy that exists only in someone's head is not a strategy.
4 The 3-2-1 rule in practice
The 3-2-1 rule says keep at least three copies of your data, on two different media types, with one copy offsite or offline. It is simple, old, and still one of the most reliable guides in backup planning. Three copies means the original plus two backups, so a single failure or a single corrupted copy does not end the story. Two media types means you are not betting everything on one technology, one controller, or one failure mode.
The third element is the one people skip. An offline copy is disconnected from the network, or stored in a repository that cannot be altered or deleted for a set period. Immutability and object lock features can enforce this, and so can tape that is physically removed and stored elsewhere. The key property is that an attacker with domain administrator credentials still cannot reach in and destroy it.
In practice, a small organization might keep production data on primary storage, nightly backups on a separate backup appliance, and a weekly copy on tape or in an isolated cloud bucket with immutability enabled. A larger organization might add replication between sites and a vault that requires separate credentials and multi-person approval to modify. The exact design varies, but the test is always the same: if the production network is fully compromised, does at least one copy survive untouched?
5 Restore is the real test
A backup that has never been restored is a hope, not a safeguard. Backups fail for many reasons: a job silently stops running, a database is backed up while inconsistent, a credential expires, a tape is unreadable, or a retention policy deletes the wrong set. None of these problems appear in a green status dashboard. They appear when you try to recover.
Build a restore testing schedule and treat it as seriously as the backup schedule itself. Test single-file restores regularly, since they are quick and catch catalog and permission problems. Test full system restores less often but on a realistic scale, including booting the recovered machine and confirming that applications and databases start correctly. Measure how long each restore actually takes and compare it with your recovery time objective. If the numbers do not match, fix the plan before an incident forces the issue.
Document the results, including what failed and what you changed. Keep the runbook current so that someone other than the original author can perform a recovery. Stress testing under realistic conditions, such as restoring to different hardware or with limited bandwidth, exposes assumptions that a quiet lab test will miss. The goal is confidence backed by evidence, not confidence backed by optimism.
6 Offsite and encryption
Offsite storage protects against events that destroy a location, and it also creates distance between production and your last line of defense. The copy can live in a cloud region, a colocation facility, or a safe with rotated media. Whatever the choice, verify that the offsite copy is genuinely isolated. A cloud bucket reachable with the same identity provider and the same administrator account as production is not isolated in any meaningful sense.
Encryption protects data in transit and at rest, and it matters for both privacy and integrity. Use strong, current algorithms and manage keys separately from the backups themselves. If the encryption key is stored on the same server as the backup, an attacker who compromises that server can decrypt everything. Consider key escrow, hardware security modules, or a separate key management process with strict access controls. Test that you can actually restore using only the escrowed keys.
Encryption also interacts with retention and legal obligations. Some data must be kept for years, and some must be destroyed on a schedule. Make sure your key management and retention policies agree, and that deleted data is genuinely unrecoverable. Combine encryption with immutability and offline storage, and you have a layered defense: even if one control fails, the others still stand between an attacker and your ability to recover.
7 Frequently asked questions
How many backup copies do I really need? The 3-2-1 rule is a floor, not a ceiling. Three copies on two media with one offline covers most small and mid-sized environments. If your data is regulated, highly valuable, or difficult to recreate, add copies and shorten your backup intervals. The right number is the one that lets you meet your recovery objectives after a realistic failure.
How often should I test restores? Test file-level restores monthly and full system restores at least quarterly, or more often if your environment changes frequently. Every test should record the time taken, the steps followed, and any problems found. If a test fails, treat it as a production incident and fix the root cause.
Does encryption slow down backups? It adds some processing overhead, but modern hardware handles it well. The bigger risk is losing the keys. Store them separately, restrict access, and verify that recovery works with only the escrowed material.
Can cloud storage replace offline copies? Not by itself. Cloud storage is convenient and resilient, but it is reachable if credentials are stolen. Use immutability, object lock, and separate accounts to create a genuine offline equivalent, and keep at least one copy that no production credential can delete.