Introduction
With the introduction of SharePoint 2007, Microsoft saw fit to give us the recycle bin for catching and holding onto tossed away information before it was lost forever. Not only did the recycle bin provide us with the opportunity to recover items for a defined period of time, but this recycle bin actually had two parts. The first stage held items tossed away by users, from which they could retrieve said items if they discovered they still needed them. The second stage provided a catch-all bucket for items that were subsequently dumped by users from the first stage, out of which a Site Collection Administrator could then retrieve these items, provided their expiration time had not passed.
Best Microsoft MCTS Certification, Microsoft MCITP Training
at certkingdom.com
While SharePoint 2010 continues the tradition of this two-stage recycle bin, it seems that there is still some confusion as to just how the recycle bin functions. This article will delve into the mystery that seems to be this little wonder of restoration and hopefully provide the clarity to its configuration and usage.
How SharePoint’s Recycle Bin Works
Let’s begin with the basic operation of SharePoint’s recycle bin. To start with, the recycle bin is both user-specific and site-specific. This means that from the user’s perspective they will only see items in the trash that they have deleted from the specific site they are currently visiting.
And just what goes into the recycle bin? List and library items, as well as lists and libraries themselves all get caught in the recycle bin when a user chooses to delete said items from SharePoint. If a list or library is deleted, all of the items contained in that list or library are deleted as well. However, if a user decides to delete their entire site, don’t expect to go into the recycle bin and find it. It won’t be there. Service Pack 1 for SharePoint 2010 adds a Site recycle bin to capture deleted sites, but we’ll review that later. For now, simply bear in mind that only items, lists and libraries can be found in the user’s trash. Therefore, users are able to retrieve an item or an entire library, without the aid of an administrator, if they discover that they really did need that material.
Best Microsoft MCTS Certification, Microsoft MCITP Training
at certkingdom.com
Deleted items can only be restored to their original location. This means that if you have deleted items from a library and then the library itself is subsequently deleted, you must first restore the library before you can restore a specific item from that library. Simply creating a new library with the same name will not work. Items are all identified and referenced by their Globally Unique Identifiers (GUIDs), so, creating a new library would generate a new GUID.
Since the recycle bin is user/site-specific, what happens if someone deletes an item that another user needs? This is where the Site Collection recycle bin comes in. The Site Collection recycle bin, viewable by Site Collection Administrators, provides a comprehensive view of everything in the trash throughout the entire Site Collection. Think of the Site Collection recycle bin as the dumpster out back where all the trash for the entire building goes. Viewing the Site Collection recycle bin, a Site Collection Administrator will see all the deleted items from all of the sites within the collection and can then restore any item that a user has deleted.
It is from the Site Collection recycle bin that Site Collection administrators have access to the second stage of the recycle bin. This is where items go that have been deleted from the user recycle bin before they are purged. Item purging is based upon the recycle bin settings that can be found in Central Administration and are configured for the web application. It is also here, in the second stage, where a Site Collection administrator will find sites that may have been deleted by users. This is, of course, if you have installed SP1 for SharePoint 2010.
So just what are these settings and how do they work? In Central Administration, under the Application Management heading, Manage Web Applications, select the web application you want to adjust the recycle bin settings for and then select General Settings from the ribbon. Scroll down until you find the Recycle Bin settings section as shown in Figure 1.
Figure 1 – Recycle Bin Settings Section
First of all, we have the ability to turn off the recycle bin completely. While there are some organizations where this is the chosen method of operations, most of us will want to avail ourselves of this handy option and leave it on. The default setting is for the recycle bin to store items for 30 days. Items held within the recycle bin will count towards any Site Collection quota settings you might have configured, so you will want to take this into consideration when planning your SharePoint environment. Switching this to the Never option will simply allow items in the recycle bin to accumulate until a user manually deletes items from the trash (and we know how often that will happen) and could therefore use up all of the quota space for a Site Collection eventually. Setting the purge duration is a good idea. Furthermore, I would suggest giving some serious thought to increasing the time that items are kept within the recycle bin itself. From a disaster recovery perspective, when comparing the cost of restoring data from backups vs. the cost of additional disk space for longer recycle storage, my point should become increasingly clear.
The second stage of the recycle bin seems to be where most of the confusion abounds. Let’s start with the storage setting. By default, items in the second stage will take up no more than 50 percent of the quota assigned to the Site Collection. If you have set a Site Collection quota of 100mb, items in the second stage can take up to an additional 50mb of disk space. Once this limit is reached and as newer items are dumped from the first stage and caught by the second stage, older items that are lying around in the second stage will be purged. There is no catch-all for items that are removed from the second stage. This also means that for collections that do not have a quota assigned, the recycle bin can simply grow and possibly fill up your entire database disk space.
The second stage can also be turned off. Before doing this, think very hard about how often it is needed to recover items that users have tossed from the trash to make room for something else because they were running out of disk space. By planning storage needs properly and taking into account the extra space for your second stage bin, it can be a very handy part of a recovery plan.
Now, let’s revisit the 30-day delete items setting. This 30 days, (or whatever preferred range it is set to) applies to both the first and second stages of the recycle bin. This is a one-setting, cover- all situation that covers 30 days total, not 30 days each. When a user deletes an item from a list or library, the 30-day timer starts. If at 28 days into the count the item is then deleted from the first stage, it rolls over to the second stage where it will sit for two more days before being purged for good. If the item would cause the second stage bin to hit its quota maximum, then an older item in the second stage would be deleted to make room for the new arrival.
Information Summary and Consideration Points
Plan a strategy well when implementing SharePoint’s recycle bin. Remember to account for the added storage needs when planning databases and consider hold times when planning a recovery model. A well-implemented recycle bin is an important element in a Disaster Recovery plan and can save both time and money over the SharePoint farm’s lifespan.
Best Microsoft MCTS Certification, Microsoft MCITP Training
at certkingdom.com
No comments:
Post a Comment