Choose the Right SharePoint Recovery Route

When a user says a SharePoint document has disappeared, first establish what disappeared. The file may have moved, the user may have lost access, or the current version may contain the wrong material. Starting with a library-wide restore can turn a small incident into a wider interruption.

Ask for the original site and path, the approximate last good time, and a description of the missing content. Keep a record of the current state before making recovery changes.

Classify the problem

Use the smallest scope that matches the evidence:

This is a triage guide, not a guarantee that every route will have the required data. Available history and previous deletion actions matter.

Check from the web interface as well as the user’s local sync folder. Record which view you inspected. Otherwise, a local display problem can be mistaken for deletion from the service.

Recover one version when one file is wrong

Microsoft’s version history overview explains how previous versions can be inspected and restored. Review the candidate first: the nearest timestamp is not always the last healthy content.

Compare a meaningful detail with the owner. For a quotation, that might be the agreed total and customer name. For a procedure, it might be the missing section. “It looks like the old file” is a weak acceptance test.

The restore procedure makes the selected version current by creating a copy; it does not remove the historical version being restored. Versioning must have been available for the required history to exist.

After restoring, ask the user to open the current document and repeat the content check. Record which version was selected and why. That gives the next support person a defensible recovery record.

Count the recycle-bin window correctly

SharePoint in Microsoft 365 normally retains deleted items for 93 days from their original deletion. Moving an item from the first recycle bin to the site collection recycle bin does not start another 93-day period. Microsoft’s recycle-bin guidance also describes conditions under which items can disappear earlier, including manual removal from the second stage.

If the first bin is empty, have someone with the required permissions inspect the second stage. Record the original deletion date and item path before restoring.

Do not ask the user to recreate the same folder structure while recovery is being investigated unless the support plan calls for it. Additional changes can make it harder to establish what should occupy the original location.

Once restored, confirm the contents and intended access. Recovery should not be signed off solely because the filename has returned.

Treat library restore as a coordinated change

Restore this library can undo file and folder activity over the previous 30 days. It relies on version history and recycle-bin data; it is not an independent copy that can recover every permanently deleted item.

Review the activity feed with the owner and identify the earliest action to undo. Later actions in the selected range are included, so healthy work after the incident point must be considered.

Before running it, tell the affected team which library is involved and how they should handle ongoing edits. Record the selected time, the reason for that time, and the person authorising the wider recovery.

This route does not restore an entire library that has itself been deleted. That is a different recovery case. If the operation reports exceptions, inspect the generated restore log and reconcile each failed item with the expected list.

Close with evidence and a prevention decision

The recovery record should identify what was recovered, what remains missing and which user validated it. If the required content is outside the available native recovery routes, escalate promptly to the organisation’s backup or support process rather than repeatedly trying unrelated restores.

Then address the cause. A mistaken edit might need a working practice change. Broad accidental deletion might reveal excessive access. Malicious changes belong in the incident response process, including containment before recovered content is exposed to the same cause again.

References

• Microsoft — Version history overview. Accessed 17 October 2026.
• Microsoft — Restore a previous version in SharePoint. Accessed 17 October 2026.
• Microsoft — Restore items from the site collection recycle bin. Accessed 17 October 2026.
• Microsoft — Restore a shared library. Accessed 17 October 2026.