Microsoft 365 backup: the cloud is available. Can you recover your data?

On Monday morning, the project folder is missing. Not just from one laptop, but from the browser and a colleague’s computer as well. A mistake has been synchronised reliably. Alternatively, an automated process has overwritten large numbers of documents with incorrect content over the weekend. Microsoft 365 is still running. The company can no longer work with the affected information.

These are hypothetical scenarios, not customer stories. They illustrate a common misunderstanding: platform availability and recovery of an earlier data state answer different questions. For an SME, the practical issue is whether it can resume preparing quotations, delivering projects and serving customers reliably after an incident.

My recommendation is not to start by buying a backup product. Start with a demonstrated restore. If nobody can explain which critical business data can be recovered, and by when, the first problem is a knowledge gap. Only then can you decide whether existing capabilities are sufficient or additional protection is necessary.

Sources checked on 21 September 2026. The linked Microsoft documentation was reviewed for this article. Product statements come from the manufacturer; the priorities, test plan and worked examples are our recommendations or explicitly hypothetical scenarios.

Synchronisation keeps working data aligned across devices and services. That supports collaboration, but it does not prove that a required historical state is still available. Versions and recycle bins help with many everyday mistakes. Retention serves other objectives, such as preserving specified information. A backup strategy should instead start with the recovery outcome the business needs.

Microsoft’s backup FAQ distinguishes current disaster-recovery copies, versions and historical recovery. Versions can have limitations for widespread damage; legal holds are not optimised for mass restoration. This does not make existing capabilities worthless. They must match the incident you need to address.

This table is a decision aid, not a comprehensive feature comparison. Whether built-in capabilities can resolve a particular incident depends on configuration, data type and timing, among other factors. Do not accept a blanket assurance that “everything is backed up”, including from your own IT team.

The recovery point objective, or RPO, expresses the maximum tolerable data loss as a period of time. If four hours is acceptable, no more than that window of work should be lost in the agreed scenario. The recovery time objective, RTO, expresses the target time to recover. Having today’s backup is of limited use if nobody can use it until next week.

Set both objectives by business process. One working day might be acceptable for a rarely used template library. For the documents supporting an active tender, that could be too late. These examples are not industry standards. Business owners must assess what disruption their operation can tolerate and which temporary alternatives are viable.

Also define when the clock starts. Technical restoration is only one part of the interruption. Detection, escalation, approval and business validation take time as well. Measuring only the duration of a restore job can produce a green report while employees remain unable to work.

According to Microsoft’s product overview, Microsoft 365 Backup protects selected SharePoint sites, OneDrive accounts and Exchange mailboxes. Backups remain within Microsoft 365 data boundaries. That is not automatically an independent copy held by a second provider. The documentation was last updated on 18 August 2026; check specific capabilities and policies in your own tenant before purchasing.

Translate product names into an inventory. “We back up Teams” is too vague as a requirement. Ask separately about files, conversations, settings, tasks and connected applications: where does the data live, what is actually protected, and how is it recovered? Protecting a storage location does not demonstrate that an entire working environment can be reconstructed.

The same applies to identities and permissions. Check which accounts, groups, sharing arrangements and applications will be needed after restoration. Record gaps explicitly. A clearly bounded scope is better than a comprehensive-sounding promise whose meaning has to be negotiated during an incident.

A native service can be appropriate when it covers the prioritised data and achieves the required recovery outcome in testing. A third-party solution may meet additional requirements. The logo is not the deciding factor: ask about storage location, administrative separation, dependencies and recovery procedures. An additional management interface alone does not establish greater independence.

Include three scenarios in your evaluation: accidental deletion, widespread data corruption, and loss of access to normal administration. Ask every provider to explain what works in each case, which prerequisites apply and what is explicitly excluded. Request a demonstration using representative test data rather than relying entirely on a product presentation.

For Swiss SMEs, contractual questions also belong on the checklist: agreed data locations, participating service providers, support access, export options and arrangements at contract termination. Do not assume that “cloud in Switzerland” means every component receives identical treatment. Obtain required commitments in writing; this article is not a substitute for individual legal advice.

