For Australian IT teams and MSPs, the recommended starting point is Microsoft 365 Backup as your baseline: it delivers 10-minute RPO for Exchange mailboxes, pay-as-you-go storage, and fast in-place restores without a separate infrastructure layer. Layer a third-party backup product or a Stanfieldit managed backup service on top when you need advanced granular search, legal discovery, custom scheduling, or extended immutability beyond what the native platform provides.
Microsoft’s high-availability SLA protects the platform, not your data. Customer-side deletion, ransomware, and accidental overwrites are your responsibility to recover from, and Microsoft’s own adoption guidance is clear on this point.
When native Microsoft 365 Backup is enough:
- Organisations with straightforward restore needs (mailbox, OneDrive, SharePoint site recovery)
- Teams with internal IT capacity to manage policies and run restore drills
- Businesses where a 10-minute RPO and same-day RTO meet the SLA
When to add a third-party backup product:
- You need granular item-level search across large tenants
- Legal discovery or eDiscovery workflows require exportable, searchable archives
- Custom backup scheduling or longer immutability windows are required
When to contract a managed service (Stanfieldit):
- Internal IT capacity is limited or the team lacks backup operations experience
- Compliance obligations (healthcare, legal, financial services) require documented SLAs and audit trails
- You want proactive monitoring, restore testing, and reporting without building it in-house
Table of Contents
- What does Microsoft 365 Backup actually cover, workload by workload?
- How Microsoft 365 Backup works: architecture, storage and restore performance
- Native, third-party, or managed: which backup approach fits your organisation?
- How do you actually restore data in Microsoft 365 Backup?
- Retention windows, append-only storage, and Australian compliance considerations
- What does Microsoft 365 Backup cost, and how should you budget for it?
- How to deploy and operate Microsoft 365 Backup: a practical checklist
- Why many Australian organisations still add third-party or managed backup
- How do you choose the right backup approach for your organisation?
- Data sovereignty and Australian data protection law: what IT teams need to know
- Integrating Microsoft 365 backups into your broader business continuity plan
- Key takeaways
- When native backup is not enough: a practitioner’s view
- Stanfieldit’s managed Microsoft 365 backup and recovery service
- Useful sources
What does Microsoft 365 Backup actually cover, workload by workload?
Microsoft 365 Backup protects Exchange Online, OneDrive for Business, and SharePoint Online. Teams channel files are covered indirectly via their underlying SharePoint sites. Teams chats are not currently covered. Power Platform and Planner are outside the native backup scope.
| Workload | Restore granularity | RPO window | Key caveats |
|---|---|---|---|
| Exchange Online | Item-level (email, calendar, contacts) | 10 minutes for prior 52 weeks | Full mailbox restore available; item search in restore UI |
| OneDrive for Business | Full account restore | 10 minutes for recent 14 days; weekly snapshots from 14–365 days | Point-in-time rollback; content after restore point is overwritten |
| SharePoint Online | Full site restore | 10 minutes for recent 14 days; weekly snapshots from 14–365 days | In-place or new URL; content after restore point is overwritten |
| Teams channel files | Via SharePoint site | Same as SharePoint | Site must be in protection policy; chat history not covered |
| Teams chats | Not covered | N/A | Requires third-party solution or Purview retention |
| Power Platform / Planner | Not covered | N/A | Requires third-party or manual export strategy |
Feature highlights worth noting:
- Express restore points for OneDrive and SharePoint deliver faster full account and site recovery than standard restore points
- Restore UI includes search and filter to locate specific items or versions
- Full site and account fidelity is maintained at the restore point
- Storage is pay-as-you-go, billed on consumption rather than per-seat
The Teams chat gap is a common blind spot for Australian organisations. If your business relies on Teams for client communication or project records, a third-party solution or Microsoft Purview retention policy is the only way to protect that data.
Industry guidance also highlights that configuration state, permissions, and collaborative workloads like Planner and Power Platform are frequently overlooked in backup scope planning, creating recovery blind spots that only surface during an actual incident.
How Microsoft 365 Backup works: architecture, storage and restore performance
Microsoft 365 Backup is built on the Backup Storage API, an append-only storage layer that sits within the Microsoft 365 trust boundary. Backups are written to append-only storage, meaning existing backup data cannot be modified or deleted by normal tenant operations. This architecture is what gives the platform its immutability-adjacent behaviour, though it is not a fully certified immutable storage system in the regulatory sense.
Storage and geo-residency: Backup data is stored in the same Microsoft 365 geo as your tenant. For Australian tenants, that means data stays within the Australia geo by default, which matters for Privacy Act compliance and data sovereignty. Partner applications built on the Backup Storage API inherit this geo-residency model.
Restore performance expectations: Microsoft publishes guidance on expected restore windows based on protection unit count. Actual performance depends on data volume, tenant configuration, and whether you use express or standard restore points.
| Protection units | Approximate restore window |
|---|---|
| 1 unit (single mailbox, site, or account) | Minutes to low hours |
| — | Hours (same business day) |
| — | Hours to overnight |
| — | Multi-day bulk recovery |
These are guidance ranges, not contractual SLAs. For large tenants, bulk recovery of many sites simultaneously will take longer than a single-site restore, and you should validate real-world RTOs in your environment during pilot testing rather than relying solely on published estimates.
Pro Tip: Use express restore points for OneDrive and SharePoint when your recovery goal is a full account or site rollback. Standard restore points are sufficient for Exchange item-level restores when you are recovering individual emails or calendar items rather than an entire mailbox.
Native, third-party, or managed: which backup approach fits your organisation?
The right approach depends on your compliance obligations, internal capacity, and how complex your recovery scenarios are. Here is how the three options compare across the dimensions that matter most.
| Dimension | Native Microsoft 365 Backup | Third-party backup product | Stanfieldit managed backup service |
|---|---|---|---|
| Workloads covered | Exchange, OneDrive, SharePoint, Teams files (via SharePoint) | Varies; typically broader (Teams chat, Planner, Power Platform) | Configured to your scope; includes gap workloads |
| Restore granularity | Item-level (Exchange), full account/site (OneDrive/SharePoint) | Advanced item-level search, exportable archives | Delegated restores with helpdesk integration |
| RTO / RPO | 10-min RPO; RTO from minutes to multi-day depending on scale | Varies by vendor and architecture | SLA-backed; tested and documented |
| Retention and immutability | Up to 365 days; append-only storage; 90-day offboarding window | Configurable; some vendors offer certified immutable storage | Policy-managed; aligned to compliance requirements |
| Admin and delegation | Global admin or backup admin role required | Role-based; often more granular delegation | Managed by Stanfieldit with client-side reporting |
| Pricing model | Pay-as-you-go storage consumption | Per-mailbox, per-GB, or tiered per-seat | Included in managed service agreement |
| Data residency | Microsoft 365 geo (Australia for AU tenants) | Depends on vendor; verify AU data centre availability | Verified and documented for Australian compliance |
| Security features | Encryption at rest and in transit; MFA; within Microsoft trust boundary | Varies; check encryption, MFA, and immutable storage claims | Stanfieldit-managed security controls and audit logging |
When native is the right call: Your organisation has a capable internal IT team, restore scenarios are straightforward, and compliance requirements do not demand eDiscovery-grade search or certified immutability.
When to add a third-party product: Industry commentary consistently points to advanced granular search, scheduling flexibility, and legal discovery workflows as the capabilities that native tools do not match. If your legal team has ever asked for a mailbox export or a point-in-time Teams chat archive, a third-party product is worth the investment.
When to contract Stanfieldit: Your team does not have the bandwidth to manage backup policies, run restore drills, and produce compliance evidence on a regular cadence. Outsourcing to a managed service means you get a documented SLA, proactive monitoring, and a tested runbook without building the capability in-house.
Pro Tip: Before committing to any approach, run a tabletop exercise with your legal and compliance stakeholders. Ask them: “If we needed to produce all emails and Teams messages from a specific project over the last 18 months, how would we do it?” The answer will tell you whether native backup alone is sufficient.
How do you actually restore data in Microsoft 365 Backup?
The restore workflow differs slightly depending on the workload, but the general pattern is consistent: select the protection unit, choose a restore point, configure the destination, and initiate the restore session.
Granular item restore (Exchange):
- Open the Microsoft 365 admin centre and navigate to the Backup and restore section.
- Select the mailbox you want to restore from.
- Choose a restore point (10-minute granularity for the prior 52 weeks).
- Search or filter for the specific items (emails, calendar entries, contacts) to recover.
- Select the destination (in-place or alternate mailbox) and confirm.
- Monitor the restore session; session history is retained for 366 days for audit purposes.
Full OneDrive or SharePoint site restore:
- Select the OneDrive account or SharePoint site from the protection policy.
- Choose between express or standard restore point. Express is recommended for full account or site rollbacks.
- Select in-place restore (overwrites current state to the restore point) or restore to a new URL.
- Confirm and monitor progress.
Pro Tip: For large SharePoint sites, always restore to a new URL first. Copy only the content you need back to the live site. A full in-place restore overwrites everything after the restore point, including content users may have created legitimately after an incident began. The roll-forward approach avoids that data loss.
Teams channel file recovery follows the SharePoint path: the underlying SharePoint site must be in your protection policy, and you restore the site to recover the files. Teams chat recovery requires a separate solution.
Microsoft’s restore documentation covers the full step sequence and session management details.
Retention windows, append-only storage, and Australian compliance considerations
Microsoft 365 Backup retains data for about one year by default. Restore point frequency differs between workloads: Exchange maintains 10-minute restore points throughout the retention period, while OneDrive and SharePoint have 10-minute points for the most recent two weeks, then weekly snapshots thereafter.
| Workload | Retention period | Restore point frequency (recent) | Restore point frequency (older) |
|---|---|---|---|
| Exchange Online | 52 weeks | 10 minutes | 10 minutes (full period) |
| OneDrive for Business | 52 weeks | 10 minutes (0–14 days) | Weekly snapshots from 14–365 days |
| SharePoint Online | 52 weeks | 10 minutes (0–14 days) | Weekly snapshots from 14–365 days |
Append-only storage in practice: The Backup Storage API writes to append-only storage, meaning backup data cannot be overwritten or deleted through normal tenant operations. Microsoft documents a 90-day offboarding recovery window: if a user is offboarded or a site is deleted, the backup remains accessible for 90 days while the backup policy is active. This approximates immutability for most operational scenarios, but it is not a formally certified immutable storage system.
Australian compliance checklist:
- Data residency: — Confirm your Microsoft 365 tenant is provisioned in the Australia geo. Backup data inherits this residency. Document this for Privacy Act and sector-specific audits.
What does Microsoft 365 Backup cost, and how should you budget for it?
Microsoft 365 Backup uses a pay-as-you-go consumption model: you pay for the storage consumed by your backup data, not a flat per-seat fee. The Microsoft 365 Backup product page lists current storage pricing, which varies by region and is subject to change.
Key cost drivers to model:
- Multi-geo tenancy: — If your organisation spans multiple Microsoft 365 geos, backup storage costs apply per geo.
Pro Tip: When modelling TCO for Australian organisations, factor in the cost of a restore drill. Running quarterly restore tests against a representative sample of protection units consumes storage throughput and staff time. Budget for at least four drills per year and include the time to document results for compliance evidence.
How to deploy and operate Microsoft 365 Backup: a practical checklist
A structured deployment reduces the risk of gaps in coverage and makes ongoing operations manageable for a small IT team or MSP.
Implementation milestones:
- Planning: Define scope (which mailboxes, OneDrive accounts, and SharePoint sites to protect), assign the Backup Admin role, and confirm data residency settings.
- Pilot: Apply protection policies to a representative subset (10–20 protection units). Validate backup frequency, storage consumption, and restore workflows before full rollout.
- Full rollout: Expand policies to all in-scope protection units. Document the policy configuration and role assignments.
- Monitoring and reporting: Configure alerts for backup policy failures. Review restore session history monthly. Report backup health to stakeholders quarterly.
- Offboarding procedures: When a user leaves or a site is decommissioned, confirm the backup policy remains active for the 90-day offboarding window before removing the protection unit.
Operational runbook items:
- Assign a named Backup Admin who is separate from the Global Admin role where possible (role separation reduces blast radius in a compromise scenario).
- Schedule quarterly restore drills: test at least one mailbox item restore, one OneDrive account restore, and one SharePoint site restore each quarter.
- Document RTO results from each drill and compare against your SLA commitments.
- Review retention lifecycle annually: confirm that retention periods still meet regulatory requirements as your business or client base changes.
Pro Tip: Keep your restore runbook as a shared document accessible to at least two people in your organisation. A runbook that only one person knows about is a single point of failure. For MSPs, store the runbook in your PSA or documentation platform so any technician can execute a restore without escalation.
A disaster recovery plan template can help you structure the runbook and define success criteria for each restore scenario.
Why many Australian organisations still add third-party or managed backup
Microsoft’s adoption guidance is direct: business continuity requires moving beyond recycle bins. Fast, scalable recovery, whether native or via an ISV, avoids the weeks-long recovery windows that manual methods produce. The guidance also acknowledges that customers control their own data and are responsible for protecting it from customer-side events.
The practical gap that pushes organisations toward third-party or managed solutions is granularity and operational capacity. Third-party platforms built on the Backup Storage API typically provide more advanced search-based discovery and item-level restore workflows, which reduces helpdesk load during incidents. For a healthcare practice that needs to locate a specific patient communication from 14 months ago, or a law firm responding to a discovery request, that search capability is the difference between a two-hour resolution and a two-day one.
Next-steps checklist for MSPs presenting to executive stakeholders:
- Risk score the tenant: Identify the workloads with the highest data loss impact (typically Exchange and SharePoint) and confirm they are in the protection policy.
- Document the coverage gaps: Teams chats, Power Platform, and Planner are outside native backup scope. Present these gaps with a recommended remediation (third-party solution or Purview retention).
- Propose a pilot plan: A 30-day pilot covering a representative sample of protection units, with a documented restore drill and RTO measurement, gives stakeholders evidence before committing to full rollout.
- Define the SLA: Agree on RPO and RTO targets with the business before deployment, not after an incident.
- Plan the testing cadence: Quarterly restore drills with documented results are the minimum for a defensible compliance position.
Local context for Australian organisations: Data residency verification is a mandatory step, not an optional one. Confirm your tenant geo in the Microsoft 365 admin centre before enabling backup policies. For healthcare and professional services clients, document the geo confirmation as part of your compliance evidence pack. When the complexity of compliance evidence, audit logging, and regular testing exceeds your internal capacity, Stanfieldit’s managed backup service provides a structured engagement with documented SLAs and reporting.
Pro Tip: When presenting a backup proposal to a client’s board or executive team, frame the conversation around recovery time, not backup frequency. Executives understand “we can recover your email from this morning in under two hours” far better than “we have a 10-minute RPO.” Translate the technical spec into a business outcome every time.
How do you choose the right backup approach for your organisation?
Start with three questions: What is your compliance obligation? What is your internal restore capability? What is your tolerance for data loss?
Decision flow:
- Identify regulated workloads. If your organisation operates in healthcare, legal, or financial services, confirm which data classes require retention beyond 365 days or certified immutability. If yes, native backup alone is insufficient.
- Assess internal restore capability. Can your team execute a full site restore, document the result, and report it to a compliance officer without external help? If no, a managed service is the lower-risk option.
- Map your recovery scenarios. List the five most likely data loss events your organisation could face (accidental deletion, ransomware, user error, offboarding, migration error). For each, confirm that your chosen backup approach can recover the data within your RTO.
- Check Teams chat and Power Platform coverage. If either workload contains business-critical data, add a third-party solution or Purview retention policy before going live.
- Validate data residency. Confirm backup data stays in the Australia geo. Document the confirmation.
Red flags that push you away from native-only:
- Active or anticipated legal holds on mailboxes or SharePoint sites
- eDiscovery requests that require searchable, exportable archives
- Multi-geo tenancy with data in regions outside Australia
- No internal staff with backup admin experience
- Regulatory requirements for retention beyond 365 days
- Teams chats containing client-facing or legally significant communications
Stakeholder questions to ask during procurement:
- Have we ever received a legal discovery request, and how did we respond?
- What is the longest acceptable outage for our email or SharePoint environment?
- Who is responsible for running and documenting restore tests?
- Do we have a current, tested runbook for data recovery?
For MSPs evaluating Microsoft 365 consultant agencies to support backup deployments, the answers to these questions should shape the scope of any engagement.
Data sovereignty and Australian data protection law: what IT teams need to know
Generic compliance notes about “data residency” miss the specifics that matter for Australian organisations. Here is what the Privacy Act 1988 (Cth) and sector-specific frameworks actually require, and how Microsoft 365 Backup intersects with them.
Privacy Act 1988 and the Australian Privacy Principles (APPs): APP 8 governs cross-border disclosure of personal information. If backup data is stored or processed outside Australia, the organisation remains accountable for any breach of the APPs by the overseas recipient. Microsoft 365 Backup stores data in the same geo as your tenant. For Australian tenants, that is the Australia geo (datacentres in New South Wales and Victoria). This satisfies the residency requirement for most APP 8 scenarios, provided you have confirmed the tenant geo and documented it.
My Health Records Act 2012: Healthcare organisations handling My Health Record data must store and process that data within Australia. Microsoft’s Australia geo satisfies this requirement for Microsoft 365 workloads, but you must verify that any third-party backup solution you add also stores data in Australian datacentres. Not all ISVs offer Australian data residency; confirm before signing.
ASIC record-keeping rules (RG 223 and related instruments): Australian financial services licensees must retain certain records for seven years. Native Microsoft 365 Backup retains data for 365 days. A third-party solution with configurable long-term retention, or Microsoft Purview archive, is required to meet the seven-year obligation.
Notifiable Data Breaches (NDB) scheme: Under the NDB scheme, organisations must notify the OAIC and affected individuals of eligible data breaches. A ransomware event that encrypts or exfiltrates Microsoft 365 data is a likely eligible breach. Having a tested backup and recovery process reduces the severity of the breach and supports the remediation steps required in the notification.
Practical sovereignty checklist:
- Confirm tenant geo in Microsoft 365 admin centre and record the date of confirmation
- Verify any third-party backup vendor’s Australian datacentre availability before procurement
- Map retention requirements by data class (general business records, health records, financial records) and confirm your backup solution meets each
- Include backup and recovery procedures in your NDB response plan
- Document all of the above in your compliance evidence pack for audits
Integrating Microsoft 365 backups into your broader business continuity plan
Microsoft 365 Backup protects cloud workloads. Most Australian SMEs also run on-premises or hybrid infrastructure: file servers, line-of-business applications, local Active Directory, and network devices. A Microsoft 365 backup strategy that is not connected to a broader business continuity and disaster recovery plan leaves significant gaps.
Hybrid and on-premises considerations:
On-premises file servers and applications need a separate backup solution. Microsoft 365 Backup does not protect on-premises infrastructure. Azure Backup and Azure Site Recovery are the natural Microsoft-stack options for hybrid environments, covering on-premises servers, VMs, and SQL databases with replication to Azure.
Active Directory is a particular risk. If your on-premises AD is the identity source for Azure AD Connect, a corruption or ransomware event affecting AD can cascade into Microsoft 365. Back up AD separately using a dedicated AD backup tool, and include AD recovery in your DR runbook.
Integrating into a broader BC/DR plan:
- Define a single Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each critical system, not just Microsoft 365. Align your backup configurations to meet those targets.
- Map dependencies: which on-premises systems does Microsoft 365 depend on (AD, ADFS, Azure AD Connect), and which on-premises systems depend on Microsoft 365 data?
- Include Microsoft 365 restore scenarios in your annual DR exercise alongside on-premises recovery scenarios. A DR test that only covers on-premises infrastructure misses the workloads your staff use every day.
- Assign a single owner for the BC/DR plan who is responsible for keeping it current as your environment changes.
For MSPs: When you onboard a new client, the backup scope conversation should cover Microsoft 365, on-premises or hybrid infrastructure, and cloud-hosted line-of-business applications in a single assessment. Treating them as separate engagements creates gaps and increases the risk of a recovery failure during an actual incident.
Key takeaways
Microsoft 365 Backup is the right baseline for Australian organisations, but native coverage alone is insufficient for Teams chats, Power Platform, long-term regulatory retention, and eDiscovery-grade search.
| Point | Details |
|---|---|
| Start with native Microsoft 365 Backup | Exchange, OneDrive, and SharePoint are covered with 10-minute RPO; deploy this as your baseline before adding anything else. |
| Know the coverage gaps | Teams chats, Power Platform, and Planner are not covered natively; address these with a third-party solution or Purview retention. |
| Retention limits matter for compliance | Native backup retains data for 365 days; Australian financial services and healthcare obligations often require longer retention via a third-party or Purview archive. |
| Test restores on a schedule | Run quarterly restore drills, measure real-world RTOs, and document results for compliance evidence. |
| Stanfieldit manages the full lifecycle | Stanfieldit’s managed backup service covers deployment, policy design, delegated restores, testing, and reporting for Australian organisations that need a documented SLA without building the capability in-house. |
When native backup is not enough: a practitioner’s view
The conversation about Microsoft 365 backups tends to split into two camps: those who assume Microsoft handles everything, and those who over-engineer a solution with multiple overlapping tools. Both positions create problems.
The first camp discovers the gap during an incident, usually a ransomware event or an accidental bulk deletion, when the recycle bin has already been emptied and the only recovery path is a backup that was never configured. The second camp spends significant budget on redundant tooling and then fails to test any of it, so when recovery is needed, nobody is confident the runbook actually works.
The more defensible position sits in the middle. Microsoft 365 Backup is a genuinely capable platform for the workloads it covers. Its 10-minute RPO for Exchange is better than most third-party solutions offered five years ago. The pay-as-you-go model removes the per-seat cost friction that used to make backup conversations difficult with budget-conscious clients.
Where the native platform falls short is not in its backup capability but in its recovery workflow. Granular search across a large tenant, legal discovery exports, and delegated restores for helpdesk staff are all areas where third-party platforms built on the Backup Storage API add real operational value. For a 20-person professional services firm, native backup is probably sufficient. For a 200-person healthcare organisation with compliance obligations and a legal team that issues discovery requests, it is not.
The practical recommendation for Australian MSPs: deploy native Microsoft 365 Backup for every client as the baseline, then assess whether the client’s compliance obligations, internal capacity, and recovery complexity justify adding a third-party product or a managed service. That assessment should happen at onboarding, not after an incident.
Stanfieldit’s managed Microsoft 365 backup and recovery service
Stanfieldit delivers end-to-end managed backup for Australian businesses: policy design, deployment, delegated restore management, quarterly restore testing, and compliance reporting, all under a documented SLA. For professional services and healthcare clients who cannot afford a recovery failure or a compliance gap, this is a materially different proposition from self-managing native backup.
The service covers Microsoft 365 workload backup configuration, gap workload remediation (Teams chats, Power Platform), hybrid and on-premises backup integration, and regular restore drills with documented RTOs. Pricing is included in a monthly managed services agreement, giving you cost predictability instead of consumption-based surprises.
If you are an IT manager or MSP evaluating backup options for an Australian client, the right next step is a conversation with the Stanfieldit team. Start with a free IT assessment to map your current backup coverage, identify gaps, and get a clear recommendation on whether native backup, a third-party product, or a fully managed service is the right fit for your organisation.
Useful sources
Key Microsoft documentation and industry resources referenced in this article:
- Microsoft 365 Backup overview (Microsoft Learn): The primary technical reference for workload coverage, RPO/RTO guidance, append-only storage architecture, and retention mechanics. Start here for implementation specifics.
- Microsoft 365 Backup product page (Microsoft Australia): Product overview, pricing model, and feature summary. Use this for licensing and cost conversations with clients.
- Microsoft 365 Backup adoption guidance: Microsoft’s recommended deployment approach, best practices whitepaper, and business continuity framing. Useful for executive presentations and stakeholder briefings.
- Restore data in Microsoft 365 Backup (Microsoft Learn): Step-by-step restore procedures, express vs standard restore point guidance, and session history documentation. Reference this when building your restore runbook.
- Microsoft 365 Backup best practices whitepaper: Microsoft’s own guidance on when to use native backup, when to add an ISV, and how to frame the decision for organisational stakeholders.
- Find lost or missing files in OneDrive (Microsoft Support): Quick reference for end-user recovery steps via recycle bin and version history, useful for helpdesk staff handling tier-1 recovery requests before escalating to a full backup restore.
