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:

When SharePoint 2010 early sneak preview was first published by the product team, one of the big wow’s were the new granular content restore capabilities, available right there in Central Administration. While this is certainly an improvement compared to earlier version of SharePoint, I still cannot call this functionality “granular content restore”. Let’s walk through the steps required to restore a document from database backup with these new capabilities.

How to Restore from Unattached Content Database, Step by Step

1. Find the backup file that contains that document you need. You’ll need to know document original location so that you can match that to the content database. You will also need to find out when the document was corrupted or deleted, so that you grab the backup file from the right date. When you have all this information you can find the reuqired backup file (or probably request it from your SQL DBA or Backup operators).

2. Restore content database to a temporary location. Backup file is not enough, to use the unattached content database recovery you need the database mounted on a SQL server. This can be the same SQL instance used by SharePoint, or a different SQL box. If you restore into the same SQL instance make sure you (or your SQL DBA’s) use a different name for the restored database and don’t override the production content! Note the name of the SQL Server instance and the name of the database copy.

3. Go to SharePoint Central Administration, navigate to Backup and Restore and click the “Recover data from an unattached content database” link under Granular Backup.

4. Type the SQL Instance and temporary database names and specify what you want to do. Note that none of the available options actually allows you to restore a document, you can either create a backup of site collection or export a site or list. If you only need a single document, you’ll need to export the library in order to get it.

5. Select site collection, site and list to export. In this step you also specify the name for the export file and the export options, such as whether security and versions should be included in the export. You are ready to start the export.

Congratulations, you have completed the Unattached Content Database Recovery now! Wait, did you actually need that document? All you have is the export.cmp file, where to look next? There is no import available in the Central Administration UI. So what do you do next?

6. Start the SharePoint Management Shell, which is PowerShell with Microsoft.SharePoint.PowerShell snap-in already loaded. Then use the Import-SPWeb cmdlet to import the library. It is important to understand you cannot restore list or library under a different name. If a document library with the same name already exists in the destination site, import will merge contents and by default create new document versions where possible.

7. Finally, browse to the imported library and get the document you just restored. Once this is done, you can safely delete the imported document library from SharePoint, and delete the temporary database from SQL server.

Pros and Contras of Unattached Content Database Recovery

If you ever had to perform granular content restore via a recovery farm in SharePoint 2003 or SharePoint 2007, you can see the process is not very different with 2010. The big step forward is that there is no need to maintain the recovery farm for SharePoint 2010 and you don’t have to attach the temporary database to the farm. You also have the UI to do the export via Central Administration.

However, that’s where improvements end and all the limitations remain:

  • You have to know exactly which backup contains the requested data, there is no search available. If you make a mistake, it is not until the very last step in the process that you find out the document you looked for is missing after the import and you have to start it all over.
  • You must use higlhy privileged account to perfrom all operations in both SQL and SharePoint, which might not be possible in some environments. Sometimes in a large organization it would take 3 different people to perform the task.
  • There is no single UI to perform the operation from the first to the last step. You have to use SQL backup management tools, SharePoint Central Administration and PowerShell, which obviously increases time to restore.
  • Granularity is limitied. You can restore a site collection, a site or a list/library.
  • Finally, all inherited limitations of SharePoint export and import apply when restoring sites and lists from unattached content database.
Technorati Tags:

Nice people from Cengage Learning contacted me recently for a review of a book they published. The book is called SharePoint 2007 Disaster Recovery Guide and was written by John L. Ferringer and Sean McDonough.

They were also very kind to send me three copies of the book for giveaway, but since you won’t believe it on April 1st anyway ;-) there’ll be a separate post soon explaining how to win your copy.

Who should read this book?

This book will be invaluable for SharePoint administrators who already have a good understanding of how data is stored in SharePoint and have some technical experience with built-in backup and recovery tools. I think it would be a difficult read for those who only have end user experience with SharePoint and are new to the platform administration. It will be overwhelming and confusing for such readers.

Why read this book?

I think that anyone who already has such experience and is tasked with preparing an overall disaster recovery plan should read this. Here’s the good stuff you will find in the book:

  • Helpful tips on what you can do with the native backup and recovery tools and how you could extend them via scripting and custom development can be found troughout the book, specifically in chapters 6-7.
  • If you are SharePoint administrator with not much experience in technologies it depends on, such as IIS and SQL Server, you’ll find quite a few insights here and get a bigger picture of what tools exist and can be used in SharePoint disaster recovery. Chapters 8 through 11 cover SQL server and Windows backup and recovery and high availability.
  • Real jewels in chapters 12 through 14 (DR Planning and Key Concepts; Design and Implementation; Testing and Maintenance) are a must-read for any technical staff responsible for SharePoint recovery. Too often we think of SharePoint just from technical perspective, these chapters help to put the technology in the right place from perspective of the overall business continuity planning.