The Microsoft pricing documentation lists USD 0.15 per GB of protected content per month. What matters is billable protected volume, not just the visible total of current files. Retained deleted content and certain versions can count too. Consequently, a clean-up does not necessarily reduce the bill immediately.

Our example assumes a constant 2,000 GB of billable volume. That produces USD 300 a month or USD 3,600 a year. An assumed 3,000 GB would cost USD 450 a month. This is not a quotation, a forecast of your data growth or a Swiss final price. Exchange rates, taxes, contract terms and operational services are excluded.

Add configuration, monitoring, testing and incident support to your calculation. Compare offers using the same scope and assumptions. Manual work can outweigh an inexpensive licence; an expensive package is not automatically better either. The relevant question is which verifiable outcome you receive for the total budget.

The other side of the calculation needs assumptions too. Consider twenty affected employees, four hours of disruption and an internal cost assumption of CHF 70 per hour. That represents CHF 5,600 of affected working capacity. It is neither proven lost revenue nor automatically a fully avoidable loss. Some work can be rescheduled; other work cannot.

Recovery effort, deadline consequences and potential customer impacts should be considered separately. Do not add these amounts blindly when they represent effects already counted elsewhere. The purpose is a defensible decision, not the most dramatic possible loss figure. Often the useful starting question is simply: which process could not tolerate half a day of interruption tomorrow?

The answer helps prioritise coverage. Do not automatically protect the largest storage consumer first. Start where missing information would disrupt the business most severely. Then expand deliberately, documenting the decision for areas that remain outside the initial scope.

Use an approved test environment containing non-sensitive, representative data. Do not delete or overwrite production customer information for an impromptu demonstration. Define a known starting state, an expected recovery point and business acceptance criteria in advance. State whether the exercise covers individual items or a larger area.

• Prepare: Document test files, versions, sample messages and required access. Name an owner and a deputy.
• Simulate: Introduce the agreed error only in the test area and record its timing.
• Restore: Follow the intended procedure, including approval and communication. Avoid undocumented shortcuts performed by the only expert.
• Validate: Open the content, check completeness and verify access using a normal test account.
• Improve: Record measured times, missing data and manual steps. Assign owners and deadlines to deviations.

Have a second administrator follow the instructions. If the process works only through one person’s memory, it is not yet dependable. Repeat testing after significant changes and schedule regular exercises; the appropriate frequency depends on risk and the pace of change.

Acceptance should describe observable outcomes. “Restore completed” is weaker than “the project owner opened the agreed document set, confirmed the expected versions and resumed the test workflow”. Do not let an attractive dashboard replace that final business check. Save the evidence and the approved exceptions alongside the procedure so the next exercise starts from what was actually learned.

Week one: Business teams and IT identify key processes, data locations, owners and recovery objectives. Review existing contracts and protection policies before ordering more licences. The deliverable is a short overview with clear outstanding questions, not a hundred-page strategy.

Week two: Run the first approved recovery test. If built-in capabilities cover the agreed scenario, document that just as clearly as a gap. A legitimate test outcome is that no additional purchase is necessary. It must not imply broader protection than the exercise actually demonstrated.

Week three: Close prioritised gaps through configuration, procedures or a suitable backup solution. Separate day-to-day administration from particularly sensitive actions where practical. Ensure escalation contacts and instructions remain accessible if normal workplace access becomes unavailable.

Week four: Repeat the test with the deputy and business acceptance. Agree how new data areas, errors and costs will be reviewed. Newly created sites or accounts must be included in the intended protection process; nobody should have to hope that somebody else remembered to do it.

At the end of the month, management should receive a concise decision record: what is covered, what was successfully tested, what remains uncertain and which risks have been accepted. Keep this separate from vendor marketing material. The document should still make sense to a new manager or support partner who was not present during implementation.

Microsoft 365 removes a substantial infrastructure burden. Deciding which information must become usable again, and how quickly, nevertheless remains a business responsibility. A workable approach combines suitable technology with clear ownership, tested instructions and realistic costs.

The best next step is concrete: select one important process and agree a controlled restore test. It will tell you more than ten general discussions about whether the cloud is secure enough. Use the result to improve the weakest part of your actual recovery chain, whether that is coverage, administration, documentation or business validation.