Most Sydney businesses have a disaster recovery plan. Far fewer have ever tested it. The gap between the two is where most real outages stop being a controlled inconvenience and become a multi-day scramble. A DR plan that has not been exercised is, at best, a hopeful document, and the moment you find out which parts of it do not work is the worst possible time to discover them.
What tested actually means
There is a wide spectrum between we have backups and we have rehearsed recovery. A useful way to think about it is a ladder, with each rung representing progressively more realistic testing.
Backup verification. The lowest rung: confirm backups are running and that you can restore a single file. Most businesses do this passively at best.
Restore-to-test. Pick a server or critical SaaS export each quarter and restore it to a sandbox. Measure how long it took and whether the restored data is usable. This step alone catches an enormous number of subtle backup failures.
Tabletop exercise. Get the right people in a room (or call) for an hour, hand them a realistic scenario such as ransomware on Friday afternoon or primary server fails on Sunday, and walk through who does what. No technology involved, just decisions and timing.
Failover drill. The full simulation: actually fail over a workload to its recovery environment, run it from there for a window, and fail back. The most informative and the most expensive in time. Annual cadence is realistic for most SMBs.
What goes wrong in real drills
Almost every DR drill exposes the same handful of problems, regardless of industry. The contact list is out of date: half the numbers ring out, two people no longer work at the business, the after-hours pager goes nowhere. Documentation references systems that have been renamed or decommissioned. Restored data is technically correct but unusable because a dependency was not restored alongside it. The team genuinely does not know who has authority to declare a disaster.
None of those are technical problems. They are operational ones, and they are invisible until you actually run the drill.
RTO and RPO, in plain terms
Two numbers shape every DR plan: how long you can be down (recovery time objective) and how much data you can afford to lose (recovery point objective). Both should be written down per workload, not as a single business-wide figure. Email can usually tolerate eight hours down; the line-of-business application that staff use to invoice cannot.
The most common DR mistake is treating both numbers as goals rather than constraints. They drive every other decision: backup frequency, replication choice, hot vs cold standby, even where the business chooses to host workloads. Get them right and the rest of the plan writes itself.
Industries that learn this the hard way
Service businesses with physical output (manufacturers, fabricators, 3D printing services, print shops) feel a DR event differently than pure information businesses. The systems that take orders, generate quotes, and schedule production sit between the customer and the physical work, and an outage there can mean idle machines and missed deadlines on top of the IT problem. For those businesses, the DR plan should explicitly include the ordering and quoting layer, not just the back-office accounting and email.
How often to test
A reasonable cadence for an SMB is: monthly restore-to-test of one critical system on rotation, quarterly tabletop with the leadership team, and an annual failover drill on the most business-critical workload. That is not unrealistic and it surfaces almost everything that matters.
The bottom line
The single most useful thing a DR plan does is force you to know, in advance, how long things will take and who will do them. A drill is the only way to find out. The first one is uncomfortable, the second is informative, and by the third the plan has been quietly rewritten by the team that actually has to execute it, which is exactly the document you want sitting in the drawer when something goes wrong.