1 Overview
Local backups have been declared obsolete so many times that the obituary has become a genre. The argument usually goes like this: cloud storage is cheap, always available, and managed by someone else, so why bother with a drive sitting on your desk? The argument is not wrong about the convenience of cloud services, but it mistakes convenience for completeness. A local backup is not a replacement for offsite protection. It is the first line of defense, the copy that is closest to you when something goes wrong and the one you can reach without a network connection, a subscription, or a vendor's permission.
The case for local backups rests on three properties that matter during an actual incident: speed, control, and independence. A directly attached drive or a device on your own network can move data far faster than most internet connections, which shortens the window between deciding to restore and actually working again. You control the hardware, the schedule, and the retention policy, so nothing changes underneath you because a provider updated a tier or a terms-of-service page. And because the copy is physically present, it keeps working when the internet does not, when a provider has an outage, or when an account is locked.
This article treats local backup as a discipline rather than a product category. The goal is to help you decide what to protect, how often to copy it, how long to keep versions, and how to prove the copies are usable. The recurring theme is that a backup you have never restored is a hypothesis, not a safeguard. Local copies make that testing cheap and fast, which is exactly why they belong at the front of your strategy rather than the back.
2 What you are actually protecting against
Backup planning goes wrong when it starts from a product rather than a threat. Before choosing drives or schedules, name the failures you are defending against, because different failures demand different copies. The most common is simple human error: a deleted file, an overwritten document, a botched edit, or a misconfigured script that wipes a directory. These incidents are frequent, usually small, and best solved by a recent local copy that can be restored in minutes without touching the network.
The second category is hardware and media failure. Drives wear out, controllers fail, power supplies die, and filesystems become corrupt. A local backup on separate hardware survives the death of the primary disk, and it does so without depending on an internet connection or a remote service being reachable. The third category is malicious or accidental destruction at a larger scale: ransomware, malware, a destructive command run with elevated privileges, or a fire, flood, or theft that takes out the whole room. These events are where a local-only strategy breaks down, because anything attached to the machine or sitting in the same building can be encrypted, erased, or carried away along with the original.
The fourth category is quieter: silent corruption and slow drift. A file can be damaged for months before anyone notices, and by then every recent copy may contain the same damage. This is why retention depth matters as much as frequency. Keeping older restore points gives you a chance to reach back before the corruption began. Naming these threats first turns backup from a vague good intention into a set of concrete requirements: fast local recovery for small mistakes, independent hardware for device failure, an offsite copy for site-wide disasters, and enough history to escape damage that spreads slowly.
3 Choosing a backup strategy
A workable strategy answers four questions: what, how often, how long, and where. Start with what you are protecting. Separate irreplaceable data, such as documents, source code, photographs, and databases, from replaceable material like operating system files and installed applications that can be reinstalled. Irreplaceable data deserves the most frequent copies and the deepest retention. System state deserves at least one image so you can rebuild a machine without a manual reinstall, but it does not need a new copy every hour.
How often you copy is governed by how much work you are willing to redo. That is the recovery point objective in plain language: if you copy once a day, you accept losing up to a day of changes. If that is too much, shorten the interval or add a continuous local copy for the files that change constantly. How long you keep copies is governed by how far back you might need to reach. A rolling window of daily versions plus weekly and monthly restore points covers most small operations without filling every drive you own. Prune old versions deliberately rather than letting storage fill until backups start failing silently.
Where the copies live is the last decision, and it should not be the same place as the original. Use a separate physical device: an external drive that is disconnected when not in use, or a network-attached storage device on a different machine. Disconnecting matters, because storage that is always mounted is exposed to whatever damages the primary system. Finally, write the plan down in one page: what is copied, when, where it lands, how long it is kept, and who checks it. A strategy that exists only in your head cannot be audited, handed over, or improved.
4 The 3-2-1 rule in practice
The 3-2-1 rule is the durable shorthand for resilient backup: keep at least three copies of your data, on two different kinds of media, with one copy stored offsite. It survives because it encodes independence. Three copies mean no single failure is fatal. Two media types mean a flaw in one technology, such as a failing drive model or a filesystem bug, does not take out every copy at once. One offsite copy means a fire, flood, theft, or local ransomware outbreak cannot reach all of your history.
In practice, a small organization might run a local image on an external drive, a second local copy on a network-attached storage device, and a third copy in cloud or removable storage kept at another location. A home user might keep one copy on an external drive, one on a second drive stored elsewhere in the building, and one encrypted copy in a cloud account. The exact hardware matters less than the separation. If all three copies sit on the same desk, plugged into the same machine, and share the same power strip, you have one copy with extra steps.
The rule is a floor, not a ceiling, and it needs maintenance to stay true. Rotate removable drives so the offsite copy is actually current rather than a snapshot from last year. Verify that the two media types are genuinely different, not two identical drives from the same batch. Confirm that the offsite copy is encrypted and that you hold the key. Recheck the plan whenever you add a device, change jobs, or move. The value of 3-2-1 is that it forces you to ask, for every copy, what single event could destroy it, and then to make sure no single event can destroy all of them.
5 Restore is the real test
A backup that has never been restored is an assumption. The only way to convert it into a safeguard is to perform restores on purpose, before you need them, and to treat the results as the real measure of your strategy. A restore test answers questions that backup logs cannot: Does the archive open? Are the files complete? Do permissions and ownership survive? Can the application actually start from the recovered data? Does the process fit inside the time you promised?
Start small and make it routine. Once a month, pick a handful of files from an older restore point and recover them to a scratch location, then open them and confirm the contents are what you expect. Once a quarter, go further: restore a full system image to spare hardware or a virtual machine and boot it. This is the step most people skip, and it is the step that exposes missing drivers, broken boot records, forgotten encryption passphrases, and archives that were silently truncated. Document how long each test took, because that number is your realistic recovery time, not the estimate in the plan.
Stress testing should include the awkward cases. Try restoring when the primary machine is unavailable, using only the local drive and whatever tools you would really have. Try restoring from the offsite copy to confirm the transfer path and the decryption key work. Try recovering a version from several weeks back to prove your retention depth is real. Keep a short log of each test with the date, what was restored, how long it took, and what failed. Then fix the failures while the stakes are low. The organizations that recover calmly are rarely the ones with the most elaborate tools; they are the ones that practiced until the procedure was boring.
6 Offsite and encryption
Local backups are fast and controllable, but they share a fate with the place they live. A fire, a flood, a burglary, or a ransomware infection that spreads across mounted drives can destroy the original and every local copy in one event. That is why the offsite copy is not optional. It can be a removable drive rotated to another building, a cloud storage account, or a replicated device at a second site. What matters is that it is physically or logically separated from the primary location and updated often enough to be useful.
Encryption protects the copies wherever they travel. Data at rest on a portable drive is easy to lose and easy to read if it is not encrypted, and data moving to a remote service crosses networks you do not control. Encrypt backups before they leave the machine, use strong modern ciphers, and manage keys deliberately. A common failure is encrypting the backup and then storing the passphrase only in a note on the machine being backed up, which defeats the purpose. Keep the key somewhere separate and recoverable, and make sure at least one other trusted person can reach it if you are unavailable.
Encryption also changes how you test. A restore test must include decryption, because a key that no longer works is indistinguishable from a backup that does not exist. Store the key material in a password manager or a sealed physical location, document the recovery procedure, and rehearse it during your restore drills. Balance is the goal: local copies give you speed and independence, the offsite copy gives you survival, and encryption keeps both from becoming a liability. Together they turn a pile of drives into a strategy you can rely on when the worst day arrives.
7 Frequently asked questions
Is a local backup still worth the effort when cloud storage is so cheap? Yes, because the two solve different problems. Cloud copies are excellent for surviving local disasters and for reaching data from anywhere, but they depend on a working internet connection, an active account, and a provider. A local copy restores quickly, works offline, and stays under your control. The strongest setups use both rather than choosing one.
How often should I back up? Match the interval to how much work you can afford to redo. If losing a day of changes is acceptable, a daily copy is enough. If not, shorten the interval or add continuous local copying for the files that change most. Then confirm the schedule actually runs, because a plan that silently stopped weeks ago is worse than no plan, since it creates false confidence.
How long should I keep old versions? Long enough to reach back past the damage you might not notice immediately. A rolling window of daily copies plus weekly and monthly restore points covers most needs. If you handle regulated or irreplaceable data, keep longer and document the retention rule so it is applied consistently rather than by accident.
Do I really need to test restores? Yes. Testing is the only proof that your backups work, and it is the only way to learn your true recovery time. Schedule small file restores monthly and a full system restore at least quarterly, log the results, and fix what breaks. A backup you have never restored is a hope, not a defense.