This is a representative scenario, not a specific client. It's a composite of the kind of server-failure recovery we handle, written to show the order we work in and why. Real incidents vary, and the details here are deliberately general.
It's Monday morning at a Perth trades business — a builder, a plumbing outfit, an electrical contractor, the kind of company where the office server holds the accounting file, the job records and the shared drive everyone works from. Except this morning the server won't boot. No shared drive, no accounting, no quotes going out. And when we go looking for the backup to restore from, we find the thing every business owner dreads: it hasn't run in weeks, and nobody knew. Here's how we handle both the crash and the nasty surprise underneath it.
Monday morning: the server won't boot
The first call is panic-adjacent: "Everything's down, nobody can work." Before touching anything, we establish what kind of failure this is, because it decides the whole recovery:
Is it the hardware or the software? A failed disk, a dead power supply and a corrupted operating system are three very different jobs.
Is any data still readable? Even a server that won't boot often has intact drives we can pull data from — so the first rule is don't make it worse.
First hour: triage without making it worse
The wrong move under pressure is to start "fixing" — reinstalling, rebuilding a RAID array, formatting — before we know what's recoverable. A rushed rebuild can permanently destroy data that was sitting there intact. So we work carefully: image the drives if we can, confirm what's readable, and get a clear picture before any irreversible step. In parallel, we get people working again on what we can — often moving the team to cloud-based access or a temporary setup so the business isn't dead in the water while the main fix happens.
The gut-punch: the backup hadn't run
This is the part that turns a bad morning into a genuine crisis. The business had a backup — a drive plugged into the server, or a piece of software someone set up years ago. But:
The backup job had been failing silently for weeks — a full disk, an expired licence, a changed password — and nobody was watching the alerts.
Or the backup was sitting on a drive plugged into the very server that died, so it's just as unavailable as the original.
Or it was running, but had never once been test-restored, so no one actually knew whether it worked.
We recover what we can from the failed hardware, and we're honest about the gap: whatever the backup missed is what the business has genuinely lost. Sometimes that's a few days; occasionally it's far more. That honesty matters — it's the moment the real lesson lands.
Getting them working again
With data recovered from the drives (and whatever the backup did hold), we stand the business back up: a repaired or replacement server, or — increasingly — a move to cloud and Microsoft 365 so there's no single box left to fail. The priority order is always the same: get the team earning again first, rebuild cleanly second.
What we change afterwards — so it never recurs
Recovery is the emergency. A backup you can actually trust is the fix:
Monitored, alerted backups. A backup nobody watches is a backup that's already failing. Ours report success or failure every day, and a failure raises a ticket — not a silence.
The 3-2-1 rule. Three copies, on two types of media, with one off-site and immutable — so a dead server, a fire, or ransomware can't take the backup with it.
Tested restores. We prove we can actually get a file, a database and a whole system back, and we time it, so "how fast could we be running again?" has a real answer. (More on why this matters in does Microsoft 365 back up your data? — the answer surprises most people.)
A written continuity plan so the next incident is a procedure, not a panic.
The lesson: a backup you haven't tested is a hope
Almost every version of this call has the same root cause — not that the business didn't care about backups, but that nobody owned them. The job ran, or didn't, and no one was checking. Proactive backup and disaster recovery exists precisely to close that gap: someone watching every night, and a tested plan for the morning the server doesn't turn on.
How we help
For our managed clients, backups are monitored, off-site, immutable and restore-tested as standard — which is why the "backup hadn't run" version of this story simply doesn't happen to them. If you're not certain your backups are running, or you've never seen a test restore, that uncertainty is worth resolving before the Monday it matters. Get in touch or call (08) 9325 1196 and we'll check it for you. We've kept Perth businesses running since 1997.
