The short answer: a backup protects you from ransomware only if it is out of reach of whatever is encrypting your network, and only if someone has restored from it recently enough to know that it works and how long it takes. A job that reports "success" every night proves neither.
Checked September 2026. Sources are listed at the end.
Most small businesses believe they are covered because a backup runs every night and nobody has complained. That belief holds right up until the morning ransomware gets in — because the backup many businesses have is exactly the kind ransomware is built to find.
Can ransomware reach your backup?
Usually, yes — and it looks for it first.
Ransomware is written by people who assume you have a backup, because almost everyone does now. So before encrypting anything, it goes hunting: a mapped network drive, a NAS sitting on the same network, a backup service signed in with the same credentials as everything else. Anything it can reach, it encrypts or deletes.
The businesses hurt worst are not the ones with no backup. They are the ones whose backup lived on the same network, behind the same login, as everything it was meant to protect.
Which backups actually survive ransomware?
| Where the backup lives | Survives an attack? | Why |
|---|---|---|
| Mapped drive or NAS on the same network | Usually not | Reachable from the machines being encrypted, often with the same login |
| File sync (OneDrive, Dropbox, Google Drive) | Not reliably | Encrypted files sync up too; recovery depends entirely on version history |
| Cloud backup, same admin login as everything else | Sometimes | Whoever holds that login can delete the recovery points |
| Cloud backup with immutability switched on | Yes | Cannot be altered or deleted for a set period, even by an administrator |
| Offline or genuinely offsite copy | Yes | Not reachable from the network at all |
The pattern is simple: a backup survives when reaching your network does not also mean reaching the backup.
Does "the backup ran successfully" mean anything?
It means the software did not throw an error. It does not tell you:
- Whether the files it copied were the right ones, or a folder that stopped being used two reorganisations ago
- Whether a locked database — your practice management system, your accounting software — was captured or silently skipped
- Whether the backup is sitting somewhere ransomware can also encrypt
- Whether anyone could actually restore from it, under pressure, in a reasonable time
Every one of those has caused a business to discover, on the day it mattered, that the backup it trusted was not going to save it.
What does a restore test actually prove?
It proves two things a log file cannot: that the data comes back, and how long coming back takes.
Testing means periodically restoring real data and confirming it opens, loads and matches what it should. Quarterly is a sensible rhythm for most small businesses.
The output is not "yes, it works." It is a number. A backup that technically works but takes four days to restore is a completely different business decision from one that takes four hours — and that is worth knowing before the day you need it, not during it.
What actually stops it?
Immutable, or write-once, copies. A properly configured immutable backup cannot be altered or deleted for a set period, even by someone with administrator access to everything else. This is the single biggest difference between a backup that survives an attack and one that doesn't.
A copy that isn't reachable with the everyday login. If the account that runs your day-to-day systems can also delete the backup, that separation does not exist. The backup needs its own credentials, ideally its own path.
A copy that leaves the network. Local backups are useful for speed, but a second copy somewhere genuinely separate covers the case where the whole site is affected — fire, theft, or a compromised network.
None of this is exotic. It is the difference between a backup product configured properly once, and one switched on and left alone.
Is any of this actually required in Australia?
Two things are worth separating: guidance, and obligation.
Regular backups are one of the eight strategies in the Australian Signals Directorate's Essential Eight, alongside patching, multi-factor authentication and restricting administrative privileges. The Essential Eight is a baseline, not a law for private businesses — but it is the list insurers, auditors and larger clients increasingly ask about.
The Privacy Act is an obligation, and it catches smaller practices than people expect. Businesses under $3 million in annual turnover are generally exempt — but that exemption does not apply to private sector health service providers holding health information. A two-chair dental practice is covered in the same way a large one is.
If a breach is likely to result in serious harm, the Notifiable Data Breaches scheme requires you to assess it within 30 calendar days at the outside, and to notify affected individuals and the Information Commissioner as soon as practicable. "We had a backup" is a reasonable answer to a regulator or an insurer only if that backup could actually be restored.
What we would do first
Not sell you more storage. Most businesses already have enough — what's missing is structure.
- Check what is actually being backed up, against what should be. It is common to find a folder, a database or a whole machine added to the network after the backup was set up, and never included in it.
- Separate the backup from everyday access. Different credentials, ideally a different path, so one compromised login cannot reach both.
- Turn on immutability wherever the platform supports it.
- Run a real restore, on a schedule, and write down how long it took. That number belongs in your recovery plan instead of a guess.
- Make sure more than one person can do it. A recovery plan that lives in one technician's head is not a plan.
If you want to know where your own setup stands before anything goes wrong, the free IT health check covers exactly this — backups included — written up in plain English, with no obligation attached. What ongoing cover looks like is on the backup and disaster recovery page.
If something has already happened, call 03 7057 1878 — evenings until 9pm, Saturdays 8am–4pm, and a Sunday emergency line from 9am to 5pm. Ransomware has no particular respect for business hours.
Sources
- Australian Signals Directorate, Essential Eight — the eight strategies, regular backups among them
- OAIC, Notifiable Data Breaches scheme — 30 calendar day assessment limit, notification as soon as practicable
- OAIC, small business and the Privacy Act — the $3 million threshold and the health service provider exception