How Does the Recycle Bin Work in SharePoint 2010?
I was recently asked how the dual stage recycle bins worked in SharePoint 2010 by one of my students (thank you, Andrew!), and I realised that I didn’t know enough. It’s not just me either. This has to be one of the poorest-documented SharePoint features on the Internet.
This article charts my journey of discovery.
Introduction
The SharePoint Recycle Bin is a complex entity. It has two stages, both accessible from within the site collection.
The 1st stage, known as the “end user recycle bin”, is where lists, documents and list items delete by users are sent. Their storage limit is known to be included in whatever site collection quota.
The 2nd stage, (accessibly only by site collection administrators) known as the “deleted from end user recycle bin”, is where such documents are sent when the user deletes them from the recycle bin. Their storage limit is known to be a percentage on top of the site collection quota, and is specified as a single setting, that applies to a whole web application.
Objectives
This experiment aims to show through empirical means how the SharePoint 2010 1st and 2nd Stage Recycle Bins behave.
Hypothesis
It is commonly understood that when the 1st stage time-to-live is reached, the deleted items will migrate to the 2nd stage recycle bin, to be held their indefinitely, or until the percentage of space of the site collection quota has been reach.
It is documented on Microsoft TechNet that the Recycle Bin timer job runs daily to find deleted content and “moves it to the next stage or deletes it”:
The behaviour is further documented on p68 of the Microsoft Press book “SharePoint 2010 Administrator’s Companion” by Bill English:
The TechNet page “Plan to protect content by using recycle bins” is ambiguous in its wording, but can be read as contradicting the other two sources.
Firstly…
| When a user does this | The item is | The item can be restored by |
|---|---|---|
|
Deletes an item |
Held in the first-stage Recycle Bin until the item is deleted from the Recycle Bin or the item has been in the Recycle Bin longer than the time limit configured for an item to be held in the Recycle Bin. |
Users or site collection administrators |
|
Deletes an item from the Recycle Bin |
Held in the second-stage Recycle Bin |
Site collection administrators |
And secondly…
The time limit for the Recycle Bins applies to the total time after the item was first deleted — not the time spent in either Recycle Bin stage.
Method
This experiment was carried out with SharePoint 2010 SP1 and the July 2011 Cumulative Update.
Two documents were placed into a Shared Documents library.
These documents were then deleted within 60 seconds of each other. Next, within a further 60 seconds, the second document was deleted from the 1st stage recycle bin. Its presence in the 2nd stage bin was then confirmed.
The site collection had a quota of 100MB.
The web application recycle bin time to live was adjusted down to 1 day, and the system clock was advanced by 24 hours.
The “Recycle Bin” timer job in Central Administration was then forced to run.
Observations
After the Recycle Bin timer job completed, both the 1st and 2nd stage recycle bins were found to be empty.
Nothing.
Not a sausage.
Conclusions
- There is a timer job that empties recycle bins. If this does not run, nothing ever gets deleted.
- The timer job deletes from 1st and 2nd stage bins anything that is older than the retention age FROM THE DATE FIRST DELETED, up to the maximum size allowed through quotas.
- The only way a deleted item can get into the 2nd stage bin is if a user deletes it from the 1st stage recycle bin.
- You really need a file-level backup and restore solution.
- Even really clever people don’t understand how this works.
Also of note:
The timer job itself may or may not be set to run every day. You can set it to run at intervals of minutes, hourly, daily, weekly, or monthly, out of which Weekly on Sunday is the SharePoint 2010 default.
So under SharePoint’s default settings (30 day Bin limit w/ Weekly timer job), an item could possibly persist in the Recycle Bin for up to 35 days if it happened to be deleted right after the timer job ran, 35 days prior.
In other words, if a timer job ran on days 0, 7, 14, 21 and 28, our item (deleted on day 1) would not yet be deleted because it’s younger than 30 days. But then the next job would not run until day 35, upon which our item would finally be deleted.
This issue is amplified with a 30 day Bin limit and a Monthly timer job, which could allow items to persist for up to 59 days before deletion!
Both scenarios can have hidden consequences for large organizations where large numbers of users could fill those recycle bins! So this timer job is really the unspoken third parameter of setting up your Recycle Bin.
nice post its helpful information
Thanks for reading!
joel
Nice Post.
Helpful for my requirement.
Thanks..!!!