Disaster recovery and business continuity.

Disaster recovery is the unglamorous part of IT. Nobody wins promotions for restoring a server. But it is the discipline that decides whether a bad day becomes a survivable incident or a closing-the-business event.

The scenarios to plan for

• Hardware failure. Most common. A server, a SAN, a firewall. Mature DR handles this in hours.
• Ransomware. The hardest scenario, because the attacker may have been inside for weeks before encryption. Restoration must skip the period of compromise.
• Insider error. Someone runs the wrong script, deletes the wrong folder, drops the wrong table. Often discovered weeks later.
• Site loss. Fire, flood, prolonged power outage, prolonged building inaccessibility. Less common but most disruptive.
• Cloud-provider outage. Rare but real. M365 has had multi-region outages within the last 24 months.

The numbers that matter

Two numbers anchor every DR plan:

Recovery Time Objective (RTO). How long you can be down. For a dental clinic, this might be 2 hours — beyond that you are sending patients home. For a manufacturing plant, hours of production loss per day. For an accounting firm in tax season, hours.

Recovery Point Objective (RPO). How much data loss is acceptable. For most SMBs, somewhere between 15 minutes and 4 hours. The customer-record database for a clinic might tolerate 15 minutes; an internal file share, 4 hours.

Both are business decisions, set by the leadership team, then engineered to. IT does not set RTO/RPO unilaterally.

The backup architecture

The current standard is "3-2-1-1":

• 3 copies of your data — production plus two backups.
• 2 different media — at minimum, on-prem fast storage plus cloud or tape.
• 1 off-site — geographically separate from your primary site.
• 1 immutable — cannot be deleted or overwritten by anyone, including a domain admin or an attacker. Object-lock cloud storage or hardened on-prem repositories.

The immutable copy is the line that ransomware cannot cross. Without it, an attacker with domain admin systematically destroys your backups before encrypting your production data — which is exactly what they do, every time.

The test cadence

• Monthly: Restore individual files from backup. Logged. If a restore fails, the cause is investigated and fixed.
• Quarterly: Restore a full server (or virtualised workload) to an isolated environment. Validate it boots, services start, application logs in.
• Annually: Full DR exercise. Simulate a site loss. Stand up alternate infrastructure (cloud or DR site). Restore production data. Have a real business user validate they can do their job. Time it.

This is the part most plans skip. A plan that has never been tested is a hope, not a plan.

The BCP layer

DR restores systems. BCP keeps the business running while DR is in progress. Typical BCP elements:

• Communication tree. Who calls whom, by what channel, in what order. Phone numbers documented off-system.
• Decision authority. Who decides "we are invoking DR" and "we are paying the ransom." Defined in advance, not at 3 AM.
• Workaround procedures. Paper backup of the appointment book. Manual receipts at the till. Offline copies of critical contracts.
• Vendor contacts. Insurance, legal, IR firm, cyber-insurance breach hotline. All on a printed wallet card the leadership team carries.
• Public communications. Pre-drafted holding statements for "we are dealing with an incident."

What 4UIT covers

For managed customers, our standard build includes 3-2-1-1 backup with Canadian-region off-site storage and immutable copies, monthly logged restore drills, quarterly full-server recovery tests, and an annual DR exercise. We also help write the BCP itself — the parts that involve people, not servers — so your privacy officer or operations lead has something to actually run.

More on our backup & DR services or talk to us.

// Frequently asked questions