Teams and SharePoint restores are requested far more often for a single item than for a whole site. Someone has overwritten a spreadsheet, deleted a channel's files or lost a thread that contained a decision. The backup holds the data. Whether it can return exactly that item, to the right place, with its permissions intact, depends on how the backup was taken and how the two services store their content.
This post explains what item-level recovery means for Teams and SharePoint, where it gets complicated and what to test before the first real request arrives.
Teams is an interface over several other services. Files shared in a channel are stored in the SharePoint site that belongs to the team. Files shared in a private chat go to the sender's OneDrive. Channel messages are held in a mailbox associated with the team's group, and chat messages in the participants' mailboxes. Meeting recordings land in OneDrive or SharePoint depending on the meeting type.
A restore therefore touches whichever service holds the item in question. A backup that covers SharePoint but not the group mailbox can return a channel's files and not its conversation. The first check for any Microsoft 365 backup is that every service behind Teams is in scope.
| Item | Stored in | Typical restore options |
|---|---|---|
| Document in a library | SharePoint | Single file or version, to original or alternate location |
| Folder or library | SharePoint | Whole folder with structure and metadata |
| Channel file | SharePoint site of the team | Single file back to the channel's folder |
| Channel post | Group mailbox | Often export only, or restore as a new post |
| Chat file | Sender's OneDrive | Single file to the owner's OneDrive |
| Whole team or site | Several services | Rebuild of site, membership, channels and tabs |
Exact behaviour varies between backup products, so the table should be read as a starting point for questions, not a specification.
A file in SharePoint is more than its contents. It carries a version history, column metadata, sharing links and permissions that may differ from the library around it. An item-level restore has to decide what to do with each. Restoring over the current file may add a version or replace the history, depending on the product. Restoring to an alternate location usually keeps content and loses unique permissions.
These details matter most when a restore is done for an audit or a dispute, where who could see the document and when it changed are part of what is being asked. It is worth knowing in advance which attributes the backup preserves.
The hard part of an item-level request is often locating the item. Users rarely know the date something went missing. A backup that can be searched by file name, author or modified date across restore points turns a long browse into a quick lookup. Retention sets the outer limit: an item deleted before the oldest restore point is gone. Choosing a clean recovery point covers how to pick a point when the time of loss is uncertain.
Item-level restores read small amounts of data from many places in the repository. The backup software consults its index, fetches the objects that make up the item and writes them back through Microsoft's interfaces, which apply their own throttling. For a handful of files the repository is rarely the limit. For a large folder or a full site, read throughput and request latency on the repository begin to matter, as does the rate the service allows on the way back in. Finding the slowest step in a restore explains how to tell which stage is holding things up.
Some incidents call for a wider restore. A ransomware event that encrypts a synced library, a script that changes thousands of files or the deletion of an entire team needs a point-in-time rollback of a site or a rebuild of the team with its channels and membership. The same backup serves both cases, but the procedure, duration and approvals differ. File restores versus larger restores makes the same distinction for virtual machines, and the reasoning carries over.
Four test restores cover most of what will be asked in practice: a single document to its original location, a previous version of a document, a deleted channel's files and a file from a user who has left the organization. Each should be timed and the result checked for content, metadata and permissions. The outcome becomes a short runbook that the service desk can follow without calling the backup administrator.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. Backup products that protect Microsoft 365 and write to S3-compatible storage can use it as their repository, with the item-level restore features provided by the backup product itself. Immutability is provided by S3 Object Lock on each object where the backup product supports it.
ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB and is used as a target for Veeam and other backup software.
Item-level recovery works well when its limits are known ahead of time. A one-page summary for the organization, stating what can be restored, from how far back and how long it usually takes, prevents most difficult conversations. It also gives the backup team a clear standard to test against each quarter.