The proposal document is in SharePoint. The confirmation email is in Exchange Online. And the sentence that actually closed the deal — "fine, let's leave it there and sign on Monday" — is in a Teams chat. Of those three things, if your backup is Microsoft's own or Veeam's — the two we read below, documentation in hand — it keeps two. The third one appears, in writing and by name, on the list of what does not get backed up.
This is nobody's fault and it isn't a faulty product. It's a published list that almost nobody opens at the point where it would help — when you decide what gets protected and with what. Everyone opens it on the day of the incident. Let's read it now.
Where a Teams message actually lives
Microsoft says it plainly in its retention documentation for Teams: "Teams uses an Azure-powered chat service as its primary storage for all messages (chats and channel messages)". The primary store for your conversations is a chat service running on Azure, not any of the boxes your backup knows how to open.
What does end up in a mailbox is a compliance copy. Also verbatim: "Data from Teams chats is stored in a hidden folder in the mailbox of each user included in the chat", and channel messages use an equivalent hidden folder inside the group mailbox. And now the sentence worth reading twice, because it decides everything else: those hidden folders "aren't designed to be directly accessible to users or administrators, but instead, store data that compliance administrators can search with eDiscovery tools".
A copy does exist, and it's designed for a compliance administrator to search with eDiscovery. That tool finds; putting the conversation back where it was in the app is a different job, with different hands and different deadlines. On the day someone asks you the question, the deadlines you get measured against are the second set.
What the built-in backup covers
Microsoft 365 Backup, the native pay-as-you-go product, protects three workloads. Its documentation table has three columns and there is no fourth: OneDrive, SharePoint and Exchange Online. The backup unit it declares is just as specific — "OneDrive account", "SharePoint site", "Exchange user account" — and Teams chat is none of those three units. The billing is published too: $0.15 per GB per month for everything protected, restores included.
And to be clear, we don't raise this as a complaint, because it makes sense. Files you share in a channel live in the team's SharePoint; files you share in a private chat end up in the uploader's OneDrive, in the Microsoft Teams Chat Files folder. Those are covered. Recordings follow the same logic: a channel meeting leaves the file in the team's SharePoint site, and a meeting born from a chat leaves it in the organiser's OneDrive — for one-to-one and group calls, in the OneDrive of whoever pressed record — and that's exactly how Microsoft documents where the retention policy has to go. Attachments are covered. The conversation is not. We already wrote a whole post about those recordings and whose account they hang from the day that person leaves.
We already wrote a separate post on how that product bills and why one checkbox protects more than you'd think. Today something simpler will do: the workload list is short, it's published, and you need to read all of it before calling anything covered.
The list your backup tool publishes
If instead of the native product you use a third-party tool, the question moves to its manual. We'll take the one we run into most in small and mid-sized companies, from the vendor we already work with on server backups: Veeam Backup for Microsoft 365, version 8.6. Its Considerations and Limitations page splits the limitations by workload — Exchange on one side, SharePoint and OneDrive together, and Teams — and in two of those sections, SharePoint and Teams, the list opens with the same sentence: "does not back up the following objects". The Teams one has ten entries. Among them:
- ✗Individual and group chats.
- ✗Audio and video calls.
- ✗Video recordings hosted in Microsoft Stream.
- ✗Contacts and the calendar (including meeting information and meeting chats).
- ✗Code snippets and audio files inside posts, and banner notifications.
- ✗Data from apps added as channel tabs, unless that data resides in the team's SharePoint document library.
- ✗The TeamsMessagesData folder of the group mailbox — precisely the hidden folder where Microsoft keeps the compliance copy of channel messages.
For SharePoint the same page has another list, seven entries long, and one of them deserves a calendar in front of you: "Archived SharePoint sites". Veeam doesn't define what it means by archived, but everything points to the Microsoft 365 Archive cold tier, whose own documentation states that content in that tier "is no longer directly accessible to anyone". And archiving triggered from a Purview retention policy is on its way — we went through it when it was announced — so that line in the manual is about to go from footnote to real situation in a lot of tenants.
We'll take a vendor that enumerates what it doesn't do over one that just says "we protect Microsoft 365" any day: that list, published in full and item by item, is one of the things we look at when we compare products. What goes wrong is when it gets read — almost always with the incident already on top of you.
Retention is not backup, and here the distinction is literal
The usual answer to all this is "relax, we have a Teams retention policy". That policy does something useful, and it does exactly what it says: it preserves so that somebody can search later. Microsoft warns about it in bold on its own page: "Messages visible in the Teams app are not an accurate reflection of whether they're retained or permanently deleted for compliance requirements". And when a deleted message is still retained, here's what happens: it stops being visible in the app and "will continue to be discoverable with eDiscovery". For the user looking for it, it's gone. We already devoted a post to that distinction with SharePoint's Purview policies.
And there are two more pieces of small print that almost never get quoted. First: Teams retention doesn't keep everything. Code snippets, voice memos recorded from the mobile client, thumbnails, announcement images and emoji reactions "aren't retained when you use retention policies for Teams messages". Second: the timings. When a user deletes a message, that message doesn't enter the SubstrateHolds folder for 21 days; it stays there for at least one day; and the timer job that processes it runs typically every 1-7 days. Microsoft does the arithmetic in its own documentation with an uncomfortable example: a policy set to delete after one day can take 16 days to actually delete.
These are the reasonable timings of a compliance system, built so nothing gets lost by accident. The problem shows up when somebody puts them into a continuity plan as if they were restore times: 21 + 1 + 7 is not an RTO you can sign off in front of a board.
The day someone leaves
Here the small print carries a condition people skip over. Microsoft: if a user with a mailbox in Exchange Online leaves the organisation and their account is deleted, "their chat messages that are subject to retention are stored in an inactive mailbox". The condition is subject to retention. If no Teams retention policy applied to that person, there is no inactive mailbox rescuing their conversations. The mechanism everyone assumes is there only exists if somebody switched it on first.
And with outsiders, worse. If an external joins with a guest account in your tenant, their messages are also stored in a shadow mailbox, and Microsoft clarifies that "retention policies aren't supported for shadow mailboxes", even though they can be reported as included in an organisation-wide policy. If the external joins from another Microsoft 365 tenant, their copies stay in their own tenant and your policies don't reach them. Your half of that conversation you do have, in your own people's mailboxes; theirs was never yours. We've written about the Microsoft 365 backup that never leaves Microsoft; this is the one that also never leaves somebody else's organisation.
What we do about it
We split the problem in two, because the two halves need different kinds of answer. Files, attachments and recordings do get backed up: that's a service, it goes into a managed Microsoft 365 backup with its own retention, and there we apply the usual rules — 3-2-1, immutable copies and tested restores, because a backup you have never restored is a hypothesis.
The conversation is another matter, and we're not going to sell a checkbox that fixes what no checkbox fixes. Our position, and we say it even when it isn't what a client wants to hear: if a conversation is a business record — a price, a scope, an authorisation, a change of deadline — it cannot live only in a chat channel. Teams is fine for talking; for keeping, the platform has already told you in writing how far it goes. That sentence gets moved out into the minutes, a ticket, a repository or an email. It costs two minutes at the end of the meeting and it removes an entire dependency from your continuity plan.
Six questions for your Microsoft 365 backup
- Which workloads does your backup cover today? Write them on one line. Next to it, write the ones the company actually uses. If the two lines don't match, you've already done half the work.
- Open your tool's limitations page and count the lines. A vendor that doesn't publish that page is a worse sign than one that publishes a long one.
- Is there a Teams retention policy? Retain, delete, or both? With what period? And let the minutes record exactly what is expected of it: searching later, not putting anything back.
- Where does each recording live? Channel meeting: the team's SharePoint. Meeting born from a chat: the organiser's OneDrive. If nothing is configured over that OneDrive, there is nothing.
- Run the drill and time it. Ask for "the conversation between X and Y on this date" and watch the clock. If the answer is "we'll pull it out with eDiscovery", you now know your real recovery time for that.
- Guests and external users: what happens to their copies. Your own users keep their half in their mailboxes; the copy that sits on the guest's side or in the other tenant is not yours to govern, and the documentation says so without ambiguity.
What we won't recommend
- ✗A ten-year retention "just in case". What you get from that is an obligation in every proceeding and a much larger surface the day somebody asks for access to all of it. Set periods by content type, not a round number to help you sleep.
- ✗Asking your backup provider to "do something" about chats without first checking which API it uses and what its manual says. The Teams Export APIs exist and products that use them exist; that's a project, with its cost, its permissions and its review — not a checkbox in a panel.
- ✗Confusing "it's in Teams" with "it's kept". It's the same confusion as between a corridor and a storeroom: everything goes through the corridor, which is exactly why nothing is kept there.
All of this gets settled by opening two documentation pages — the platform vendor's and the backup vendor's — and comparing what they say against what the company believes it has. One afternoon, with no migration and no change of tooling. The alternative is doing that reading on the day somebody asks about the conversation from 14 May.
Sources (all primary, consulted on 22 Sep 2026): message storage, hidden folders, SubstrateHolds, the 21 days, the 16-day example, what isn't retained, inactive mailboxes, shadow mailboxes and where the recordings policy goes — Microsoft Learn, "Learn about retention for Teams"; covered workloads, granularity and pricing — Microsoft Learn, "Overview of Microsoft 365 Backup"; lists of objects not backed up for Teams and SharePoint, version 8.6 — Veeam Backup for Microsoft 365, "Considerations and Limitations"; the archive tier — Microsoft Learn, "Overview of Microsoft 365 Archive"; the Microsoft Teams Chat Files folder in the uploader's OneDrive — Microsoft support, "File storage in Microsoft Teams".
Do you actually know what is and isn't in your Microsoft 365 backup?
At everyWAN we build and run Microsoft 365 backups with their own retention, immutable copies and tested restores. And before selling you anything, we put in writing what stays outside.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN