Just got another question about SharePoint 2010 remote BLOB storage (RBS) and its impact on the backups. The topic is already covered by so many posts and articles, I will just add a quick summary and few links to more details.

There are three simple things to remember about RBS and backups:

  • It is the RBS provider implementation that defines how backup works for externalized content. External content may or may not be included in your backups, depending on the provider you choose.
  • With the out of the box SQL 2008 R2 RBS FILESTREAM provider, externalized content is included in traditional VDI backups (“virtual backup device interface”). That is, native SQL and SharePoint backups will include both the database and the external content. Same is true for all 3rd party SQL backups that use VDI.
  • The out of the box SQL 2008 R2 RBS FILESTREAM provider does not support snapshots. Any SQL backup based on snapshots (such as Microsoft Data Protection Manager) will NOT automatically protect the external content.

If you plan to leverage RBS to reduce the size of your databases in SQL, you may have to change your backup strategy based on the above. Major questions are:

  • What is your current backup strategy, do you use snapshots or traditional backups?
  • How does the RBS provider of your choice work with the existing backup? Will external content be automatically included in backups?
  • If yes, make sure you and your SQL DBAs are aware that backup files can be MUCH larger than SQL database size
  • If not, how will you handle backup and restore of the external content? For example, if your backup is snapshot-based, you should take same time snapshots of the file system or NAS location with the external content. Make sure you test and thoroughly document all recovery scenarios in this case.

See also Plan for backup and recovery on Microsoft TechNet for other considerations.

Configuring RBS FILESTREAM for SharePoint 2010 and SQL 2008 is not a trivial task. Ghazwan Khairi recently started his SharePoint Quester videoblog, and one of his posts goes step by step through installing and configuring RBS for SharePoint 2010. This includes all script snippets and command line examples that you’ll need. Very helpful and detailed, check it out.

Finally, if you wonder why anyone may want to go into all this trouble with configuring RBS, it is worth reading Chris McNulty’s blog series on top SharePoint performance killers.

Technorati Tags:
Advertisements

When you start planning for disaster recovery of your SharePoint farm you inevitably face the challenge of how to restore the farm configuration.

What is a configuration database? A configuration database in SharePoint is what defines your farm. It keeps all the information about other databases, servers and services that comprise the farm. It also stores info about “all Internet Information Services (IIS) Web sites or Web applications, solutions, Web Part packages, site templates, and Web application and farm settings specific to SharePoint technologies, such as default quota, blocked file types, and configuration” (from Database types and descriptions). If you want to drill into this in more detail, take a look at the database structure explained in Nidhi’s blog.

The coolest thing about configuration database in my opinion is how it serves as a central piece in WSS 3.0 architecture to allow administrators easily scale a SharePoint farm. All the global farm settings, most of IIS configuration (some details in Joel’s post here), and even solution binaries are stored in the config database and will be automatically propagated from there when you join more servers to the farm.

What’s the problem with backup/recovery of configuration database? Restoration of SharePoint configuration database is not supported by Microsoft if all you do is just take farm backup via Central Administration or with STSADM. In case of disaster recovery, you would have to manually re-create all farm settings, re-deploy any solutions and customizations, etc. A related article on TechNet gives a little insight on what causes this support limitation:

Although the configuration database and the SharePoint Central Administration Web site content database can be backed up, restoring backups of the configuration database and Central Administration content database from a farm by using the tools built in to SharePoint Products and Technologies is not supported.

This is because data in these databases may not be synchronized with data in other Microsoft Office SharePoint Server 2007 databases. Therefore, the tools built in to SharePoint Products and Technologies do not recover these databases during a farm-level recovery.

If this data is not synchronized, users might experience various random errors.

