This is an exclusive blog by Soud Ereiqat, Systems Engineer, AvePoint. AvePoint are Diamond Partners at the the European SharePoint Conference in Berlin from the 17th-20th October.

A solid backup & recovery strategy for your SharePoint platform in case of a disaster or a situation that creates a need for single item restores is an important step when maintaining strict SLAs.

Single item restores should be seamlessly possible regardless of where the SharePoint content is stored.

By default, content (including metadata & BLOBs) is stored in the content database. When content is offloaded out of SQL using RBS in combination with an ISV specific EBS/RBS provider, such as the one provided in AvePoint's DocAve Software Platform for SharePoint, the metadata is stored in the AllUserData or AllDocs table. But the BLOB is offloaded to a NetShare of choice at upload or through scheduled jobs (determined by size, age or other metadata).

By breaking up the SharePoint content so that metadata and BLOBs are stored outside the SQL Server database we can improve SQL performance and scalability but we must of course ensure that the externalized content is included in our backup/restore.

In the case of externalized SharePoint content one should create a backup strategy that includes clear steps indicating when a restore of externalized content is necessary when using EBS or RBS technology.

DocAve offers ways of integrating the externalized BLOBs into backup and restore capabilities. There are numerous ways of dealing with externalized content when backing up using DocAve Data Protection. When running granular backups we can choose to either backup the links to the content or to backup the original content. When running granular backups with the option to backup the original content we must consider that the content would be sourced through the SharePoint API which can cause performance restraints. It is recommended to backup the links only and backup the BLOB store using file system methods. If using platform backups one could backup the SQL database and include the BLOB store through the Web Front End File System.

Due to the way that DocAve integrates the externalized content in SharePoint, backup strategy amendments for this content can be kept to a minimum. When the DocAve RBS Provider externalizes data it is stored as a binary in the BLOB store. The corresponding metadata stub is generated in SQL and linked to the BLOB instance. When files are edited we do not overwrite the existing document but create a new BLOB instance that is then linked to the existing metadata entry in SQL. The initial instance of the BLOB that is now redundant is marked as expired and will be cleared out of the BLOB store at the next garbage collection. One of the reasons for generating a new binary when a file is edited is that we can restore old instances without having to overwrite an existing file. Also, the repercussions of a corrupt file will only affect a single instance instead of related versions.

By using the garbage collection delay correctly additional steps necessary to restore externalized content that is residing in the external BLOB repository can be marginalised. The simple reason is that it is possible to delay the deletion of expired BLOBs by for example 60 days. A BLOB file is set to expired but remains in the BLOB store for 60 days AFTER the complete deletion out of SharePoint. A restore of a SQL metadata stub would simply set the expired BLOB to active and any further steps to restore a file from the BLOB store are deemed unnecessary.

Deletion Delay for expired BLOB instances in DocAve

Single item restores of BLOBs can be easy when the correct strategies are used. By using a schedule for garbage collection and a deletion delay of expired BLOBs administrative steps for restores can be kept to a minimum. In case of a disaster when a restore of the whole BLOB store is necessary, the general rule of thumb is that the externalized content should always be restored to the same UNC path. It is strongly recommended to restore the externalized content before initiating SQL database restores.

There are many resources that describe how the use of EBS/ RBS Technology can improve the performance of your SharePoint Infrastructure. There is a Microsoft research publication that describes the effect of the use of externalization technologies based on BLOB size. Taking large objects out of the SharePoint Content Databases can improve the stability and scalability of SharePoint. Nevertheless externalizing content witholut ensuring it is backed up and can be restored would be a step in the wrong direction. The information described herein is a vital addition to your backup & restore strategy to ensure your externalized SharePoint content is safe.

I hope this article helps shed some light on how to deal with content that was externalized from SharePoint Content Databases using EBE/ RBS API.

Come meet AvePoint at stand number 11&12  at the European SharePoint Conference.