Some suggestions for the Second Edition

Few things that I believe could be done better to make the book more straightforward for SharePoint newbies, not only administrators with good level of understanding:

  • Add an overview of how SharePoint data, configurations, and customizations are stored. A lot of this information is scattered throughout the book, but there’s no single chapter in the book to serve as a reference. Things like Joel’s SharePoint containment hierarchy could really help here.
  • Make it very clear how much technical knowledge and experience is assumed. Some sections of the book surprised me by too detailed explanations of the basics (like the default install paths with screenshots, etc.), while the very next page can mention about IP bindingsin IIS with no explanation at all.
  • Re-write or cut the chapters that cover topics that are not directly related to disaster recovery. It’s good to know about recycle bins, SharePoint Designer backups, and maybe even the options such as saving site templates with content. But none of these really fits into the disaster recovery plan discussed further on in the book, and spending almost 60 pages on them might be too much.
  • Get another round of technical review to ensure all technical details are accurate and there is no ambiguity. For example, in several places the book mentions you can restore a single site collection from a Central Administration backup. In reality, this is only true when you keep one site collection per content database. This assumption is never articulated in the book, which can be really misleading for readers who don’t have hands-on experience with Central Administration and STSADM.exe backups.

Bottom line:

SharePoint 2007 Disaster Recovery Guide is a great resource for SharePoint administrators with good technical understanding of SharePoint overall architecture and built-in backup and recovery tools. From reading it you can learn how you can extend the use of the native tools with other methods, and see what other technologies such as Windows Server and SQL Server have to offer. Finally, the book allows you to take a step back and see the bigger picture of SharePoint disaster recovery from the business perspective.

So, take your time to review the ToC with John’s comments and stay tuned for the giveaway details!

Technorati tags:

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:

When someone downloads and installs Windows SharePoint Service with the default settings, the install wizard hardly indicates that SQL engine is being used in the back end. Is this a problem for SharePoint admins? And for SQL DBA’s? What happens when SharePoint grows in size and importance for the organization? Do the SQL DBA’s need to think about SharePoint backup and restore?

These were the questions discussed in a recent webcast by David Walker, ASP .Net MVP and specialist in enterprise apps architecture, and David Gugick and Doug Davis from Quest Software, where they are leading Product Management teams for Quest’s SQL and SharePoint product lines.

I missed the webcast but the recording is available for download the recording from Quest website. Although it was primarily meant for SQL Server administrators, it really helps to understand what common problems SharePoint and SQL admins are facing and why it’s so much easier to solve them together.

Technorati Tags:
, , ,

It’s been over half a year since Microsoft announced WSS v3 hotfix that allows to store SharePoint data outside SQL Server with a KB article that Todd Carter called one of the worst articles he had seen. And last week Adam Woodruff also published results of his research about keeping SharePoint files outside SQL database. This hotfix basically exposes an API for anyone who cares to develop a solution themselves.

Both Todd’s and Adam’s posts make me think that SharePoint data on external storage is still only a theoretical possibility rather than something real. The API is not guaranteed to be supported, and has several challenges. I wonder if anyone actually created a provider based on the API yet, I could not find any reference.

The biggest issue from my perspective is the API does not have a built-in mechanism to guarantee consistent backups. A backup tool for such deployment would have to be smart enough and consider different parts of the same object are stored in different places (e.g., hierarchy and metadata in SQL and the file itself on external storage).

BTW, with this entry Adam started his blog finally – after I teased him in the recent post about our new SharePoint recovery white paper. Adding the link to my blogroll and hope to see more exciting stuff there!

Technorati Tags:
, , ,

I recently mentioned several good sessions I attended in Seattle conference in a blog post about importance of understanding the crucial role of SQL Server in the SharePoint world. Now you can download the slides for the sessions I mentioned (even if you don’t have login at www.mssharepointconference.com):

Awesome stuff. Curious to see these slides published now after the Dubai SharePoint conference, but not after the bigger event in Seattle a month ago… Thanks to the Dubai sun?..

%d bloggers like this: