Handling an accidental mass delete of SharePoint files

Mass deletes in SharePoint are rarely malicious. The usual suspects are a user who dragged a folder in File Explorer while OneDrive was syncing, a laptop being reimaged with the sync client still signed in, a Power Automate flow with a bad condition, or a migration tool told to "clean up". The files are almost always recoverable. The damage comes from restoring badly — in the wrong order, from the wrong place, or while the thing that deleted them is still running.

Stop the cause first

Before restoring anything, make sure it cannot happen again in the next ten minutes.

• Sync client: find the device. Pause syncing or sign the account out of OneDrive on that PC. If the user deleted from Explorer, restoring in the browser while the client is still running will simply sync the delete again. This is the single most common way a recovery goes wrong.
• Script or flow: turn it off. Check Power Automate run history, and the Unified Audit Log for FileDeleted events by a service principal or a single account in a tight time window.
• Migration or third-party tool: stop the job and check whether it was running in a mode that mirrors deletions.

Identify the actor and the window from the audit log: Purview → Audit → search for FileDeleted, FileRecycled and FolderDeleted on the site, sorted by time. You want three numbers: who, first delete, last delete. Every restore choice below depends on them.

Pick the restore tool

There are three built-in tools and they are not interchangeable.

Recycle bin: precise, manual, 93 days

Every deleted file goes to the site's recycle bin (first stage, visible to users) and, if deleted from there, the second-stage bin (site collection admins). Both share a 93-day clock. You can filter by Deleted by and Date deleted, select everything, and restore.

Use it when the delete was bounded — one folder, one library, one user — and you want to restore exactly those items and nothing else. Its weaknesses: the web UI restores in batches and struggles with tens of thousands of items, and if a folder's parent was also deleted, restore the parent first or the children land in odd places. For large volumes, script it with PnP PowerShell:

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/Finance -Interactive
Get-PnPRecycleBinItem -FirstStage | Where-Object DeletedByEmail -eq "user@contoso.com" | Where-Object DeletedDate -gt (Get-Date "2026-09-01 14:00") | Restore-PnPRecycleBinItem -Force

Restore this library: broad, time-based, 30 days

Every document library has Restore this library (library settings menu), which rolls the whole library back to a point in the last 30 days, undoing deletes, moves, edits and renames together. It shows a histogram of activity so you can pick the moment just before the spike.

Use it when the damage is wide and the cause was a single event — the sync-client wipe, the runaway script. It restores everything the library saw after the chosen point, including legitimate work other people did since. If the delete was yesterday and the library is busy, tell users that edits since then will be reverted and ask them to save copies first. It is usually still the right call: undoing a day of work for ten people is cheaper than reconstructing 40,000 files by hand.

Note that it works per library, not per site. A site with six libraries hit by one script needs six restores.

Version history: for overwrites, not deletes

If the "delete" was actually a mass overwrite — a script that replaced file contents, or ransomware encrypting in place — the recycle bin has nothing, and version history has everything. Restore previous versions per file, or use Restore this library which also reverses edits.

Order of operations for a large recovery

1. Stop the cause and confirm it is stopped.
2. Take a note of the delete window and actor.
3. Tell users of the affected site to stop working in it for the next hour. A short Teams message beats a surprise.
4. If a single event caused it and it is inside 30 days: Restore this library to the minute before the first delete.
5. Otherwise: recycle bin, filtered by actor and time, restored via PowerShell in batches.
6. Verify counts. Compare item counts in the library before and after against the audit log's delete count. Spot-check permissions on a few restored files — unique permissions come back with the file, but it is worth confirming.
7. Only then re-enable the sync client or flow, and watch the audit log for another burst.

When it is a sync-client wipe specifically

Two wrinkles. First, the user's PC may still have the files locally if the deletion was in the cloud (someone else removed them and the client mirrored it). Copy them out before signing back in. Second, if Known Folder Move was in play and the user's Desktop or Documents got emptied, that is a OneDrive recovery on the user's own OneDrive, not the SharePoint site — Restore your OneDrive in the user's settings covers it.

If the pattern is recurring, the OneDrive sync admin settings let you block deletion of large numbers of files at once from the client with a warning, and the sync admin best practices cover the policy.

Past 93 days, or emptied from the recycle bin

The built-in path is exhausted. What remains:

• Retention policies. If a Purview retention policy covered the site, deleted items were copied to the Preservation Hold library and are recoverable from there for the retention period. Site collection admins can browse it at the site URL plus /PreservationHoldLibrary.
• Microsoft 365 Backup or a third-party backup, which restores the site or library to a snapshot.
• Microsoft support cannot restore individual files past the recycle bin. For a whole site that has left the tenant recycle bin, there is a short best-effort window — worth a ticket for a site, not for files.

What to change afterwards

• Turn on the Ransomware / mass deletion alert in Defender for Cloud Apps or an alert policy on a high volume of FileDeleted events. The right time to find out is minute ten, not day three.
• Put a retention policy on sites whose content matters beyond 93 days.
• Consider restricting sync for libraries where sync-client deletes are a recurring problem, or requiring users to check out before editing in high-value libraries.
• Write down which libraries hold the content that would end the company if lost, and decide honestly whether a 30-day rollback and a 93-day bin are enough for them. For most, no.