I’ll cut straight to the chase: no, a configuration database backpastedimage1478188484999v3.pngup is not just a fancy paperweight. The prevailing wisdom in the SharePoint space is that configuration database backups are generally useless, and there’s a reason for that perception. The reality is a bit more complex and requires some discussion.
I’m not the first to address the topic of SharePoint farm configuration database backups. A few years ago, Ilia Sotnikov wrote a great blog post titled Mysterious config database: you can back it up but not restore? that addressed the topic. The majority of the information he presented back then (written in the SharePoint 2007 time frame) is still accurate and relevant today, but SharePoint 2010 and some platform advances have changed the equation a bit.
The Approach
This post examines the topic of SharePoint farm configuration database backups through a set of questions and answers. Many of the questions are ones that I regularly see or receive myself when speaking, via email, and through Twitter. Benjamin Athawes’tweet on the right is a great example.
I know Ben, and he’s a bright guy. He already knew the answer to the question being posed, but he had read something that ran counter to the correct answer.
That’s the problem with the topic of SharePoint farm configuration database backups: lots of contradictory information. That’s also why I do my best to reference relevant technical resources and go “a level deeper” in this post.
So, without further ado …
Let’s Play Q&A!
Can I back up a SharePoint farm configuration database?
Sure. Knock yourself out. And don’t let the following sentence about SharePoint-based backups (from TechNet) scare you away:
Backing up the farm backs up the configuration and Central Administration content databases, but these cannot be restored using Microsoft SharePoint Server 2010 tools.
“Possible to back up” and “cannot be restored” are two different things. I cover how database backups may be used a bit later in this post.
Wait a minute – a SharePoint farm configuration database can’t be restored using SharePoint’s own tools?
Strictly speaking, no. If you need the official statement, check out the support article from Microsoft titled Restoration of the configuration database by using the built-in backup and restore functionality is not supported in SharePoint Server 2007 or in Windows SharePoint Services 3.0. Note that the article applies to the SharePoint 2010 platform as well (as identified in the article’s “APPLIES TO” section).
I really dislike the cut-and-dry way the “cannot be restored” statement is made, though, because it may leave you with the impression that you don’t get farm configuration data back when you do a full-farm restore using SharePoint’s tools. Practically speaking, you do get the farm configuration back – you just don’t get the SharePoint farm configuration database itself that was part of the backup set.
When a full-farm backup is performed using SharePoint’s native farm-level backup mechanism, your farm’s configuration data is transcribed into the backup set. When you execute a restore with the same built-in tools, that configuration data flows back into the farm’s “new” configuration database. The “new” database doesn’t get overwritten by the “old” database from the backup set, but the “new” database does get populated with the configuration settings that were captured in the backup set.
So it’s okay for me to create a backup of a SharePoint farm configuration database using SQL Server’s built-in tools?
Yes. A SharePoint farm configuration database is just like any other SQL Server database for purposes of backup. Just don’t plan on restoring that database by itself; “restore challenges” are an entirely different topic.
Using SQL Server to back up a SharePoint farm configuration database prior to SharePoint 2010 was mostly a “for the sake of completeness” checkbox. There was little that you could actually do with the database backup. That changed with SharePoint 2010, though. I discuss why that is a little later in this post.
Can I restore a SharePoint farm configuration database using SQL Server’s database restore mechanism?
Stand-alone restoration of a SharePoint farm configuration database is not supported. This is implied by the previously referenced article dealing with SharePoint’s backup and restore functionality. It’s spelled-out a little more clearly in this TechNet article under the “Use SQL Server tools to restore a farm” section:
Although you cannot restore the complete farm by using SQL Server tools, you can restore most of the farm databases. If you restore the databases by using SQL Server tools, you must restore the farm configuration by using Central Administration or Windows PowerShell. For more information about how to restore the farm’s configuration settings, see Restore a farm configuration in SharePoint Server 2010.
Please note my emphasis on the phrase stand-alone. “Thou shalt not restore a SharePoint farm configuration database” is true in the overwhelming majority of cases.
Is there any supported way to restore a SharePoint farm configuration database from a database backup?
I already mentioned that a restore using SharePoint’s native full-farm capabilities effectively puts your configuration back, but the mechanism employed isn’t a database restore. So, can a SharePoint farm configuration database truly be restored using a database restore mechanism?
Old school SharePoint administrators may find this hard to believe, but the answer is yes. The circumstances under which a restore is permitted (and supported) are very specific, though.
The farm configuration database backup must be captured as part of a backup that’s performed by an application that leverages the SharePoint Foundation Volume Shadow Copy Service Writer(or SPF-VSS Writer for short). The SPF-VSS Writer, in conjunction with the Windows Volume Shadow Copy Service, enables an appropriately written application to create and back up a point-in-time consistent snapshot set of all registered SharePoint farm databases and Search index files. The SPF-VSS Writer also permits such applications to restore the databases and index files from a backup set – including the SharePoint farm configuration database. From the SPF-VSS Writer article on MSDN:
The SPF-VSS Writer enables a requestor to select all databases, a segment of the databases (multiple select), or a single database (single select) for both backup and restore operations. All databases, except configuration and the Central Administration content database, are selectable through the writer. The configuration and Central Administration content databases can be backed up and restored only as part of the whole farm.
The last sentence in the excerpt above is key: a SharePoint farm configuration database that is part of an SPF-VSS Writer-based backup set can only be restored when the whole farm is being restored from that backup set with the aid of the SPF-VSS Writer. The SPF-VSS Writer takes the necessary steps (following a full-farm restore) to ensure that the farm configuration database and other SharePoint databases are synchronized.
What’s the big deal? Why can’t I restore the SharePoint farm configuration database by itself?
The support article referenced earlier covers the synchronization issues that may surface. Simply restoring a SharePoint farm configuration database doesn’t do anything to synchronize the configuration between the farm configuration database and the other databases in the farm. For example, the rows in the SiteMap and SiteUrlMap tables need to properly map to the site collections and paths in each content database. That’s one problem.
Another problem is that a SharePoint farm configuration database contains topological and environmentally specific information about a SharePoint farm, and this has a big impact on farm configuration database portability. To demonstrate, I popped open the Objects table in the farm configuration database of a SharePoint 2013 preview farm I’m working on and focused on just a few rows (below).
Examining the entries in the Name field in the image above, you can clearly see references to database names(SharePoint_AdminContent_* and SharePoint_Config), references to server names (SP2013-WFEand smtp.sculptedsystem.com), and a whole host of other environmentally specific information. Entries like these drive home the fact that each farm’s configuration database is specific to one SharePoint farm. Introducing an older instance of a configuration database into a SharePoint farm is a risky proposition, particularly if any type of environmental changes were made following the farm configuration database backup.
To reiterate: farm configuration databases need to be backed-up and restored as part of a full-farm database set to avoid synchronization issues between the farm configuration database and other databases in the farm. The SPF-VSS Writer is one way to achieve point-in-time consistency across an entire farm’s collection of databases and search indexes. Other ways exist (shutting down the entire farm for instance), but supportability varies based on approach.
TechNet talks about restoring my farm’s configuration. Is the “farm configuration backup” mechanism described a viable alternative to restoring my farm configuration database?
Many of the TechNet articles indicating that a SharePoint 2010 farm configuration database cannot be restored point readers to the Back up a farm configuration in SharePoint Server 2010 article (and its complement, Restore a farm configuration in SharePoint Server 2010) as the solution to the “I can’t restore a farm configuration database” problem.
To that, I say “baloney.”
When configuration-only backup and restore was introduced in SharePoint 2010, I dissected the new capability in a blog post titled Configuration-Only Backup and Restore in SharePoint 2010. While I encourage you to check out the post for a full look at how configuration-only backup and restore works, the conclusion I drew was that the capability doesn’t allow for any significant configuration protection or migration. The capability actually covers very little in the way of farm configuration, and it also has major gaps; for example, it doesn’t cover Web application or service application configuration.
Configuration-only backup and restore can help in some configuration-related tasks, but it is better suited to protecting and migrating only a handful of settings and objects – not an entire farm’s configuration.
Okay, slightly different question: can I move my SharePoint farm configuration database to a different SQL Server?
Yes, but only as part of a move that relocates all SharePoint databases from one SQL Server to another. This question comes up often enough that Microsoft provides guidance for the scenario via the Move all databases (SharePoint Server 2010) article on TechNet.
A bit earlier, I mentioned that the farm configuration database tracks server names and topology within the farm environment; that tracking extends to the SQL Server name or connection alias that is used by farm members. Reading the TechNet article, you’ll notice the reliance on SQL Server connection aliases that get established during the move process. They’re the lynchpin needed to make everything work once the databases have been moved to a different SQL Server. Since there is no supported way to change the name of the SQL Server (as tracked by the farm configuration database), a SQL Server connection alias is needed on all farm members to “re-wire” the farm members to the new SQL Server.
On a related side note: I normally recommend the use of SQL Server connection aliases any time a SharePoint farm is set up. For those of you who have read other posts of mine that reference farm topology, you’ve probably seen me use SpSqlAlias in place of an actual server name whenever I demonstrate connecting to a SQL Server. Starting with an alias is actually recommended as part of hardening SQL Server for SharePoint, and an alias simplifies topology changes that might occur later on – such as the SharePoint database move scenario.
If I can’t restore a SharePoint farm configuration database from SQL Server backup, then what good is the backup?
For purposes of a straight database restore into a SharePoint environment, it’s no good. The one point I’ve tried to consistently make throughout this post is that there is no supported (or recommended) scenario where a SharePoint farm configuration database can be restored by itself into a SharePoint environment.
That doesn’t mean that a lone SharePoint farm configuration database backup is just a fancy virtual paperweight. I mentioned configuration-only backup and restore a bit earlier. Although the capability is only usable with a subset of farm configuration data, it has its uses. I’m particularly fond of it for the purpose of extracting all solutions (.WSP packages) that were in a SharePoint farm’s solution store. Extracting solution packages in this fashion is an easy way to copy all solutions from one farm to another.
A stand-alone farm configuration database (unassociated with a farm, as might be the case if the database is restored by itself) can be the target of a configuration-only backup using the Backup-SPConfigurationDatabase PowerShell cmdlet. If you’re interested in learning more, check out a separate post I wrote titled A Tale of Two Cmdlets.
I understand the risks, and I know I’ll be unsupported. Realistically, what’s going to happen to my environment if I restore the SharePoint farm configuration database by itself?
That is the $64,000 question. Your farm may run without issue. Or it may tank. Or it may mostly run with problems here and there. It really depends on the degree of synchronization between the farm configuration database and the rest of the databases in the farm.
If you’re willing to accept that you’ll be moving your farm into an unsupported state, then a farm configuration database restore can sometimes mean the difference between a dead farm (requiring rebuild) and quickly returning a farm to an operational state. To be clear, though: I can’t think of any instance in which I would advocate for a stand-alone farm configuration database restore in a production, staging, authoring, or any sort of related “real” or “important” environment. The risk and loss of support just isn’t worth it.
I’ll be honest, though, and say that I have done a farm configuration database restore in a development VM environment. Back in the SharePoint 2007 days, I had a well-intentioned (but misguided developer) use a tool that resulted in irreparable damage to the content type hierarchy of a development farm I was responsible for. The farm was effectively “brain dead,” and I was looking at a full environment rebuild. A configuration database backup had been captured just a few hours earlier, so I took a chance and restored it. We all got lucky and the farm became operational again. At that point, though, I (and everyone else) knew that we were unsupported. It was an informed decision, and the risks and implications were accepted by everyone ahead of time.
Nowadays, I wouldn’t take the same risk because there are simply too many good tools to automate farm builds. The one I lean on heavily is AutoSPInstaller. If you’re not familiar with it, you owe it to yourself to check it out. Rather than restoring a farm configuration database (and accepting all the risks and stigma associated with that decision), you can simply kick off another farm build and be back to operational without losing too much time.
Is any of this going to change with SharePoint 2013?
SharePoint 2013 is still in preview at the time that I’m writing this, but the likely answer is “no.” I’ve reviewed much of the backup and restore documentation that has been made available, and I see very little that has changed since SharePoint 2010. The platform isn’t nailed down just yet, though, so there’s always the potential for a surprise or two.
References and Resources
- Blog: Ilia Sotnikov’s Restore Point. SharePoint.
- Blog: Benjamin Athawes Tales from a SharePoint Farm
- TechNet: Backup up a farm in SharePoint Server 2010
- Microsoft Support: Restoration of the configuration database by using the built-in backup and restore functionality is not supported in SharePoint Server 2007 or in Windows SharePoint Services 3.0
- TechNet: Restore a farm in SharePoint Server 2010
- MSDN: SharePoint Foundation VSS Writer
- TechNet: Back up a farm configuration in SharePoint Server 2010
- TechNet: Restore a farm configuration in SharePoint Server 2010
- Blog Post: Configuration-Only Backup and Restore in SharePoint 2010
- TechNet: Move all databases (SharePoint Server 2010)
- TechNet: Harden SQL Server for SharePoint environments (SharePoint 2010)
- Blog Post: A Tale of Two Cmdlets
- Wikipedia: The $64,000 Question
- CodePlex: AutoSPInstaller