The test that matters: assume the PC is already owned
Firewalls and antivirus are the lock on the door. This article is about what happens after someone's already inside. So play it out: your main machine is compromised, ransomware running with full admin rights, free to do whatever it likes. Now ask one question. Can it reach your backup and destroy it?
If the answer is yes, you don't have a backup, you have a second target. That's just how you have to design the thing, because the day you need a backup is by definition the day the worst has already happened. Build for the good days and you've built nothing. Build for the day the PC gets owned and you've built the only backup worth having.
Why your current setup probably fails the test
Most home and small-business setups fail this on the first question, and here's the honest rundown of why.
The always-plugged-in USB drive. The most common backup in the country, and it's encrypted within minutes of an infection. Ransomware doesn't politely stick to the C: drive. It enumerates every connected disk and every drive letter the machine can see, and a permanently attached external is just another drive letter. Handy for recovering a file you deleted by accident. Useless the day it actually matters.
The mapped NAS share. A network drive is a real step up for capacity and convenience, but if the PC can write to that share, so can the malware running on the PC. Modern strains actively crawl the network looking for shares and NAS boxes, and they go for the backup store first, because the crooks know an unreachable backup is the one thing that lets you tell them to get stuffed. A writable share is reachable. Reachable is dead.
The synced cloud folder. This is the one that fools the most people, because the cloud feels safe. OneDrive, Dropbox, Google Drive and the rest don't back up, they sync: they mirror your files everywhere in near real time. So when ransomware encrypts your documents, the encrypted versions sync straight up and overwrite the good ones. The cloud did its job perfectly. It kept everything in sync, including the disaster. (The deeper why-sync-isn't-backup explanation lives in the small business backup primer; the short version is they're different jobs.)
Notice the pattern. Every one of these fails for the same reason: the infected machine has a writable path to the backup. Fix that one thing and you've fixed all three.
The three honest ways to make a copy untouchable
There are exactly three ways I'd trust to put a copy out of reach, and they're not equally convenient. Here's each, plainly, with the catch stated.
1. Air-gapped: the disk that isn't plugged in
The crudest method and, dollar for dollar, the most bulletproof. An air-gapped backup is a drive that's only connected while the backup is running, then physically unplugged and put in a drawer. Malware cannot encrypt a disk that isn't there. No clever software, no subscription, no trust in a vendor's settings, just a cable that isn't connected.
The way to do it properly is a rotation: two cheap external drives, swap them weekly, and crucially keep one of them offline and offsite at any given time, the one you take home. That single habit gets you a copy that survives ransomware, theft, fire and a power surge in one move. The catch is honest and it's the only one: air-gap relies on a human remembering to swap the drives. A backup that depends on memory drifts stale. So this is brilliant as a low-cost layer, and better still when it's paired with something automated underneath.
2. Immutable: object-lock, where delete is simply refused
This is the automated answer, and it's the one I'd build a serious setup around. "Immutable" means a copy that cannot be changed or deleted once it's written, full stop. The mechanism on cloud object storage is called object-lock, and it's worth understanding because it's genuinely different from "password-protected."
When a file is uploaded with object-lock on, the storage stamps it with a retention date. Until that date passes, the storage itself refuses every delete and overwrite request, including ones that arrive with perfectly valid administrator credentials. That last part is the whole point. With a normal cloud backup, if ransomware steals the saved login, it can delete your data through the front door. With object-lock, the malware can log in, it can upload new junk, but it physically cannot remove what's already locked, because the guarantee is enforced by the storage, not by a password it can steal. Stolen credentials are useless against a rule baked into the disk. Set a retention window that's longer than you'd take to notice and recover from an attack, two weeks, a month, and a locked copy is waiting no matter what happens to the PC.
3. Pull-based: the PC has no login to the backup
The third approach flips the direction of trust, and it's the cleanest if you're handy. In most setups the PC pushes its data out to the backup, which means the PC holds the keys to the backup, which means malware on the PC holds them too. A pull-based setup turns that around: a separate backup server reaches in and pulls the data from the PC on its own schedule. The PC has no credentials to the backup at all, doesn't even know where it lives. An infected workstation can't wipe a store it has no login to and no path to. This is exactly how a well-built backup appliance works, where a cheap box quietly pulls from your machines and keeps versioned snapshots they can't reach back into.
The Australian reality: design around the upload, don't skip the offsite
Most ransomware-backup advice is written as if everyone has fat symmetrical fibre. We don't. On a typical NBN plan your upload is a small fraction of your download, often single-digit megabits, and a backup is almost entirely upload. That changes the maths, and it's where a lot of Aussies quietly give up on the offsite copy. Don't.
The honest implication is just timing. The first full backup of years of files to an immutable cloud bucket can take days, grinding away in the background. After that, a good backup sends only what changed each night, which is tiny and fine on any link. So the pattern that works here is two layers: a fast local copy for everyday speed, plus a cold, immutable cloud copy doing the slow offsite, ransomware-proof job quietly underneath. If your upload is painful, some providers let you seed the first backup by posting them a drive; otherwise let the first run take a week. A slow upload is a reason to start tonight, not a reason to skip the offsite copy you most need.
How I'd build it, in order, cheaply
You don't need to spend big. Work down this list and stop when you're genuinely covered.
- Decide what you can't lose. The accounting file, the customer records, the quotes, the photos, the email. You almost never need the whole machine, you need the data that is the business or the memories. Keeping it small keeps it fast, cheap and easy to store immutably.
- Get a fast local copy first. A NAS or a dedicated drive that backs up automatically. This is your everyday net for "I deleted the wrong thing" and your instant restore. It is not your ransomware protection on its own, because the PC can reach it.
- Add one untouchable copy. This is the step that makes it ransomware proof, and it's the step everyone skips. Pick one: object-lock immutable cloud storage, or an air-gapped drive you unplug between runs, or a pull-based backup server. One is enough. Without it, a clever infection takes every copy at once.
- Put a copy offsite. The immutable cloud copy covers this automatically. If you're going the air-gap route, the offline drive lives somewhere other than the building it's protecting. One location is one event away from nothing.
- Automate it, then test the restore. A backup that needs a human to remember will be weeks stale on the day it matters, so automate the job. Then actually restore a real file from the safe copy, to a fresh location, and open it. An untested backup is a hope with a schedule, not a backup.
If you'd rather own the whole stack than rent it, this runs beautifully on hardware you control. For the foundations, start with the small business backup primer.
What "ransomware proof" actually looks like
A protected setup isn't an expensive one, it's a designed one. A fast local copy for everyday restores, and at least one copy the infected machine physically cannot reach: unplugged, object-locked, or pulled by a server with no login back to the PC. Offsite, automated, and tested so it isn't running on luck. Set up like that, a ransomware note stops being a catastrophe and becomes an afternoon: wipe the machine, restore from the copy that survived, back to work, and the only thing the crooks got was your time. That's the whole point of the word "proof", not that an attack can't happen, but that when it does, it can't touch the one thing that gets you back. Start with the small business backup primer for the foundations first.
Ransomware proof backup: common questions
- What is a ransomware proof backup?
- A copy of your data that the infected machine physically cannot reach, alter or delete. It's not a product or a brand of software, it's a property of how the copy is stored: disconnected from the network (air-gapped), written with an object-lock that forbids changes until a retention window passes (immutable), or pulled in by a separate server the PC has no login to. If ransomware running with full admin on your computer has no path to that copy, it survives. That's the whole test.
- Can ransomware encrypt my cloud backup?
- Yes, if the cloud is just a synced folder or a drive the PC can write to. Sync services mirror an encryption as faithfully as a normal save, so the good files get overwritten by the encrypted ones within minutes. Even a real cloud backup can be wiped if the malware steals the saved login and deletes through those credentials. The only cloud copy ransomware can't touch is one with immutability or object-lock on, so a copy, once written, can't be deleted until its retention period expires, not even with valid credentials.
- Is an air-gapped backup overkill for a home or small business?
- No, and it's the cheapest ransomware proof backup there is. It's just a drive that's only plugged in while the backup runs, then unplugged and put away. Malware can't encrypt a disk that isn't connected. A rotation of two cheap external drives, one always offline, gives genuine ransomware protection for the price of the drives. The catch is it relies on a human to swap them, so pair it with an automated immutable cloud copy if you can.
- What is immutable backup and how does object-lock work?
- Immutable backup means a copy that can't be changed or deleted once it's written. The common mechanism is object-lock on cloud object storage: when a file is uploaded it's stamped with a retention date, and until that date passes the storage refuses every delete or overwrite request, including ones from an administrator with the right credentials. So even if ransomware steals your cloud login, it can add new data but it can't touch what's already locked. That guarantee is enforced by the storage itself, not by a password, which is exactly why it survives a credential theft.
- Does the NBN upload speed make cloud backup impractical in Australia?
- It makes the first backup slow, not impractical. On a typical NBN plan your upload is a small fraction of your download, often single-digit megabits, and a backup is almost all upload. The first full copy can take days, but after that a good backup only sends what changed, which is tiny and fine on any link. The practical pattern here is a fast local copy for everyday restores plus a cold, immutable cloud copy for the offsite, ransomware-proof job. If the first upload is painful, seed it by posting a drive, or let the initial run grind for a week. Don't let the upload talk you out of the offsite copy.
- How do I make my existing backup ransomware proof?
- Apply one test: assume the PC is already owned, with ransomware running as admin, and ask whether it can reach and destroy the backup. If a USB drive is permanently plugged in, or a NAS share is mapped and writable, or the cloud is a synced folder, the answer is yes and that copy isn't safe. Fix it by adding at least one copy the machine can't touch: unplug the drive between runs, turn on object-lock on your cloud storage, or move to a pull-based setup where a separate server fetches the data and the PC has no login to the backup. You don't have to replace everything, you have to add one untouchable copy.
Not sure your backup would survive the day it's actually needed? That's worth ten minutes before you find out the hard way. Tell us what you're protecting and we'll help you work out whether it's truly out of reach, no jargon, no scare tactics, no selling you storage you don't need.