Backup & continuity
Backup and Disaster Recovery in Oakville
A backup you have never restored is a hypothesis. The first genuine test should not happen on the worst morning of your year.
At a glance
- Immutable copies that ransomware cannot alter
- Microsoft 365 data protected separately from the tenant
- Scheduled restore testing with documented results
- Recovery objectives agreed with the business, not assumed
Three disciplines that are not the same thing
Backup is the ability to retrieve data — a deleted file, a corrupted database, a mailbox emptied by mistake. Disaster recovery is the ability to bring systems back into operation after significant loss, within a defined timeframe. Business continuity is the ability of the organisation to keep functioning while recovery is underway, including the parts that are not technical at all.
Conflating them causes real damage. Plenty of organisations have complete backups and no realistic recovery capability, because restoring forty terabytes over an internet connection takes longer than their business can survive. Others have both and no continuity plan, so nobody knows who calls clients or how invoices go out during the outage.
- Backup: retrieve data that is lost or corrupted
- Disaster recovery: restore systems within a defined time
- Continuity: keep operating while recovery happens
Backup built to survive an attacker
Modern ransomware targets backups deliberately and often patiently — dwelling in an environment long enough that recent backup copies contain the same compromise. Immutability is the answer: copies that cannot be modified or deleted for a defined retention period, even with administrative credentials.
We combine local copies for speed with offsite immutable copies for resilience, keep backup infrastructure credentials separate from production identity, retain enough history to reach a known-good point before a dwell period, and monitor jobs so a silent failure is caught in days rather than discovered during a restore attempt.
- Immutable offsite copies with defined retention
- Local copies for fast routine restores
- Backup credentials isolated from production identity
- Server, endpoint, cloud workload and SaaS coverage
- Monitored jobs with alerting on failure
Microsoft 365 is not backed up by Microsoft
This surprises people regularly. Microsoft protects the platform and provides limited recycle bin and retention features. It does not provide the point-in-time recovery most organisations assume they have — and once retention windows lapse, deleted mail, SharePoint content, OneDrive files and Teams conversations are gone.
Third-party Microsoft 365 backup addresses the realistic scenarios: a departing employee clearing a mailbox, a sync error propagating deletions, ransomware encrypting files that then synchronise to the cloud, or a legal request for content deleted eighteen months ago.
Recovery objectives, tested rather than assumed
Recovery point objective is how much data you can afford to lose; recovery time objective is how long you can afford to be down. Both are business decisions with cost implications, and they differ per system — a practice management database may warrant fifteen minutes and two hours, while an archive server may be perfectly served by daily backup and a week.
We set these with the business, design to meet them, then test. Restore testing on a schedule, with documented results, is the only thing that converts an assumption into a capability — and it is the evidence insurers and auditors increasingly ask to see.
- Per-system RPO and RTO agreed with the business
- Documented recovery runbooks with sequence and dependencies
- Scheduled restore tests with recorded results
- Full recovery exercises for critical systems
- Continuity planning for the non-technical response
Keep exploring
Related Oakville services
Most engagements combine several of these. Follow the thread that matches the problem you are trying to solve.
Questions
Frequently asked questions
- How often should restores be tested?
- Routine file-level restores monthly, and a fuller recovery exercise for critical systems at least annually. The point is not just proving the data is readable — it is measuring how long recovery actually takes against the RTO you committed to.
- How long should backups be retained?
- It depends on your obligations and risk. Thirty days covers most operational mistakes, but ransomware dwell time and legal or regulatory retention requirements often push toward months or years for certain data. We size retention against both, because retention costs money and unnecessary retention is also a liability.
- What is the difference between disaster recovery and just having backups?
- Time. Backups hold the data; disaster recovery is the tested capability — infrastructure, runbooks, sequence and dependencies — to bring systems back within an agreed timeframe. Many organisations discover the gap only when they calculate how long restoring everything would actually take.
- Can you recover us if we are hit by ransomware?
- Recovery depends on what protection existed beforehand. With immutable offsite backups, tested restores and a documented plan, a clean recovery is realistic. Without them, options narrow sharply. If you are dealing with an active incident, call (289) 667-4000 and notify your insurer before altering affected systems.
When was your last documented restore test?
If the answer is uncertain, that is the finding. We will review coverage, immutability and recovery times and show you where the gaps are.