SharePoint Backup Issues: Too Much Content?
As if you weren’t aware, your SharePoint environment could very well be a gigantic jumble of content. More than half of SharePoint deployments now measure well over 1 TB of content. Every year, this content grows around 65 percent. This is a lot of content – but what does it mean for you?
One significant problem this massive amount of content causes is the time it takes to back up and restore your SharePoint environment. With that much content, it is simply too much for out-of-the-box SharePoint tools to handle.
When considering a SharePoint backup of your content, STSADM backup and SharePoint Central Admin backup are two tools that are natively available within SharePoint. They “allow administrators to backup content databases and site collections via either command line and scripting or an administrator-issued command in Central Admin.” Great, right? They’re available right within SharePoint, and they are therefore a free solution for you.
However, there’s a significant catch - both of these solutions are not recommended for use on:
- Content databases larger than 100 GB
- Site collections that are larger than 15GB that you want to back up by using the STSADM command-line tool
With restrictions like that, you may start to look for a third-party backup tool. Unfortunately, more often than not, expensive third-party tools like Symantec encounter the same issues backing up large databases and site collections.
Why do these issues occur? For starters, databases tend to be much greater than 100GB as a result of Binary Large Objects (BLOBs). SharePoint natively stores BLOBs within SQL Server relational database, and they take up 95 percent of the space in your content database. That’s a lot of space to allot to non-relational data.
Recovery is another aspect of SharePoint where SharePoint’s built-in mechanism falls short of the mark if your databases are large.
Hardware will fail, and users will accidentally delete items that they need. These are two realities that SharePoint users and administrators will have to deal with. SharePoint has a built-in mechanism for item-level recovery through the use of the recycling bin feature. However, deleted items are only available within the recycling bin for an allotted period of time, the default being 30 days.
Once this period expires, end users cannot retrieve deleted items on their own, but must look to site collection administrators. Site collection admins will then have to retrieve an entire content database in order to recover one deleted file.
Important considerations to keep in mind when configuring your recycling bin settings include:
- Items in tier 1 recycle bin still count against a user’s quota
- Content BLOBs in the recycle bin are still stored in the content database of StoragePoint is not implemented
- The second tier of the item recycle bin and the site recycle bin need to be considered when planning database sizes and growth.
This means that items that are kept within the recycling bin are not truly deleted but are rather still part of your content databases. These only further increase the size of your content database, making backup and recovery times longer. Circling back, with large databases, SharePoint’s native solutions cannot cope and provide the kind of backup and recovery that organizations require.
So what solution is there, that will allow you to decrease the size of your content database, without compromising your content? Furthermore, what solution will allow you to continue selective restoration at the item level without requiring recycling bin space?
Read “Changing the SharePoint Backup Game: How to Backup Multi-Terabyte SharePoint Farms in Minutes” to find out the solution to your problems.
On Wednesday, we’ll investigate further how to save space and improve SharePoint backup.