Disaster recovery

Why it matters

Businesses rarely fail because of the disaster itself; they fail because recovery takes too long. Customers move to a competitor who can deliver, staff cannot work, invoices cannot be issued, and the cash gap compounds. A recovery plan converts an open-ended crisis into a known period of disruption. It also matters for compliance and contracts: insurers ask about backups, the Privacy Act expects reasonable steps to protect personal information from loss, and larger customers increasingly want to see a tested plan before they rely on you.

Decide what matters and how fast you need it back

Start by listing the systems and data the business cannot operate without: the accounting system, the customer database, email, the booking or job management tool, the point-of-sale, design files, the website. For each, ask two questions. How long could we be without it before the damage becomes serious? That is the recovery time objective (RTO). How much data could we afford to lose, measured as the time since the last backup? That is the recovery point objective (RPO).

The answers vary. An online store might need the website back within an hour and can lose at most a few minutes of orders. The same business can probably live without its design archive for a week. Setting these objectives honestly stops you over-investing in things that do not matter and under-investing in the ones that do. They also become the specification for your backup design and the test you hold the plan to.

Design backups that survive the disaster

A backup only counts if it survives whatever destroyed the original. A drive plugged into the server burns with the server and gets encrypted with it. The widely used rule is three copies of your data, on two different types of storage, with one kept off site or offline. For most small businesses this translates to the live system, a local backup for fast restores, and a cloud backup in a separate account with separate credentials that an attacker who compromises your main environment cannot reach.

Cloud software does not remove the need. Providers protect their platform against their own failures, but most do not protect you against your own deletions, a malicious insider or a compromised administrator account, and their retention windows are often shorter than you assume. Check each critical SaaS tool for its export and backup options and add third-party backup where the data is irreplaceable. Where you run your own databases or servers, immutable backups that cannot be altered or deleted for a set period are the strongest defence against ransomware.

Write the plan people can follow at 2am

The disaster recovery plan is a short document that a stressed person can follow without you. It names who declares a disaster and leads the response, lists contact details for staff, IT provider, insurer, landlord, key suppliers and customers, and sets out the recovery order: which systems come back first, from which backup, by whom, with the steps and credentials needed. It covers where people work if the site is unusable and how you communicate when email is down.

Keep a copy where the disaster cannot reach it: printed in a folder at a second location and in a personal cloud account. Include the small things that stall recoveries, such as software licence keys, domain registrar logins, MFA recovery codes and the phone number of the person who set up the network. If you use a managed IT provider, make sure the plan says what they do and what you do, and that you have tested the handoff.

• Who declares a disaster, who leads, and who takes over if they are unavailable.
• Contact list for staff, providers, insurer, landlord, key customers and regulators.
• Recovery order with RTO and RPO for each system and the restore steps.
• Where staff work and how they communicate if the site or email is down.
• Credentials, licence keys and recovery codes stored securely but reachably.
• Communication templates for customers and staff.

Test it, then test it again

An untested backup is a hypothesis. Restore a file every month. Restore a whole system to a spare machine or cloud environment every quarter and time it against the RTO. Once a year, run a tabletop exercise: gather the team, present a scenario such as "the office flooded overnight and the server is under water", and walk through the plan step by step. Every exercise finds something: a password that changed, a provider contact who left, a step that only one person knows.

Treat the whole thing as a loop. Plan, back up, test, learn, improve. Businesses that run this cycle recover in hours or days; those that do not find out what they were missing on the worst day of the year. Where internal capacity is thin, managed backup and monitoring from a provider such as SMBH Consulting’s AIOps and database services teams makes the testing routine rather than heroic.

How to build a disaster recovery plan

1. List critical systems and data Everything the business cannot operate without, including SaaS tools and the files on people’s laptops.
2. Set RTO and RPO for each How long can it be down, and how much data can you lose? Be honest, not ambitious.
3. Audit current backups against those targets What is backed up, how often, where, and when it was last restored.
4. Close the gaps Add off-site or immutable copies, SaaS backup, and shorter intervals where the RPO demands it.
5. Write the plan Roles, contacts, recovery order, steps, credentials and workarounds, stored where the disaster cannot reach it.
6. Test on a schedule File restores monthly, system restores quarterly, a tabletop scenario annually.
7. Review after every test and incident Update the plan and backup design with what you learned.

Real-world example

A Townsville wholesaler recovers from a flooded warehouse

Coral Coast Distributors supplies around 300 retail customers from a single warehouse with an on-site server running its inventory and ordering system. After a close call in a previous wet season, the owner, Deb, spent a few weeks on disaster recovery: inventory and accounting systems moved to a hosted platform with daily backups to a separate cloud account, laptops configured to sync to cloud storage, a printed plan kept at her home, and a quarterly restore test run by her IT provider. The RTO for the ordering system was set at one business day; the RPO at a few hours.

When floodwater enters the warehouse two years later, the server room is destroyed along with a portion of stock. By mid-morning staff are taking orders from the hosted system on laptops at a borrowed office, customers have received a text message explaining the delay and the alternative pickup arrangement, and the insurer has been notified with photographs. Stock records lag by about three hours of the previous evening’s receipts, which are reconstructed from supplier dockets. The business trades at reduced capacity for ten days while the warehouse is cleaned and loses no customers. The post-incident review adds a second mobile network for the office internet and an earlier trigger for moving stock off the floor when flood warnings are issued.

Common mistakes

• Backups that are never restored Backup jobs fail silently and media degrades. If you have not restored from it, you do not know it works.
• One copy, one place A backup next to the server shares the server’s fate. Keep an off-site or offline copy that an attacker or fire cannot reach.
• Assuming the cloud provider backs you up Most SaaS providers protect their platform, not your deleted or corrupted data, and retention windows are short. Check and add backup where needed.
• A plan only the owner can run If the plan lives in your head or your laptop, the business cannot recover when you are the one unavailable.
• Forgetting the small dependencies Domain logins, licence keys, MFA recovery codes and the IT provider’s number stall more recoveries than missing data does.

KPIs to track

• Critical systems with RTO and RPO defined Share of systems on your critical list with both objectives written down. Target: all.
• Backup success rate Share of scheduled backup jobs that completed and were verified in the last 30 days. Anything below 100% needs investigation.
• Last successful restore test Date of the last file restore and the last full system restore. Monthly and quarterly respectively.
• Measured recovery time versus RTO How long the last test restore took compared with the objective. If it is longer, the design or the objective must change.
• Plan review date When the plan was last updated. More than twelve months, or any major system change, means it is probably wrong somewhere.

Frequently asked questions

What is the difference between disaster recovery and business continuity?

Business continuity covers how the whole business keeps operating through a disruption: people, premises, suppliers, customers and communications. Disaster recovery is the technical subset: restoring systems and data. You need both, and the recovery plan should sit inside the continuity plan.

How often should I back up?

As often as your recovery point objective demands. If losing a day of orders would be acceptable, daily is fine; if an hour would hurt, you need continuous or hourly backups for that system. Set the interval per system, not globally.

We use cloud software for everything. Do we still need a plan?

Yes. You still need to know how you would work if the provider was down or your account was compromised, how you would export or restore your data, and who would do it. Cloud reduces some risks and introduces others.

How long should a recovery test take?

A monthly file restore takes minutes. A quarterly system restore to a test environment might take a few hours with your IT provider. An annual tabletop exercise is a two-hour meeting. The time is trivial compared with an unplanned outage.

Key takeaways

• Set a recovery time and recovery point objective for every critical system; they define everything else.
• Keep three copies of your data, on two types of storage, with one off site or offline that an attacker cannot reach.
• Cloud software protects the platform, not your mistakes; check retention and add backup where data is irreplaceable.
• Write a plan a stressed colleague can follow without you and keep it where the disaster cannot reach it.
• Test restores monthly, systems quarterly and the full scenario yearly, and fix what each test finds.