Microsoft Teams backup: where your Teams data actually lives

If you are shopping for a Microsoft Teams backup, the first thing worth knowing is that there is no "Teams database" to back up. Teams is a front end. The messages, files, recordings and team structure you see in the app are stored across Exchange Online, SharePoint Online and OneDrive for Business — each with its own retention clock and its own restore behaviour. Natively you get roughly 30 days to bring back a deleted team or channel, and a 93-day recycle bin for files. There is no point-in-time restore, and nothing in that toolkit survives an attacker who waits a month before acting. Here is where each piece actually lives, and what that means the day you need it back.

Where your Teams data actually lives

This is the single most useful thing to understand about Teams, and it is why "just back up Teams" is not a request any admin console can satisfy:

What you see in Teams	Where Microsoft actually stores it
Channel messages	A hidden folder in the mailbox of the Microsoft 365 Group behind the team
1:1 and group chat messages	A hidden folder in each participant's own Exchange Online mailbox
Files posted in a channel	The team's SharePoint Online site, in a folder per channel
Files shared in a 1:1 or group chat	The sender's OneDrive for Business, under a Microsoft Teams chat files folder
Meeting recordings	OneDrive for the organiser (regular meetings) or the team's SharePoint site (channel meetings)
Team and channel structure, membership, permissions	Microsoft 365 Group and Teams metadata, backed by Entra ID
Tabs, apps, connectors, planner boards	The underlying service for each — largely not in Teams at all

Two consequences fall straight out of that table. First, a file "in Teams" is really a SharePoint or OneDrive item, and it obeys SharePoint or OneDrive rules, not Teams rules. Second, chat history is mailbox data — which means when you offboard a user and delete their mailbox, you are deleting one side of every conversation they were part of.

What a native Microsoft Teams backup actually covers

Microsoft gives you several genuinely useful recovery mechanisms. They are just narrower than most people assume:

Deleted team — about 30 days. Deleting a team soft-deletes the Microsoft 365 Group behind it. An admin can restore that group, and with it the team, within the default 30-day window. After that it is purged.

Deleted channel — about 30 days. A deleted standard channel can be restored from the Teams client or admin centre inside a similar window. Note that the channel's files are a separate matter: they live in the SharePoint site and follow SharePoint's own clock.

Deleted files — 93 days. Items removed from a SharePoint site or OneDrive go to a first-stage recycle bin, then a second-stage one, with the total window running 93 days from the original deletion. This is the mechanism people are actually relying on when they say "we can get files back."

Deleted chat messages — effectively nothing self-service. There is no user- or admin-facing "restore this deleted message" button for chat. Once a message is deleted, recovering it depends on whether a retention policy or hold happened to be preserving it, and retrieval then goes through eDiscovery rather than a restore.

Notice what is missing from that list: any way to say "put this team back the way it was last Tuesday." Every native mechanism is a bin you fish a specific item out of, within a window, one item at a time.

Retention policies and eDiscovery are not backup

This is the most common and most expensive misunderstanding, so it is worth being precise about the difference.

A retention policy is a preservation control. It stops data being permanently removed before a date you specify, and it can also force deletion after one. It exists to satisfy legal and compliance obligations, and it does that well. What it does not give you is a restore. The data is held in place, invisible to users, retrievable by a compliance administrator through an eDiscovery search and export — as a file you then have to reimport by hand.

That distinction is not academic. In an incident, the questions are "how quickly can we be operational" and "can we get back to a known-good state." An eDiscovery export answers neither. It answers "can we produce this data if compelled," which is a different job. We walk through the same divide in more depth in our post on the SaaS shared responsibility model: Microsoft guarantees the platform and its own infrastructure, while the recoverability of your data at your required granularity stays with you.

The gaps that actually bite

The attacker who waits. Ransomware operators and disgruntled insiders both understand retention windows. Activity that stays quiet for longer than 30 days empties the team and channel restore windows before anyone opens a ticket. Our Microsoft 365 ransomware recovery walkthrough covers what that timeline looks like from the inside.

Overwrites, not deletions. Recycle bins catch deletions. They do not catch a synced folder that mass-overwrites good files with encrypted ones, or a bulk metadata change, or an automation that rewrites content in place. The item was never deleted, so nothing lands in a bin.

Offboarding. Delete a departed employee's mailbox and their side of every 1:1 chat goes with it. Files they shared from their OneDrive can become inaccessible when that OneDrive is removed, even though the file appears in a chat other people can still open.

Granularity. Real restore requests are narrow: one channel, one page of history, one folder as it stood before a specific change. Native tooling is built around the whole object — restore the team, restore the group, restore the item from a bin — and gets awkward fast when the request is anything else.

Proving it. Frameworks like NIS2 expect recovery capability you can demonstrate and test, with evidence. "We have retention policies configured" is a preservation answer given to a recovery question, and auditors increasingly know the difference.

What to look for in a Teams backup

Because Teams data is spread across three services, the only thing that produces a coherent restore is a layer that understands how those pieces relate. Concretely, look for:

• Coverage of all of it — channel messages, chats, the SharePoint document libraries behind channels, the OneDrive folders behind chat files, plus team and channel structure, membership and permissions
• Point-in-time restore, so "as it was before the change" is an actual option rather than a reconstruction exercise
• Granular restore down to a single channel, conversation or folder, without touching the rest of the tenant
• Structure and permissions preserved, so a restored team comes back usable rather than as a pile of files needing rewiring
• Anomaly detection that flags mass-delete and mass-change events while they are happening, instead of leaving you to notice on day 31
• Restore logs you can hand to an auditor, for NIS2, ISO 27001 and GDPR conversations
• Restores you have actually tested — an untested backup is a belief, not a control

We are independent: we help you choose the solution that fits your tenant and your obligations, and we get it deployed and running with guided onboarding. You own and run it afterwards — no black box, no dependency on us to get your own data back. Our Microsoft 365 backup and recovery page breaks down what gets protected workload by workload, Teams included.

If you are not certain whether your current setup would survive a bulk-delete in Teams that nobody notices for six weeks, that is exactly the question an assessment answers — a short, practical review of where your Teams data sits today, which windows you are actually relying on, and what a real restore would take.