Can Microsoft 365 Backup restore individual files?
Yes. Microsoft 365 Backup can restore individual files from a suitable recovery point, provided the file is within the configured backup scope and the relevant workload supports file-level recovery.
Individual-file recovery means selecting a specific backed-up file, rather than restoring an entire user account, site, mailbox or document library. Microsoft 365 Backup uses an available recovery point to return that item to an earlier state, subject to the workload, backup configuration and recovery options in use.
The practical recovery process normally involves identifying the affected file, choosing a recovery point from before the loss or unwanted change, and confirming the destination for the restored data. Depending on the workload and the recovery method available, the file may be returned to its original location or recovered in a way that allows it to be reviewed before it replaces existing content. This distinction matters where a file has been overwritten, encrypted or altered, rather than simply deleted.
What can be recovered depends on the backup scope. A file must have been included in the configured Microsoft 365 Backup protection for it to be available. Files created, moved or changed outside that scope will not appear in a recovery point. The selected recovery point must also pre-date the incident; a backup taken after accidental deletion or ransomware encryption may preserve the problem rather than the required earlier version.
- Deleted files: a previous recovery point can provide a copy of a file that is no longer present in its original location.
- Overwritten files: an earlier version may be recovered where the backup contains the required state.
- Encrypted or corrupted files: recovery can provide an unaffected earlier copy if one exists in the backup history.
- Multiple files: individual recovery is different from restoring a whole site, library or user’s data, although a wider restore may be more appropriate when many items are affected.
Restoring the file itself does not necessarily recreate every surrounding condition exactly as it was. File content, location, version information, sharing links, permissions, ownership, metadata and dependencies may be handled differently according to the Microsoft 365 workload and the restore operation. A recovered document may therefore need its access permissions or links checked before it is treated as fully restored. Where a file is used by an application, workflow or integrated business process, those dependencies should also be tested.
Selection of the recovery point is a key control. The most recent point is not always the correct one: it may contain a mistaken edit, deletion or malicious change. Administrators should compare the incident time with the available points and choose a version known to pre-date the problem. If the exact time of compromise is uncertain, reviewing more than one recovery point can help identify a clean version.
Access to individual-file recovery should be limited to authorised administrators or recovery operators. This reduces the risk of an unauthorised person retrieving sensitive business information or replacing legitimate content. The recovery should be recorded, including the affected file, selected recovery point, operator, destination and any permissions or links that required follow-up.
Microsoft 365 Backup is not a substitute for ordinary file-management controls. Version history, recycle bins, retention policies and user permissions may help with certain incidents, but they do not provide the same protection or recovery model as a separately managed backup. A backup plan should define which Microsoft 365 data is protected, how long recovery points are retained, who can perform a restore and how the restored file will be validated.
Before relying on file-level recovery, test representative files from each protected workload. Confirm that the required recovery points are visible, the restored content opens correctly, the destination is suitable, and access controls remain appropriate. Testing should include files with different owners, locations and sensitivity levels so that a successful demonstration does not conceal a gap in the actual backup configuration.

Individual-file recovery restores the backed-up content of the selected item, but it does not automatically recreate the business process that uses it. After recovery, check that formulas, document relationships, embedded content and application integrations still work as expected. This is particularly important for spreadsheets, templates and files used as inputs to operational systems.
Where the restored file is intended to replace a damaged copy, retain the existing item until the recovered version has been reviewed and approved. This provides a clear comparison point and helps avoid replacing usable content with an unsuitable recovery version.