Call NowFree Quote
Best Practice

How to Create an IT Disaster Recovery Plan for Your Perth Business

An IT disaster recovery plan is the document that tells your team exactly what to do when something goes seriously wrong - and can be the difference between a recoverable incident and a business-ending one. Most Perth businesses don't have one until they wish they did. Here's how to build one that actually works.

Disaster Recovery vs Business Continuity - Know the Difference

Disaster Recovery (DR) focuses on restoring IT systems and data after a failure. Business Continuity Planning (BCP) is broader - it covers how the whole business keeps operating during a disruption, including non-IT considerations like staff, premises, and suppliers.

This guide focuses on IT disaster recovery - the most urgent and actionable starting point for most Perth SMBs.

Step 1: Define Your Recovery Objectives

Two metrics define what your DR plan needs to achieve:

  • Recovery Time Objective (RTO) - how long can your business operate without its IT systems before the impact becomes unacceptable? For some Perth businesses this is 4 hours; for others it might be 2 days. Your RTO sets the target for how quickly you need to be back online.
  • Recovery Point Objective (RPO) - how much data can you afford to lose? If your RPO is 4 hours, you need backups taken at least every 4 hours. If your RPO is 24 hours, nightly backups may be sufficient.

These numbers drive every other decision in your DR plan - what backup frequency you need, what recovery infrastructure you invest in, and how much the plan costs to implement.

Step 2: Identify Your Critical Systems

Not everything needs to be recovered at the same speed. Categorise your systems by criticality:

  • Tier 1 - Must recover within RTO: The systems that stop the business if they're down. Typically: email, accounting/invoicing software, customer-facing systems, and any system your staff use every hour of the day.
  • Tier 2 - Recover within 24–48 hours: Important but not immediately business-stopping. File storage, secondary databases, internal tools.
  • Tier 3 - Recover within a week: Archival systems, reporting tools, non-critical applications.

For each Tier 1 system, document: what it is, where it runs (server, cloud, third-party SaaS), who is responsible for it, how it's backed up, and the steps to restore it.

Step 3: Document Your Backup Architecture

Your DR plan should clearly document what is backed up, where, how often, and how long it's retained. Apply the 3-2-1 rule: three copies of data, two on different media, one offsite. For each backup:

  • What data does it cover?
  • How often does it run?
  • Where is it stored (local device, cloud, offsite tape)?
  • How long are recovery points retained?
  • Who monitors it for failures?
  • When was it last tested?

Step 4: Write the Recovery Runbook

A runbook is a step-by-step procedure for restoring each critical system. Written clearly enough that someone unfamiliar with your environment could follow it under pressure. For each Tier 1 system, the runbook should cover:

  • How to access the backup (credentials, location, access procedure)
  • Step-by-step restore procedure
  • How to verify the restore was successful
  • Dependencies - what else needs to be running first
  • Estimated time to complete

The runbook must be stored somewhere accessible when your primary systems are down - a printed copy in the office, a copy in a personal cloud account, or with your IT provider. A runbook stored only on the server you're trying to recover is useless.

Step 5: Define Roles and Communication

When disaster strikes, confusion costs time. Your DR plan should define:

  • Who declares an IT disaster and triggers the plan?
  • Who is the primary contact to the IT provider?
  • How will staff be notified that systems are down and given status updates?
  • Who communicates with clients if services are disrupted?
  • What manual workarounds exist while systems are being restored?

Step 6: Test It - At Least Annually

An untested DR plan is a hypothesis, not a plan. Testing reveals gaps before a real crisis does. At minimum, run an annual tabletop exercise - walk your team through a simulated scenario (“ransomware has encrypted the server, what do we do?”) and identify where the plan breaks down.

More rigorous testing involves actually restoring systems from backup to verify the process works and the time estimates are accurate. Your IT provider should facilitate this.

What a Managed IT Provider Does for Your DR Plan

A managed IT provider should own the technical elements of your DR plan - monitoring backups, maintaining recovery documentation, and executing the runbook when called upon. What they can't do is make the business decisions: what your RTO is, which systems are critical, and how to communicate with customers. That part is yours.

Frequently Asked Questions

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

Disaster recovery focuses specifically on restoring IT systems and data after a failure, while business continuity is broader and covers how the whole business keeps operating, including staff, premises, and suppliers. Most Perth SMBs should start with IT disaster recovery since it's the more urgent and actionable piece.

What are RTO and RPO, and why do they matter?

Recovery Time Objective is how long your business can operate without its IT systems before the impact becomes unacceptable, and Recovery Point Objective is how much data you can afford to lose. These two numbers drive almost every other decision in a DR plan, including how often backups need to run.

Do we really need to test our disaster recovery plan?

Yes, an untested plan is a hypothesis, not a plan, and testing is what reveals the gaps before a real crisis does. At minimum, an annual tabletop exercise, walking through a simulated scenario as a team, will show you where the plan breaks down.

Where should our recovery runbook be stored?

Somewhere accessible when your primary systems are actually down, a printed copy in the office, a personal cloud account, or with your IT provider. A runbook stored only on the server you're trying to recover is not going to help you when you need it most.

Our backup and disaster recovery service handles the monitoring, documentation, and runbook execution your DR plan depends on.

Backup & Disaster Recovery →

Need help building a disaster recovery plan for your Perth business?

Call 0433 087 091 - we'll assess your current backup setup and help you build a recovery plan that matches your actual RTO and RPO.

Book a Free IT Assessment

For related reading, see our guides to How to Protect Your Perth Business from Ransomware and Cyber Attack Response for Perth Businesses.

Share this article