Skip to content
// Industries

Regulated, deadline-bound, and allergic to downtime.

We don’t sell backups. We sell getting you back.

Immutable copies, restores that are actually tested, and a recovery time you have measured rather than assumed. The only number that matters is how long you are down.

A backup you have never restored is not a backup. It is a rumour with a scheduling agent.

Almost every business we take over has backups running. Far fewer have ever restored from them. The failures we find are dull and consistent — a job that has errored silently since a server rebuild, a Microsoft 365 tenant nobody realised was excluded, an off-site copy sitting on a share the ransomware would have encrypted too.

01 · Recovery scenarios

What breaks, and how long it takes.

Recovery time is not one number — it depends entirely on what went wrong. These are the scenarios we plan for, and the honest shape of each. Your actual targets get agreed per system and written into the agreement.

Recovery scenarios, source of restore, and typical recovery time
Scenario Restored from Typical time
01Deleted file or folder Restored fromMost recent local snapshot Typical timeMinutes — often self-service
02Mailbox, SharePoint or Teams data Restored fromMicrosoft 365 backup, retained separately Typical timeUnder an hour
03Failed server or corrupted database Restored fromLocal image, restored in place or virtualised Typical timeSame business day
04Site loss — fire, flood, theft Restored fromOff-site copy, rebuilt on replacement hardware Typical timeOne to two days
05Ransomware across the estate Restored fromImmutable off-site copy, restored in sequence Typical timeSequenced over days, clean first
06Departed staff data request Restored fromRetained archive Typical timeMinutes

Notice the last two are measured in days, not hours. Anyone quoting you four-hour recovery from a full ransomware event is selling something. Sectors where recovery time is the whole argument: healthcare, retirement residences and dental clinics.

02 · What makes it survivable

Four properties that decide whether you recover.

Backup software is a commodity. These four design decisions are what separate a backup that works from one that merely runs.

See the security stack
A laptop with a blank screen and a knocked-over mug beside it, while the woman who was using it works on a second laptop showing the same document.
01

Immutability

The off-site copy cannot be modified or deleted for its retention window — not by us, not by you, and not by an attacker holding your domain admin credentials. Modern ransomware hunts backups first; this is the control that defeats that.

02

Separation

Backups do not live on the domain, do not authenticate with your production credentials, and are not reachable from a compromised workstation. A copy your attacker can reach is not a copy.

03

Verification

Every job is checked the following morning, and a real restore is performed quarterly with the elapsed time recorded. A green tick in a dashboard is a claim; a restored file is evidence.

04

Sequencing

Recovery order is decided before the incident — domain controller, then line-of-business database, then file shares, then endpoints. Deciding this at 6am during an outage is how a two-day recovery becomes a week.

03 · Recovery workflow

What happens the morning it actually goes wrong.

Five stages, agreed in advance, with named authority at each. Nobody should be inventing process while the phones are ringing.

Hour 0

Declare

Someone with authority calls it. The declaration starts the clock and switches us into recovery mode.

Immediately

Isolate

Contain the spread and protect the backup repository before anything else is touched.

First hours

Assess

Establish what is clean, what is encrypted, and the last known-good restore point per system.

Sequenced

Restore

Rebuild in the agreed order, into a clean environment. Verify each tier before starting the next.

After

Report

Written account of the incident, elapsed times against target, and what changes so it does not recur.

// Decided before you need it

Who can declare a disaster, which systems come back first, what your staff are told and when, whether you notify clients, and where the cyber-insurance policy number lives. Five answers, agreed at onboarding, that shorten the worst day your business has by a full working day.

04 · Verification

Proof, on a schedule.

Daily Job review. Every backup job checked the next morning. Failures are raised the same day, not discovered at quarter end.
Monthly Spot restore. A random file and a random mailbox, restored and confirmed. Small, fast, and it catches silent corruption early.
Quarterly Full restore test. A complete system restored from backup and timed. You get the evidence and the elapsed time against your target.
Annually Disaster rehearsal. Walk the full scenario with your leadership — declaration, comms, sequence, insurer. An hour that pays for itself once.

If your current provider cannot show you a dated restore test, you do not have a recovery capability. You have a subscription. The longer version — what to plan for, what to test, and how fast you can realistically be back — is in disaster recovery for Ottawa SMBs.

05 · Questions

The ones people actually ask.

If yours isn’t here, ask it directly — you’ll get an answer from an engineer, not a form letter.

Not in the way most people assume. Microsoft guarantees the platform, not your content — retention is limited, and a deletion or a ransomware event that syncs through OneDrive is your problem, not theirs. Microsoft’s own shared-responsibility model says this explicitly. We back the tenant up separately.

Days, not hours, for most small businesses — and anyone promising otherwise is guessing. What we can commit to is sequence and evidence: the order systems come back, the last known-good point for each, and a tested restore time per system rather than a marketing figure.

The off-site copy is written once and cannot be altered or deleted until its retention period expires — including by an administrator account. That matters because attackers now target backups deliberately, usually with credentials they have already stolen from you.

Usually. Databases need application-aware backup rather than a file copy, or you restore something that will not start. We check this at onboarding and tell you plainly if a vendor-specific method is required.

Yes, and that is often the right first step. A recovery review tests what you already own, times a real restore, and gives you written findings. Several clients have gone away, fixed two things, and kept their existing setup.

Canadian data residency by default, which matters for PIPEDA and for most professional obligations. If your sector requires something specific, tell us at onboarding and we will design to it rather than around it.

You get an export and thirty days to take it. No exit fee and no hostage-taking — your data was never ours to hold.

Recovery is a capability, not a product.

Start with a recovery review — we test what you already have and tell you what would actually happen. You keep the findings either way.