So, is there any way I can back up and restore the config database? We were discussing this with a well-known SQL expert Charley Hanania a while ago, and came to a simple thought – if something can be backed up, it must be possible to restore it. It’s the question of understanding the risks and choosing the right tools to mitigate them. If the risk is that SharePoint farm structure information in config database would be not synchronized with other databases, you need a way to make a point-in-time backup of all databases within the farm, ensuring that none of these databases changes during the backup process. How is this possible?

  • Obviously, snapshot technologies and products that use them can achieve this functionality. For example, this allows Microsoft Data Protection Manager to back up and restore all SharePoint databases, including configuration db.
  • Another supported way to restore all databases suggested on TechNet is to take a backup when the SharePoint farm is offline. Essentially, this means all SharePoint services are stopped across all front end and application servers, and no changes are being made during the backup process. Does not seem feasible for live SharePoint environment? This is where SQL Server’s features such as log shipping or database mirroring can help. Both techniques allow you to create and maintain a copy of SQL database that is not accessed by SharePoint. So working closely with your SQL DBA you can have a “point-in-time” copy of all the farm databases and back them up.

Config db is not the only reason why you can utilize log shipping and/or database mirroring in SharePoint environment. For example, see Mike Watson’s recent presentation decks from Best Practices and SPTech conferences, where he discusses how both options apply to SharePoint environment for high availability and disaster recovery.

Technorati tags:

I just came across a recent SharePoint Backup / Recovery Solutions blog post by Babar Batla, Principal Solutions Specialist for Microsoft. In his list, Babar has both Microsoft Data Protection Manager 2007 and Quest Recovery Manager for SharePoint (and that’s the product I am working on). So do these products compete? Not really, they can actually complement each other! So, when do you use which?

With a recent release of Recovery Manager 2.2 we enhanced it to read and restore data from snapshots made with DPM as well as few other backup formats (see our web site for details). Adding this on top of DPM you can use the same snapshots in more SharePoint restoration scenarios:

  • Granular restore with DPM is only possible for documents and sites. Recovery Manager adds restore of any SharePoint objects, from a list item or document up to a site collection (and everything in between!) – all from the backups you already have with DPM.
  • Recovery Manager also gives more flexibility when the original server farm is unavailable: you can restore SharePoint data to an alternative SharePoint location or even a file share.
  • In addition, organizations where backup operations are centralized can benefit from using tools like Rcovery Manager and DPM together, because this allows to separate platform disaster recovery task from document and site restore, and the latter can be delegated to application specific administrators.

Technorati tags:

I recently blogged about the release candidate build of DPM 2007, and it just went RTM two days ago. One of the interesting features of the new release is support for granular recovery of SharePoint 2007 items via a staging farm environment.

The product page still has no specific datasheets or whitepapers on SharePoint protection, but there is a Protecting SharePoint with DPM webcast scheduled for November 27th. For those who cannot wait that long to learn more, 120-days trial is free and available for download (requires registration).

Technorati Tags:
, , , , , ,

Okay, it is real now: the DPM blog announced System Center Data Protection Manager 2007 Release Candidate few days ago. I am not going to talk about all cool new features of DPM 2007, there are loads of info on it’s web page (by the way, including pricing and licensing options). But one new feature I am excited about is the new document level recovery for SharePoint! And it is new in this build, actually, it was not available in Beta builds, so I cannot wait to try it live!

Unfortunately, there is not as much info available about SharePoint protection yet as for other platforms: for example, there are white papers on protecting Exchange or SQL. I would love to see similar white paper about SharePoint protection eventually, but now we have the build to explore – what are you waiting for?! Download the free 120-day trial software, try it and tell what you think about it. And here’s a great DPM installation walkthrough from Sean Earp to help – thanks Sean!

My very first observations are:

  • It does not keep data twice! Same snapshot is being used to restore entire database (or all databases within a farm) or to restore a site or just a document. Very cool, no more stressful and long site-level backups with STSADM.exe.
  • It allows browsing and searching through SharePoint contents from within the DPM Console, and selectively restore the data that you need. Way better than you could ever get from SQL backup and STSADM.
  • It requires a staging SharePoint server (all-in-one installation seems to be enough) for granular recoveries. Looks like DPM automates the good old method of re-attaching content database to a staging server, and eliminates most of the manual work this method requires from admin.
  • Document level restore only available for SharePoint Services 3.0 and MOSS 2007. You can still use DPM to protect WSS 2.0 and SPS 2003 content databases, as part of SQL protection functionality.

I will blog more about DPM and SharePoint recovery as soon as I play more with it.

Technorati Tags:
, , , , , , , ,

%d bloggers like this: