With ever-increasing number of documents added to SharePoint repositories, one challenge seems to be growing and that is the amount of time it takes to complete SharePoint backups. Larger SharePoint databases due to BLOB storage in them are resulting in longer and longer running backups that never seem to finish. And, this is causing performance-loss, inefficient resource usage, increased likelihood of data-loss and failure to meet SLA commitments of SharePoint backup/recovery windows.
I receive complains from SharePoint administrators that many times they have to recover documents that users accidently deleted and they have also been removed from the Recycle Bin. Although SharePoint comes with a set of native tools for recovery, these tools usually don’t help much as none of them provides a very granular level of recovery.
One such tool is STSAdm for SharePoint backup. Its granularity is low and can be CPU intensive. As a result, Microsoft doesn’t recommend using it for large SharePoint backups. Another is “SharePoint Central Administration Backup/Restore”. It can help you protect content databases and associated search/index files. However, it cannot run backups on schedule. Further, it doesn’t allow retrieving subset of backup data and forces you to restore the entire content database. Microsoft doesn’t recommend using either of these tools for content databases larger than 100 GB and specially STSAdm for site collections larger than 15 GB.
Additionally, SharePoint administrators can use SQL Server database tools and techniques for reliable and timely backup/recovery, but they too have their own limitations.
Firstly, SharePoint by-default creates a single data-file for content database. And the BLOBs it stores in the database eventually grow to terabytes. But, they are all stored in one database file unless data-file is manually partitioned. A data-file of more than 200 GB is not recommended by Microsoft, as their backup usually results in a performance hit, exceeds the backup window and needs larger storage. It introduces an element of periodic maintenance too.
Secondly, content databases by design cannot span multiple file-groups; hence the option of parallel backups of file-groups in SQL Server cannot be exploited.
Resultantly, the available tools may assist the administrators with elementary SharePoint backup/recovery at best at certain costs. The question arises how long can you wait for your administrator to find/restore a lost document — minutes, hours, or days?
StorageEdge provides an out-of-the-box solution to overcome SharePoint backup/recovery troubles. By taking charge of your BLOBs and moving them out of database, it effectively addresses the root-cause of SharePoint backup concerns.
Figure 1: Configuring Storage Tiers in StorageEdge for BLOB storage
StorageEdge ensures the management of these BLOBS including their backup/recovery through the following:
• Simplified SharePoint backup/recovery – With fewer, smaller content databases, the SharePoint backup tools work like a charm.
• Externalizing BLOBs to different storage tiers such as SAN or NAS, administrators exploit the built-in features of these hardware.
• Letting the administrators configure the Recycle Bins to hold items for unlimited periods without fear of increasing database size makes self-recovery of documents possible.
• SQL Server is not the right place for your BLOBs. StorageEdge takes them to where they belong – File system, SAN, NAS or Cloud.
• Facilities such as policy-based storage tiers, compression and encryption not only reduce SharePoint backup/recovery times but also help you save on overall storage costs.