A project manager deletes the wrong SharePoint folder. A departing employee's OneDrive is removed before anyone transfers its files. A compromised account encrypts synchronized documents. Finance needs an email from nine months ago, but nobody can say whether it was retained, deleted, or ever protected by a backup policy.
All four situations are described casually as a need to restore Microsoft 365. They are not the same recovery problem. Microsoft 365 has recycle bins, version history, deleted-item recovery, retention policies, holds, and a separate Microsoft 365 Backup service. Independent backup products add other storage, management, coverage, and export choices. Each control has a purpose, a window, and a failure mode.
For a Toronto professional-services firm or an Ontario nonprofit, the useful question is not whether Microsoft backs up the cloud. The useful question is: can the organization recover the right email, file, site, or mailbox to the required point in time, within the time the business can tolerate, after the kind of incident it is preparing for? This guide helps Canadian small businesses answer that question without treating retention and backup as synonyms.
Four controls that are often confused
The easiest way to avoid an expensive misunderstanding is to name each control precisely. The following summary is intentionally practical; exact availability and licensing depend on the Microsoft 365 plan, workload, policy configuration, and backup provider in use.
| Control | Primary purpose | Useful for | Important limitation |
|---|---|---|---|
| Recycle bin or deleted-item recovery | Undo a recent deletion | A user removes a file, folder, email, or site and reports it promptly | The recovery window is limited and differs by workload |
| Version history or Files Restore | Return changed files to an earlier state | Accidental overwrites, mass changes, corruption, or recent ransomware impact | Effectiveness depends on workload features, versions, permissions, and time window |
| Purview retention or hold | Preserve or dispose of content according to policy | Records, investigations, legal obligations, and defensible lifecycle rules | Preservation is not automatically a simple operational restore experience |
| Backup | Create recoverable points and restore protected content after an incident | Point-in-time recovery, broad deletion, compromised accounts, and operational continuity | Only configured workloads, users, sites, and time periods are protected |
What native recovery can do well
Native recovery is valuable and should be part of the plan. Microsoft states that the SharePoint and OneDrive first-stage and second-stage recycle bins share a 93-day period. Exchange Online's Recoverable Items folder uses a default deleted-item retention period of 14 days, which an administrator can increase to a maximum of 30 days for mailboxes. These windows are useful for recent, known deletions when someone notices the problem in time.
SharePoint and OneDrive also support version-based recovery. Microsoft's resiliency documentation describes Files Restore for returning a document library to a point within the previous 30 days. That can be effective after mass edits, corruption, or ransomware, but the recovery design must account for version settings and the possibility that the compromised identity also has destructive permissions.
A built-in feature can be the fastest answer to a small incident. It becomes risky when the business assumes the window is longer than it is, does not know who can perform the restore, or discovers that the affected workload and scenario behave differently from the one tested last year.
Why retention is not the same as a restore plan
Microsoft Purview retention policies and labels decide whether content must be retained, deleted, or retained and then deleted. They can apply to workloads including Exchange, SharePoint, OneDrive, Teams, and other Microsoft 365 locations. Their purpose is information lifecycle and compliance: keeping information for a required period and disposing of it when policy says it should no longer exist.
That preserved copy may help recover content, but a retention rule should not be presented to management as a complete backup without testing the exact restore workflow. Ask who can find the item, whether metadata and permissions are restored, whether an entire site or mailbox can return to a chosen point, how long the operation takes, and what happens when the original user has been deleted.
Retention can also intentionally delete content. A policy that keeps records forever may conflict with privacy and disposal obligations; a policy that deletes too soon can remove evidence the business needs. The Office of the Privacy Commissioner of Canada advises organizations to keep personal information only as long as needed for identified purposes or legal requirements, then dispose of it securely. Backup retention must be part of that lifecycle—not an invisible exception to it.
What Microsoft 365 Backup provides in 2026
Microsoft 365 Backup is a separate pay-as-you-go service administered through the Microsoft 365 environment. Microsoft's current overview lists protection for OneDrive, SharePoint, and Exchange Online, with a one-year retention period. For OneDrive and SharePoint, it describes frequent standard restore points for the recent two-week period and less frequent express restore points farther back. For Exchange Online, it describes ten-minute recovery points across the prior 52 weeks.
The service supports full and granular recovery options, depending on workload and scenario. Microsoft's restore guidance includes full OneDrive account and SharePoint site restores, selected file and folder recovery, and Exchange mailbox or item recovery. Backup data stays within the protected service's Microsoft 365 data boundary, which may simplify architecture for organizations that prefer Microsoft-native administration.
A one-year product description does not mean every item is automatically protected for a year. Administrators must create and monitor policies for the intended mailboxes, accounts, and sites. Microsoft notes that backups for a deleted user remain available for the restore point's 365-day retention period, but offboarding procedures still need to verify that the user was protected before deletion and that an authorized administrator knows how to recover the data.
When to evaluate an independent backup service
An independent Microsoft 365 backup service may be appropriate when the organization wants storage or administrative separation, a retention period longer or more customizable than the native service, additional workload coverage, cross-user restore workflows, export options, consolidated backup across several platforms, or a managed provider responsible for monitoring and testing.
Independent does not automatically mean safer. The provider becomes another system handling business and possibly personal information. Review identity controls, encryption, data location, subcontractors, audit logs, deletion commitments, recovery objectives, service availability, data export, incident notification, and what happens when the contract ends. The Office of the Privacy Commissioner of Canada emphasizes that an organization remains accountable for personal information processed by a cloud provider.
Compare demonstrated outcomes rather than marketing labels. Ask each provider to restore one mailbox item, one folder with permissions, one deleted user's content, and a larger site to a chosen point. Record the elapsed time, restored fidelity, administrator steps, audit evidence, and any extra charges.
Match the control to the recovery scenario
| Scenario | First recovery path to test | Planning question |
|---|---|---|
| One recently deleted file | Recycle bin or version history | Can the user or administrator restore it within the documented window? |
| Hundreds of encrypted or overwritten files | Files Restore or point-in-time backup | Can the team identify a clean time and restore at scale without reintroducing malware? |
| Deleted employee account | Offboarding retention and protected backup | Was the user's mailbox and OneDrive included before the account was removed? |
| Email needed for a record request | Purview retention, hold, search, or backup as designed | Is the goal legal preservation, discovery, or operational restoration? |
| Compromised global administrator | Secured backup administration and incident recovery | Can the attacker alter policies or delete recovery data with the same identity? |
| Large SharePoint site deleted | Native site recovery or protected site restore | How long will full restoration take, and what happens to permissions and sharing links? |
A 10-step Microsoft 365 backup and recovery plan
1. Inventory business data and owners
List active and shared Exchange mailboxes, OneDrive accounts, SharePoint sites, Teams-connected sites, Microsoft 365 groups, Power Platform environments, and data held in third-party applications. Assign a business owner and sensitivity level. Do not assume that protecting Exchange, OneDrive, and SharePoint also protects every Teams message, Planner board, Power BI workspace, Forms response, or Power Platform record in the way the business expects.
2. Write the incidents the plan must survive
Use concrete statements: recover an accidentally deleted client folder; restore a mailbox after account compromise; return a SharePoint library to the point before ransomware; recover a former employee's files; produce retained correspondence; or rebuild collaboration after a tenant-wide administrative incident. A product comparison is meaningful only when it is tested against an agreed scenario.
3. Set recovery point and recovery time objectives
The recovery point objective, or RPO, is the maximum acceptable amount of recent change that could be lost. The recovery time objective, or RTO, is how quickly the service or data must be usable again. A mailbox used for general correspondence may tolerate a different RPO and RTO than a SharePoint site used to dispatch field work or approve customer orders.
4. Separate operational recovery from record retention
Document how long information must be available for business recovery, how long it must be retained for legal or regulatory purposes, and when it should be deleted. These periods may differ. Involve the appropriate privacy, legal, finance, and records owners; an IT administrator should not invent a universal seven-year rule for every mailbox and file.
5. Verify protection coverage, not just licensing
Export or review the protected mailbox, OneDrive, and SharePoint lists. Compare them with the inventory. Look for new employees, new sites, renamed groups, deleted accounts, shared mailboxes, and sites excluded during a pilot. If the service supports automatic onboarding rules, test them; if it does not, make coverage review part of employee and site provisioning.
6. Protect backup administration
Require phishing-resistant multifactor authentication where supported, least-privilege roles, separate administrator identities, protected emergency access, alerts for policy changes, and audit logging. Limit who can restore sensitive mail or files because restore access can expose information the administrator could not normally read. For independent backup, avoid using one standing global administrator credential when a narrower, application-specific authorization model is available.
7. Make recovery part of offboarding
Before removing a licence or account, confirm who owns the mailbox and OneDrive data, whether a legal or business retention requirement applies, whether protection is active, and how future access will work. Transfer business-owned files to an appropriate team location instead of treating a former employee's OneDrive as permanent departmental storage.
8. Monitor policies, failures, capacity, and cost
A green subscription status is not enough. Review policy health, protected-object count, failed or delayed restore points, storage growth, unusual policy changes, deleted users, and billing anomalies. Assign a named owner and an escalation path. For a managed IT service, define which findings create a ticket, who receives it, and the response target.
9. Test representative restores every quarter
Restore a recent email, an older attachment, a OneDrive folder, selected SharePoint content, and a larger object relevant to the business. Include a deleted-user scenario and a ransomware-style point-in-time scenario at least annually. Verify content, timestamps, metadata, permissions, sharing, search, and application usability—not only that the restore job says complete.
10. Document the recovery runbook and vendor exit
Record incident triage, clean-point selection, administrator roles, identity recovery, malware containment, restore order, validation, employee communication, and escalation contacts. Document how backup data is exported or deleted if the organization changes providers. Keep a protected copy of the runbook somewhere the team can reach when Microsoft 365 sign-in is unavailable.
Backup is one layer of ransomware recovery
The Canadian Centre for Cyber Security's January 2026 ransomware guidance warns that attackers with broad control may encrypt production data and delete connected backups. Recovery therefore begins with containment and identity security, not an immediate bulk restore. Determine how the attacker entered, disable compromised access, preserve evidence, identify a clean recovery point, and prevent restored content from synchronizing back into an infected device or session.
Backup also does not replace endpoint protection, patching, MFA, email security, least privilege, or employee verification procedures. It reduces the impact of some incidents when prevention fails. The strongest plan combines protected recovery data with controls that make compromise less likely and detection faster.
Questions to ask a backup provider
- Which Microsoft 365 workloads and object types are protected, and which are excluded?
- How frequently are restore points created, and how long is each type retained?
- Can we restore one item, a folder, a mailbox, a OneDrive account, and a SharePoint site?
- What metadata, permissions, versions, sharing links, and folder structure return after restore?
- How are new users, shared mailboxes, groups, and sites added automatically?
- Can backup policies or recovery data be changed by the same compromised administrator identity?
- Where is data processed and stored, and which subprocessors can access it?
- How are restores, exports, policy changes, and administrator actions logged?
- What are the expected restore time, throughput limits, and support escalation path?
- How do pricing, minimums, egress, restore, retention, and deleted-user charges work?
- How can we export or securely delete our backup data when the service ends?
- Will the provider demonstrate our recovery scenarios before we sign?
A realistic 30-day starting plan
| Week | Action | Evidence |
|---|---|---|
| 1 | Inventory workloads, owners, sensitive data, and recovery scenarios | Approved scope and risk list |
| 2 | Define RPO, RTO, retention, coverage, administration, and provider criteria | Recovery requirements and shortlist |
| 3 | Configure a representative pilot and protect its administrators | Policy export, access review, and monitoring |
| 4 | Run granular, deleted-user, and point-in-time restores | Timed test record, issues, owners, and go/no-go decision |
The result should be a decision supported by restore evidence, not a licence count. A ten-person company may need a simple native configuration with disciplined testing. A larger or regulated business may need longer retention, administrative separation, broader workload coverage, or a managed recovery service. The right design follows the business requirement.