IT Disaster Recovery for Australian Businesses: Why "We Have Backups" Isn't Enough (and What Actually Keeps You Running)

Ask most business owners if they would survive a ransomware attack or a server dying overnight, and you get the same three words. "We have backups."

It is the most comforting sentence in IT, and one of the most dangerous, because having backups and being able to recover are two very different things. Plenty of businesses have found that out at the worst possible moment, when they reached for the backup and it was not there, was not current, or was encrypted along with everything else.

Only 41% of Australian organisations have solid backup and disaster recovery in place, according to Barracuda's 2025 research. The other 59% are running on hope.

This guide is about being in the 41%. What disaster recovery actually is, what a real plan includes, a template you can start filling in today, and what to do in the first hour when it all goes wrong. No jargon for its own sake, just the plan that keeps your business running on its worst day.

Here's what's covered:

Backup vs disaster recovery vs business continuity: what's the difference?

These three terms get used as if they mean the same thing. They do not, and the difference is the whole point.

A backup is a copy of your data. That is all it is. If a file is deleted or a drive fails, you can pull the copy. Backups are necessary, but on their own they are just spare parts sitting in a box.

Disaster recovery is the plan and the process for getting your IT systems back up and running after something takes them down. It uses your backups, but it also answers the harder questions: how fast, in what order, by whom, and to what.

Business continuity is the widest of the three. It is how the business keeps operating while disaster recovery is happening: where staff work, how you take orders, how you talk to customers, what you do manually if the systems are down for a day.

The simplest way to hold it in your head: backup is the copy, disaster recovery is getting the technology back, business continuity is keeping the business alive in the meantime. You need all three. Most businesses only have the first, and assume it covers the other two.

Why "we have backups" isn't a disaster recovery plan

Here is the uncomfortable part. The backup you are relying on may not do what you think it will.

The most common ways backups fail a business are depressingly simple. They were never tested, so nobody noticed they had silently stopped working months ago. They were connected to the same network the ransomware encrypted, so they got encrypted too. Or they were technically fine but so slow to restore that the business was down for a week, which for many businesses is the same as not having them at all.

This is not theoretical. Barnett's Couriers, a courier business that had operated in Wollongong for around 40 years, was hit by a cyber attack in 2024. The company worked with IT consultants to try to restore its systems, could not bring them back, and ceased trading. Four decades of business, ended by a recovery that failed.

The numbers say a lot of Australian businesses are exposed the same way. Barracuda's 2025 research found only 41% of Australian organisations have a proper backup and disaster recovery setup in place, and 43% of Australian ransomware victims end up paying the ransom, usually because they have no other way to get their data back. CyberCX's 2025-26 threat reporting found 78% of Australian ransomware victims were small and medium businesses, with a median ransom of $54,000.

The lesson is not "backups are pointless." It is that a backup without a tested recovery plan is a spare tyre you have never checked, in a boot you are not sure opens. Disaster recovery is making sure the whole thing actually works before you need it.

What an IT disaster recovery plan actually includes

A real disaster recovery plan is not a 90-page document nobody reads. It is a clear, practical set of decisions made in advance, so that nobody is improvising on the worst day. Here is what it needs.

The two numbers that matter: RTO and RPO

Two numbers sit at the heart of every disaster recovery plan, and they are simpler than they sound.

RTO (recovery time objective) is how fast you need to be back up. If your business can survive four hours down but not two days, your RTO is four hours, and your plan has to be built to hit it.

RPO (recovery point objective) is how much data you can afford to lose, measured in time. If you back up once a night, your RPO is up to 24 hours, meaning a disaster could cost you a full day's work. If losing a day is unacceptable, you back up more often. Setting these two numbers honestly is what turns a vague wish into a plan you can build and price.

What to protect, and the 3-2-1 rule

Not everything matters equally. A good plan identifies what is critical (the data, systems, and applications the business genuinely cannot run without) and protects those hardest.

The backup standard worth knowing is the 3-2-1 rule: three copies of your data, on two different types of storage, with one kept off-site and disconnected. That last part is what saves you from ransomware, because a copy that is offline cannot be encrypted when the attack hits.

Roles, contacts, and who does what

When systems go down, wasted time is usually confusion about who does what. The plan should name who declares a disaster, who contacts your IT provider, who talks to staff and customers, and who makes the call on the big decisions. It should include the contact details you will need when your email and phone system are the things that are down.

If you are not confident your current setup could actually hit a sensible RTO, that is exactly the kind of thing worth pressure-testing in a discovery session before a real disaster does it for you.

A disaster recovery plan template you can use

You do not need fancy software to start. You need to answer a set of questions and write the answers down somewhere your team can find them. Here is a template you can copy and fill in.

1. Critical systems and data List the systems and data the business cannot operate without, in priority order. For each, note where it lives and where the backup is.

2. Your RTO and RPO For each critical system: how fast must it be back (RTO), and how much data can you afford to lose (RPO)?

3. Backups What is backed up, how often, to where, and when was the last successful test restore? (If the answer to that last one is "not sure," that is your first job.)

4. Roles and responsibilities Who declares a disaster. Who leads recovery. Who contacts the IT provider. Who handles staff and customer communication. Name a backup person for each.

5. Key contacts IT provider (and after-hours number), internet provider, key software vendors, insurer, and any compliance or legal contacts. Keep a copy somewhere reachable when your systems are down, including on paper or a phone.

6. Recovery steps The order systems get restored in, and who does each step. Detailed enough that someone other than your most senior person could follow it.

7. Business continuity actions How the business keeps operating while IT is being restored. Where people work, how you take orders or payments, what you do manually for a day.

8. Testing schedule When you will test, and how. (More on that shortly.)

Fill that in honestly and you have a disaster recovery plan that beats what most Australian small businesses currently have, which is nothing written down at all.

What to do in the first hour of an attack or outage

When it actually happens, the first hour matters more than any other. Panic and the wrong moves make it worse. Here is the short version of what to do.

Disconnect, don't shut down. If you suspect ransomware , isolate affected machines from the network (unplug the network cable, turn off Wi-Fi) to stop it spreading. Avoid powering devices off, since that can destroy evidence and, in some cases, data that could be recovered.

Call your IT provider immediately. This is what the after-hours number is for. The sooner someone who knows your setup is involved, the better the outcome.

Don't rush to pay. Paying a ransom is no guarantee you get your data back, it marks you as a payer, and there may be legal reporting obligations. Make that decision with expert advice, not in a panic.

Preserve evidence. Don't wipe or rebuild anything yet. Your provider, insurer, and any investigators will need the scene intact.

Start your communication plan. Tell staff what is happening and what to do. If customer data may be involved, your obligations and your reputation both depend on handling the comms properly.

Report it. Report cybercrime to the Australian Cyber Security Centre through ReportCyber at cyber.gov.au. Depending on what data is involved, you may have mandatory notification obligations under the Privacy Act.

The businesses that come through a disaster intact are almost never the lucky ones. They are the ones who decided what to do before it happened.

Testing your plan, because an untested plan is just a guess

A disaster recovery plan you have never tested is a hypothesis. You do not actually know if it works, and the worst time to find out is during a real disaster.

Testing does not have to be a huge production. A sensible rhythm for most small and medium businesses looks like this: a quick check every quarter that backups are running and a test restore actually works, and once a year a fuller simulation where you walk through the whole plan as if a real disaster had hit.

The quarterly check catches the silent failures, the backup that stopped working in March that nobody noticed. The annual simulation catches the gaps in the plan itself: the contact who left, the system everyone forgot about, the recovery step that takes three times longer than assumed.

