Guide · Microsoft 365 & SharePoint
Someone just deleted the shared folder: how to get mass-deleted files back
Here's the short version: stop editing that site, then work the two recycle bins and version history before the retention clock runs down. Mass-deleted files in Microsoft 365 are usually recoverable if you move fast. This guide covers exactly where the files went, how to bring them back, and when to stop clicking and get help.
Last updated 4 July 2026 · by Alien IT Solutions
Rule one: stop editing and don't panic-delete more
A shared folder emptied out, a SharePoint library gone, a whole team suddenly staring at "no files"? The single biggest rule is the same as any data scare: stop changing things. Do not re-create the folder, do not start dragging files around, do not let everyone keep saving over what is left while you work out what happened.
The good news is that Microsoft 365 rarely destroys files the instant they are deleted. It moves them somewhere you can reach. The bad news is a countdown started the moment it happened, and fresh edits and syncs can complicate the recovery. Calm, quick and careful beats fast and frantic every time.
Where the files actually went
Deleting from SharePoint or OneDrive does not wipe the files off the face of the earth. It moves them into a recycle bin, and there are two of them stacked behind each other. Knowing this turns blind panic into a short checklist.
First stop is the site recycle bin, or the OneDrive recycle bin if the files lived in someone's personal storage. Anything deleted in the normal way lands here first, and anyone with the right access can select the items and restore them straight back to where they were. For most accidental deletions, this is the whole story, and you are done in a couple of minutes.
When items are cleared from that first bin, or once they have sat there long enough, they drop into the second-stage recycle bin. This one is reachable by a site collection administrator rather than everyday users, and it is the reason "the recycle bin is empty" is not the end of the road. Only after the second-stage bin is emptied or times out are the files gone from the normal tools.
The first-hour checklist
Four things, in order. They cost nothing and they protect every option you have left.
Stop editing that site
Ask everyone to pause on the affected library or site. New saves, new versions and background syncs can pile up while you work, and a busy site is harder to untangle than a quiet one.
Check the site recycle bin first
Open the recycle bin for that SharePoint site or OneDrive, look for the deleted items, select them and restore. Most accidental deletions end right here, so try the simple option before anything clever.
Then the second-stage bin
If the first bin is empty, a site collection administrator checks the second-stage recycle bin. Files cleared from the first bin, or emptied by someone in a hurry, often still sit here waiting to be restored.
Note who, what and when
What was deleted, roughly when, and by whom if you can tell. Written down, in order. It shapes how the recovery runs and helps work out whether it was one folder or a whole library.
Triage: which kind of loss have you got?
Three situations, three very different playbooks. Getting this call right is most of the battle.
! Files deleted, still within the retention window
The good-news case. The files went to a recycle bin and the clock has not run out. Check the site bin, then the second-stage bin, select the items and restore them to their original spot. Do this before you rebuild anything by hand, because a clean restore beats re-typing folder structures from memory.
! A file was overwritten or emptied, not deleted
The file still exists, but the good content is gone, saved over or wiped out. This is a version history job, not a recycle bin one. Open the file's version history, find the last good copy, and restore it. Nothing to fish out of a bin, just an earlier version of a file that never left.
! Both bins empty and version history exhausted
Now you are past the self-serve tools. Depending on the setup, a site can sometimes be rolled back to an earlier point, and files under retention or legal hold may survive in the background. This is specialist territory, so stop clicking and get advice before you make it worse.
The retention clock is the real enemy
Straight answer: the reason speed matters is the retention clock. Deleted items do not sit in the recycle bins forever. By default they are kept for a set number of days across both stages, then purged, and the countdown started the second the files were deleted, not the second you noticed.
Out of the box, that window is ninety-three days across both recycle bins combined, though an administrator can change it. That sounds generous until you remember the delay before anyone realises files are missing, the time spent working out who deleted them, and the weekend nobody is watching the tenant. Treat every hour as spent, not free. The sooner you restore, the more you get back.
There is a second timing trap worth knowing. If someone had the folder synced to their desktop, deleting it there can push the deletion up to the cloud and out to everyone else, and a sync client mid-way through that job can keep re-applying the change. Pausing sync on the affected site while you recover stops the deletion chasing you around.
Version history: the overlooked lifesaver
Here's the tool people forget. SharePoint and OneDrive keep previous versions of files by default, which means overwrites and content-wipes are often the easiest thing of all to fix. Someone saved a blank document over the real one, or pasted rubbish across a spreadsheet? The good copy is still in the file's history, waiting.
To use it, open the file, find version history, and you get a list of earlier saves with dates. Preview them, pick the last good one, and restore it. The file never left the library, so there is nothing to recover from a bin. This is completely separate from the recycle bin route, and it is usually faster, so it is worth checking first whenever the problem is "the file is there but the content is wrong".
One caveat worth setting straight. Version history covers changes to files that still exist. If the file itself was deleted, that is a recycle bin job, and if versioning was switched off on that library, there may be no earlier copies to fall back on. Knowing which of the two problems you have saves a lot of clicking in the wrong place.
Self-serve or call someone in?
Here's the honest split. Restoring it yourself is fine when three things are true: the deletion is recent and inside the retention window, the files show up in one of the recycle bins or in version history, and you have the access to restore them. A folder someone dragged to the wrong place, a document saved over this morning. Have a go, done calmly it is a reasonable bet.
Hand it over when any of these are true: both recycle bins come up empty, the deletion happened long enough ago that the clock may have run out, or the data is business-critical and you cannot afford a wrong move. Years of shared records. The finance library. A site the whole company runs on.
The rule we give everyone: don't experiment on data you can't afford to lose. Your first-ever tenant-wide restore should not be on the only copy of something that matters, because a rushed restore to the wrong location, or a bin emptied by mistake mid-recovery, removes options you cannot get back. With irreplaceable shared data, the cheapest path is the one that works the first time.
What a proper 365 recovery looks like
If you do call someone in, here's how to judge them. A real recovery is methodical, not frantic. It starts by pausing changes on the affected site so the picture stops moving, then works the recycle bins and the second-stage bin in order, and checks version history for anything overwritten rather than deleted. Only when the self-serve tools are exhausted does it move on to the heavier options.
The piece nobody expects is what happens after the files come back. A recovery is not finished when the folder reappears. It is finished when there is a real backup of that Microsoft 365 data sitting outside the recycle bins, so the next accidental delete is a quiet restore instead of a countdown. The built-in bins are a safety net with a time limit. Handing the data back with nothing better in place is how the same phone call happens again next quarter.
The real lesson: the recycle bin is not a backup
Every one of these jobs starts the same way: a shared library everyone relied on, one bad click, and a clock nobody knew was ticking. A proper Microsoft 365 backup turns this whole page into a non-event. Someone empties the folder? Restore it from a copy that lives outside the bins, with no ninety-three-day deadline hanging over you. The recycle bins are a helpful safety net, but they expire; a real backup that actually restores is boring, and boring is exactly what you want your shared data to be. If today's scare ends well, spend the relief on setting one up, plus a quick look at who can delete what, before the next bad click picks the library you can't rebuild.
Questions people ask
Someone deleted our shared folder in Microsoft 365. Can we get it back?
Usually, yes, if you act quickly. Files deleted from SharePoint or OneDrive go to a recycle bin rather than vanishing, and there is a second-stage bin behind it. Check the site recycle bin first, then the second-stage bin, then version history. The main enemy is the clock, because deleted items are purged after a set number of days.
Where do deleted SharePoint and OneDrive files actually go?
They go through two stages. First they land in the recycle bin for that site or OneDrive, where anyone with access can restore them. When items are cleared from there, or after a set number of days, they drop into the second-stage recycle bin, which a site collection administrator can reach. Only after that second bin empties are they gone from the normal tools.
How long do I have before deleted files are gone for good?
By default, items sit in the recycle bins for ninety-three days total across both stages before they are purged, though an administrator can change that. Treat it as a countdown that started the moment the files were deleted. The sooner you restore, the more you get back, so do not sit on it while you decide who to blame.
A shared file was overwritten, not deleted. Can version history help?
Yes. SharePoint and OneDrive keep previous versions of files by default, so if someone saved over a document or wiped its contents, you can open version history and restore an earlier copy. This is separate from the recycle bin and often the fastest fix when the file still exists but the good content is gone.
The recycle bins are empty and version history is gone. Any other options?
Possibly, but you are now into specialist territory. Microsoft can sometimes restore a whole site to an earlier point in time within a limited window, and files placed under retention or legal hold may survive in the background even after the bins are emptied. These are not self-serve buttons, so this is the point to get help rather than keep clicking.
How do we make sure one bad click can't do this again?
A real backup for Microsoft 365, plus a little friction on who can delete what. The built-in recycle bins are a safety net with a time limit, not a backup. A dedicated 365 backup keeps its own copies you can restore long after the bins have emptied, and tightening permissions means fewer people can empty a shared library by accident.
Shared files gone right now?
Stop editing that site, then tell us what happened through the contact form. We'll tell you straight whether it's a recycle bin restore, a version history fix, or one to stop touching before the clock runs down.