This is an exclusive blog by Soud Ereiqat, Systems
Engineer, AvePoint.
AvePoint were Diamond Partners at the the European
SharePoint Conference in Berlin 2011.
A solid recovery & backup 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.
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.