This is also where a good managed IT provider earns its keep. Testing, monitoring, and maintaining recovery readiness is the kind of unglamorous, ongoing work that gets skipped when everyone is busy, and it is the work that decides whether your plan holds on the day. (If you want to know what to look for in a provider who takes this seriously, our managed IT services buyer's guide covers it.)

If you would rather have someone test your recovery properly and keep it that way, a discovery session is a sensible place to start.

Putting it together

"We have backups" is where disaster recovery starts, not where it ends. The businesses that survive their worst day are the ones who went further: who knew the difference between a backup and a recovery, set honest RTO and RPO targets, wrote the plan down, and tested it before they needed it.

None of it is complicated. It is mostly a matter of deciding in advance instead of improvising in a crisis, and then checking that the decisions actually hold. The template above is a genuine starting point. Fill it in this week and you will already be ahead of most businesses your size.

If you would rather not find out the hard way whether your current setup would hold, Tech Seek can pressure-test your backups and recovery before a real disaster does. We are a Melbourne MSP with in-house technicians and proper data backup and recovery built in, not bolted on. The discovery session is a straightforward place to start.

Frequently Asked Questions

What is an IT disaster recovery plan?

An IT disaster recovery plan is a documented set of decisions and steps for getting your technology back up and running after something takes it down, whether that is a cyber attack, hardware failure, or natural disaster. It covers what to recover, in what order, how fast, and who does it.

A good plan also sets clear targets (how fast you need to be back, how much data you can afford to lose) and is tested regularly, so you know it works before you need it.

What's the difference between backup, disaster recovery, and business continuity?

A backup is a copy of your data. Disaster recovery is the process of getting your IT systems running again after an incident, using those backups. Business continuity is how the business keeps operating while that recovery happens.

Think of it as the copy, the technology coming back, and the business staying alive in the meantime. You need all three, but most businesses only have backups and assume that covers everything.

What is RTO and RPO?

RTO (recovery time objective) is how quickly you need your systems back after a disaster. RPO (recovery point objective) is how much data you can afford to lose, measured in time.

If you back up once a night, your RPO is up to 24 hours, so a disaster could cost you a full day's work. Setting both numbers honestly is what tells you how often to back up and how your recovery needs to be built.

Will my backups actually work in a ransomware attack?

Only if they have been set up and tested with ransomware in mind. The common failure is a backup that sits on the same network as everything else, so when ransomware hits, it encrypts the backup too.

The protection is an off-site copy that stays disconnected (the "1" in the 3-2-1 rule), plus regular test restores so you know the backup actually works. An untested backup is the one that lets you down.

How often should I test my disaster recovery plan?

For most small and medium businesses, a quick check every quarter that backups are running and a test restore works, and a fuller walk-through of the whole plan once a year. The quarterly check catches silent backup failures. The annual simulation catches gaps in the plan itself.

The exact cadence matters less than the habit. A plan tested once and filed away is barely better than no plan at all.

What is DRaaS (Disaster Recovery as a Service)?

DRaaS is disaster recovery delivered by a provider, usually using the cloud, so your systems can be spun up off-site and quickly if your own go down. Instead of buying and maintaining your own recovery infrastructure, you pay a provider to keep it ready.

It suits businesses that need fast recovery times but do not want the cost and complexity of running duplicate systems themselves. A managed IT provider can advise whether it fits your situation.

How long does it take to recover from a ransomware attack?

It varies enormously, from hours if you have a tested plan and clean off-site backups, to weeks if you do not. Australian research has found many organisations take one to two weeks to fully recover, and some never do.

The single biggest factor is preparation. Businesses with a tested disaster recovery plan recover far faster than those improvising after the fact.

How much does a disaster recovery plan cost?

Writing the plan itself can cost nothing but time, especially if you start with a template. The cost sits in the recovery capability behind it: your backup setup, off-site copies, and how fast you need to be back, since faster recovery costs more.

For most small and medium businesses, disaster recovery is part of a broader managed IT arrangement rather than a separate line item. Our guide to managed IT services pricing covers how that is usually costed.

What is the 3-2-1 backup rule?

The 3-2-1 rule is a simple backup standard: keep three copies of your data, on two different types of storage, with one copy off-site and disconnected. The off-site, disconnected copy is the one that protects you from ransomware, because it cannot be encrypted when the attack hits.

It is the baseline most IT professionals work to, and a good starting test for whether your current backups are actually safe.