1 Overview
A local backup feels like the safest thing you can do. The copy sits on a drive you own, the restore is fast, and nothing depends on an internet connection. That comfort is exactly why local backups become a time bomb. Ransomware and other destructive attacks are built to find and encrypt or delete every copy they can reach, and a backup drive that stays attached to the same machine or network is one of the first things they go after. When the primary data is locked and the local copy is locked with it, the backup has stopped being a backup.
The fix is not to abandon local backups. Fast local restores remain the quickest way to recover a deleted file or roll back a bad update. The fix is to stop treating a single local copy as your whole recovery plan. This article explains what a local-only strategy actually protects against, how to choose a layered approach, how the 3-2-1 rule applies in practice, why restore testing matters more than backup completion, and how offsite storage and encryption close the remaining gaps. The goal is a backup system that survives the same event that takes down your primary data, not one that fails alongside it.
2 What you are actually protecting against
The threats that defeat local-only backups are not exotic. Ransomware is the obvious one. Modern ransomware operators routinely look for connected backup drives, mapped network shares, and backup servers before they trigger encryption. If the backup target is reachable with the credentials of the infected machine, it is in scope. Some strains delete shadow copies and local snapshots first, removing the quick rollback options that many people assume will save them. A backup that is online and writable during an attack is a target, not a safety net.
Beyond ransomware, a local backup shares the fate of the room it lives in. Fire, flood, theft, power surges, and accidental deletion all take out primary and local copy together. Human error is just as serious: a mistaken sync or a misconfigured job can overwrite good backups with corrupted or encrypted data. Hardware failure of the backup drive itself is common, and a single drive with no second copy is a single point of failure. Finally, insider action, whether malicious or careless, can reach any storage the person already has access to. Each of these scenarios has the same shape: the event that destroys your primary data also destroys the local copy, leaving nothing to restore from.
3 Choosing a backup strategy
Start by deciding what you are protecting and how much loss you can tolerate. Not every system needs the same treatment. Critical servers and databases may need frequent backups and a short recovery point objective, meaning little data can be lost between copies. Workstations and archived files can often accept daily or weekly copies. Mapping systems to recovery priorities keeps the plan affordable and prevents the common mistake of backing up everything the same way and then failing to restore the things that matter most.
Next, choose media and locations deliberately. A practical pattern is a fast local copy on separate hardware for quick restores, plus at least one copy that is not reachable from the primary network, plus an offsite copy. The unreachable copy is the key idea: offline, immutable, or air-gapped storage cannot be encrypted or deleted by malware running on your network. Retention should be long enough to reach back past the point where an intrusion began, because attackers often dwell for days or weeks before detonating. Automate the jobs, monitor them, and alert on failures, since an unmonitored backup is only a hope. Document the plan so anyone on the team can execute a restore without guessing.
4 The 3-2-1 rule in practice
The 3-2-1 rule says keep three copies of your data, on two different types of media, with one copy offsite. In practice, that usually means the live data, a local backup on separate hardware, and an offsite copy. The two media types matter because a single failure mode, such as a bad batch of drives or a flawed controller, should not take out every copy at once. The offsite copy matters because it survives events that destroy a building or a network. The rule is a floor, not a ceiling; many teams add a fourth copy that is offline or immutable to blunt ransomware specifically.
Applying it means being honest about what counts as a copy. A snapshot on the same array is not a separate copy. A sync to a folder on the same machine is not a separate copy. A cloud drive that mirrors deletions is not a backup. Each copy should be independently restorable and, ideally, independently protected with its own credentials. Test that the offsite copy can actually be retrieved and that the local copy is not simply a mirror of the primary. When you can point to three genuinely separate copies and explain how each one survives a ransomware event, a fire, and a bad deletion, the rule is doing its job.
5 Restore is the real test
A backup job that reports success proves only that data was written somewhere. It does not prove the data can be read, that the application can start from it, or that the restore finishes inside your recovery time objective. The only meaningful measure is a restore you have actually performed. Schedule regular restore drills: recover individual files, then a full application, then a bare-metal rebuild on clean hardware. Time each one and compare it to your targets. If a restore takes longer than the business can tolerate, the backup is not meeting its purpose no matter how green the dashboard looks.
Stress testing should include hostile conditions. Restore from the offsite copy, not just the local one, to confirm bandwidth, credentials, and procedures hold up. Try restoring to isolated hardware so you are not overwriting the very data you are trying to recover. Verify that encryption keys and passwords are available to the people who need them during an incident, because a perfectly encrypted backup with a lost key is unrecoverable. Check that restores work after the primary environment is gone. Keep a written runbook and rehearse it. The teams that recover quickly are the ones that practiced before the emergency, not the ones that discovered their backup was incomplete while the clock was running.
6 Offsite and encryption
Offsite storage is what keeps a single incident from becoming a total loss. The copy should live somewhere that is not reachable from your production network with normal credentials, so malware cannot traverse to it. Options include a cloud or managed storage service, a colocation facility, or rotated media stored at a separate physical address. Whatever you choose, the offsite copy needs its own access controls, its own retention policy, and a tested path back. If retrieving it requires the same network and accounts that were compromised, it is not truly offsite in any useful sense.
Encryption protects that copy in transit and at rest. Encrypt backups before they leave your control, and manage keys separately from the data they protect. A common failure is storing the encryption key on the same server or in the same account as the backup, which hands an attacker both. Use strong, current encryption and rotate keys on a schedule. Remember that encryption is not a substitute for access control or for keeping an offline copy; it protects confidentiality if media is lost or stolen, but it does not stop a determined attacker who already holds valid credentials. Combine encryption, strict access, immutability where available, and an offline or air-gapped copy so no single compromise defeats the whole chain.
7 Frequently asked questions
Is a local backup useless? No. Local backups are the fastest way to recover from everyday problems like accidental deletion, failed updates, or a single disk failure. They become dangerous only when they are the entire plan, because the same event that destroys primary data can destroy them. Keep the local copy and add offsite and offline protection around it.
How often should I test restores? Often enough that the procedure stays familiar and the results stay trustworthy. A reasonable starting point is restoring sample files monthly, testing a full application recovery quarterly, and rehearsing a bare-metal rebuild at least once or twice a year. Adjust to your recovery time objective and the rate at which your environment changes.
Do I need encryption if the backup never leaves my building? Yes. Media gets lost, stolen, retired, or returned for warranty, and insider access is a real risk. Encrypting backups and managing keys separately limits the damage when a drive goes missing or an account is misused.
What is the single most important change? Make sure at least one copy cannot be reached, altered, or deleted by anything running on your primary network. An offline, immutable, or air-gapped copy is what turns a fragile local backup into a recovery plan that survives ransomware.