Configuration-Only Backup and Restore in SharePoint 2010

In this post, I discuss SharePoint 2010’s new configuration-only backup and restore capabilities, how they work, and why they probably aren’t going to remove the need for farm configuration documentation anytime soon.

Since our SharePoint 2010 Disaster Recovery Guide is written, starched, pressed, and ready to wear, I thought it was time to get back to some of the blogging I promised to start doing again once the book was finished.  I guess that if I didn’t have something to write, I simply wouldn’t know what to do with myself.  <insert smirk here>

Motivation For This Post

SharePoint 2010’s configuration-only backup and restore capabilities are on a long list of topics I’ve been meaning to blog about, but in all honesty it wasn’t at the top of that list.  I’ve been seeing the topic start to get some real attention in a number of forums, though, from folks like Todd Klindt (in one of his recent netcasts) and Benjamin Athawes (in his blog and in the helpful replies he’s been providing out in Microsoft’s TechNet forums).

It seems that many folks in the SharePoint community have heard about configuration-only backup and restore, and I think there’s an awful lot of hope that it will help with some of the problems we faced with SharePoint 2007.  By the time you finish reading this post, I hope to impart a solid understanding of what configuration-only backup and restore will – and won’t – do for you.

The Elephant In The Room

Before I go any further, let me address the question that I suspect the overwhelming majority of you probably want an answer to:

Will configuration-only backup and restore let me clone my SharePoint 2010 farm?

The quick answer: no.  At the risk of being a bit flippant, I’ll include a slightly longer answer: heck no – not even close.

When configuration-only backup and restore was introduced to the world, it promised so much.  I remember hearing the discussion of “farm templates” and of “cloning configuration.”  I remember sitting through Bill Baer’s business continuity management (BCM) session at the SharePoint Conference in 2009 and thinking about all the things I was going to do with the new capability.

In light of what I now know about configuration-only backup and restore, I went back to the recorded SPC sessions (including SPC311 – Bill’s BCM session) to make sure I wasn’t hearing things.  I wasn’t.  My guess is that the initial vision for configuration-only backup and restore had to get scaled-back prior to the product becoming generally available.  Maybe the team ran out of time, maybe they hit technical hurdles, or perhaps it was a combination of the two.  Regardless, the capability in its current form isn’t quite what I had hoped it would be.

Enough with the hand-waving.  Let’s dive in.

High-Level: What Is Configuration-Only Backup and Restore?

For a brief primer on configuration-only backup and restore, check out the “Backup and recovery overview (SharePoint 2010)” article on TechNet.  If you don’t want to take the time to read the article, though, I’ll sum it up for you: a configuration-only backup and restore allows you to extract portable configuration settings from a SharePoint 2010 farm configuration database and apply those settings to a different farm.  The promise, as indicated earlier, is that you could effectively “clone” the configuration of a farm.  The configuration template that would be generated from this process could then be applied to other farms to create copies of the original farm’s settings and configuration.  This would be extremely beneficial when duplicating environments (e.g., creating staging and testing environments that match a production environment), building development and demo virtual machines (VMs), and more.

Those of you who have worked with SharePoint 2007 recognize the leap forward that this represents.  Anyone who has spent any amount of time exploring SharePoint backup and recovery knows that farm configuration databases are tied to their SharePoint environments.  Microsoft doesn’t support transplanting one farm’s configuration database into another farm; most of the time, it simply wouldn’t work.  Even if you could get it to work through some extremely impressive techno-jujitsu, you’d be in a horribly unsupported state as far as Microsoft support was concerned.

What Does It Look Like?

Configuration-only backup and restore in SharePoint 2010 is an extension to the existing catastrophic backup and restore capabilities located in the Microsoft.SharePoint.Administration and Microsoft.SharePoint.Administration.Backup namespaces.  The processes and mechanisms that allow you to create farm-level backups from Central Administration (through “Farm Backup and Restore”), PowerShell (via Backup-SPFarm), and STSADM.exe (via STSADM –o backup in catastrophic mode) are the same ones that are employed in configuration-only backups.

In fact, the backup sets that are generated from a configuration-only backup are basically the same, structurally speaking, as those that are generated from a “normal” (content + configuration) catastrophic backup.  One easy way to determine the nature of a backup, though, is to crack open the backup location’s table of contents file (spbrtoc.xml) and examine the value within the <SPConfigurationOnly /> element for a given backup or restore run (represented by a <SPHistoryObject /> element).

For example, this particular backup run was clearly a configuration-only backup because its <SPConfigurationOnly /> element contains a value of True
[sourcecode language=”xml” highlight=”9″]<SPHistoryObject>
<SPStartTime>08/18/2010 16:15:12</SPStartTime>
<SPFinishTime>08/18/2010 16:15:37</SPFinishTime>
If you browse the folder containing the backup set that is generated from a configuration-only backup, you’ll see the expected array of sequentially numbered hexadecimal .bak files, as well as a log file (spbackup.log) and backup component hierarchy file (spbackup.xml).


The .bak files themselves contain XML-serialized representations of various farm objects that were captured during the configuration backup process:

[sourcecode language=”xml” wraplines=”false”]<object type="Microsoft.Office.Server.Administration.DiagnosticsService, Microsoft.Office.Server, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c">
<fld type="System.Collections.Hashtable, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="m_Throttles" />
<fld name="m_Versions" type="null" />
<fld name="m_UpgradeContext" type="null" />
<fld type="System.Collections.Hashtable, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="m_UpgradedPersistedFields" />
<fld name="m_Properties" type="null" />
<sFld type="String" name="m_LastUpdatedUser">SPDC\s0ladmin</sFld>
<sFld type="String" name="m_LastUpdatedProcess">psconfigui (4228)</sFld>
<sFld type="String" name="m_LastUpdatedMachine">SPDEV</sFld>
<sFld type="DateTime" name="m_LastUpdatedTime">2010-04-25T17:38:27</sFld>

Again, this is all very similar to a standard catastrophic farm backup.  The one notable absence in the backup set that is produced during a configuration-only backup is that of SQL Server database backup files that begin (internally) with a telltale TAPE header.  The absence of these files is expected, though, since configuration-only backups operate on farm configuration settings and metadata – not the content and other data that is housed primarily in SQL Server databases.

“Wait,” you might be saying, “service applications typically have quite a bit of configuration data, and much of that data is housed in SQL Server databases.  Wouldn’t those databases be captured by the configuration-only backup process?”  Hold that question – I’ll be addressing it in a short bit.

A Quick Peek At What’s Going On Under The Hood

To better understand how configuration-only backup and restore works, it helps to dive below the backup set and into the SharePoint object model to see what’s actually happening.  If you’re not a developer, no worries – I’ll try to keep this simple.

The type that is the backbone of configuration-only backup and restore operations is the IBackupRestoreConfiguration interface.  Classes in the SharePoint object model can implement this interface (and supply a CanBackupRestoreAsConfiguration property value of true) if they wish to meet the bare minimum requirements for inclusion in configuration-only backup and restore operations.

If you’ve worked with catastrophic backup and restore in the SharePoint object model before, this interface name may seem a little familiar to you – even if it isn’t.  That’s because extending the native catastrophic backup and restore functionality of SharePoint to include new content classes is done through the similarly named IBackupRestore interface.  IBackupRestore came before IBackupRestoreConfiguration, and the latter is actually derived from the former.  The patterns of interaction between the runtime backup objects and objects that implement these two interfaces is very similar – as you might expect given their inheritance relationship.

So you might be wondering, “So what?  I don’t plan to build configuration-only backup and restore-capable components.  Why are you going through all of this.”  The answer to that question is relatively easy to answer: we can get a pretty clear understanding of what is actually included in configuration-only backup and restore operations by looking at the SharePoint classes that implement the IBackupRestoreConfiguration interface.

Hold onto the concept of examining types that implement IBackupRestoreConfiguration; we’ll be coming back to it in just a second.

What Does A Configuration-Only Backup Actually Capture? – Part 1

Let’s leave the SharePoint object model and come back up to ground level for a moment.

In plain English, configuration-only backup and restore is basically supposed to address the “I need to create a template of my farm” pain point we felt with SharePoint 2007.  Does it?  What gap is filled by the capability according to Microsoft?

If you read the TechNet article I linked to earlier, you’ll find just five types of settings (or configuration data items) that are actually listed as included in a configuration-only backup:

  • Antivirus
  • Information rights management (IRM)
  • Outbound e-mail settings (only restored when performing an "overwrite").
  • Customizations deployed as trusted solutions
  • Diagnostic logging

I don’t know about you, but this doesn’t exactly line up too well with the list of things I’d want to replicate from Farm A to Farm B if I were actually trying to clone Farm A configuration settings.  Don’t get me wrong: several of the items listed are things I would want to bring across (especially the customizations in the farm solution store), but there are a whole host of additional things I’d want to see.

What Does A Configuration-Only Backup Actually Capture? – Part 2

The five bullet points I just supplied aren’t entirely well-defined, and they’re more than a little “light” in terms of farm configuration data.  Let’s define the list a bit more clearly by seeing which classes in the SharePoint object model actually implement the required IBackupRestoreConfiguration interface.

When I fire-up Reflector and analyze the types that use the IBackupRestoreConfiguration interface, I come up with the following classes (ignoring the SPBackupRestore type, since its ImplementsIBackupRestoreConfiguration method only checks to see whether or not other objects themselves actually implement the interface):

  • Microsoft.SharePoint.Administration.SPDiagnosticsServiceBase
  • Microsoft.SharePoint.Administration.SPFarm
  • Microsoft.SharePoint.Administration.SPResourceMeasure
  • Microsoft.SharePoint.Administration.SPSolution
  • Microsoft.SharePoint.Administration.SPSolutionCollection
  • Microsoft.SharePoint.Administration.SPSolutionLanguagePack
  • Microsoft.SharePoint.Administration.SPUserCodeExecutionTier
  • Microsoft.SharePoint.Administration.SPUserCodeLoadBalancerProvider
  • Microsoft.SharePoint.Administration.SPUserCodeProvider
  • Microsoft.SharePoint.Administration.SPUserCodeService
  • Microsoft.SharePoint.Administration.SPWebService
  • Microsoft.SharePoint.UserCode.SPSolutionValidator

Each of these classes is capable of participating in a configuration-only backup because it implements IBackupRestoreConfiguration.  The list is longer than the five bullets I mentioned earlier, but many of the classes cited can be grouped into common areas of functionality.  The SPSolution, SPSolutionCollection, and SPSolutionLanguagePack types are associated with trusted solutions (the farm solution store), for example, while the SPDiagnosticsServiceBase type is tied to trace log and event throttling management (i.e., diagnostic logging).  A simple one-to-one mapping between classes and settings areas (that you might find in Central Administration) doesn’t actually exist.

Identifying what is included in a configuration-only backup isn’t quite a quick and easy affair.

What Doesn’t A Configuration-Only Backup Capture?

Sometimes it’s simply easier to talk about what a thing isn’t rather than what it is.  As you’re probably coming to see, configuration-only backup and restore is one of those things.

For those who hoped that configuration-only backup and restore would deliver us to the promised land of SharePoint farm templates and full configuration replication, the first signs of trouble in paradise come by reading the implementation notes for the IBackupRestoreConfiguration interface.  In essence they state that you shouldn’t be implementing the interface to capture configuration settings unless the following three conditions are true for the settings in question:

  1. The settings you’re trying to preserve are only configuration settings – not content like lists, documents, etc.
  2. The settings you want to capture are scoped to the entire farm or the Content Publishing Web Service (i.e., they apply equally to all non-Central Admin Web applications and the site collections contained within them – not to just a subset)
  3. The settings aren’t tied to server names or your specific SharePoint farm topology

That list starts “simple” and ends “rough.”  With those three bullets, we can instantly rule-out configuration data that is tied to individual Web applications, content databases, site collections, and everything else below them.  Configuration-only backup and restore won’t protect your per-Web application settings, either, including alternate access mappings (AAMs).

I’m making a special point of highlighting AAMs because configuration-only backup and restore was initially advertised as being capable of capturing these mappings.  Sure, you can view AAMs within Central Administration and may think that they’re maintained at the farm level, but they aren’t – they’re tied to specific Web applications.  AAMs for a Web application are represented (within the object model) as an instance of the SPAlternateUrlCollection class.  The SPAlternateUrlCollection isn’t on the list of IBackupRestoreConfiguration implementers provided earlier, nor are its parent types (most notably the SPWebApplication type through its AlternateUrls property).  Net effect: it isn’t included in configuration-only backup and restore operations.

Since cloning a SharePoint farm usually involves taking it from one environment to another, bullet #3 is a rather big sticking point, as well.  Configuration-only backup and restore won’t handle anything that includes a server name, IP address, or any other environmentally-dependent setting.  The reason is pretty simple – how would SharePoint know how to actually re-wire that stuff (in a new environment) on restore?


Okay, What About Service Applications?

The Service Application Framework is new to SharePoint 2010, and it represents a major step forward in correcting many of the performance, configuration, and scalability limits of MOSS 2007’s shared service provider (SSP) model.  If you’ve touched SharePoint 2010 in any form, chances are you’ve at least stumbled into service applications in some form.  Examples include the Managed Metadata Service, Business Data Connectivity (BCS) Services, and Search.

Although the Service Application Framework has been engineered to participate in normal (content+configuration) catastrophic backup and restore operations, it doesn’t do so through the standard IBackupRestore interface.  Developers of service application and related classes can adorn their classes with a couple of different attributes (IisWebServiceApplicationBackupBehaviorAttribute and IIsWebServiceApplicationProxyBackupBehaviorAttribute – not exactly “short and sweet” in the name department), and they get backup and restore integration as a freebie.  This is a big relief for developers, because properly implementing the IBackupRestore interface in their classes is anything but trivial.

There is a downside to the attribute-based backup and restore approach as its implemented, though: the Service Application Framework simply doesn’t participate in configuration-only backup and restore.  When you execute a configuration-only backup, you won’t capture any configuration data tied to search, BCS, managed metadata, web analytics, Excel services, or any of the other service applications.

Double ouch.

The Verdict On Configuration-Only Backup And Restore

I’ll start by apologizing if this post dashed your hopes.  Believe me when I say that I had very high hopes for configuration-only backup and restore, as well.  Cloning farms by hand is painful work; I’ve done it enough times to know that much.

Since configuration-only backup and restore doesn’t actually cover any configuration data tied to service applications and individual Web applications, cloning a farm in SharePoint 2010 is still going to be a largely manual affair.  Scripting can (and probably should) play a large role, and so will documentation.

There, I said it – the ugly “d” word.  Documentation.

Documentation continues to play a big role in capturing configuration data in SharePoint 2010, but that doesn’t mean you have to resort to taking notes or capturing screenshots en masse.

Microsoft has (indirectly) acknowledged that configuration-only backup and restore isn’t going to round up all of our desired configuration settings, and they’ve attempted to lend us a hand through some PowerShell scripting.  If you haven’t yet reviewed Microsoft’s farm documentation script on TechNet, I highly recommend that you check it out.  Saying that the script’s treatment of farm configuration data is “extensive” is kind of like saying that a tsunami is a “big wave” – it doesn’t do it justice.

I also want to be clear and say that despite the limitations I’ve described, I still think that configuration-only backup and restore is worth some serious investigation for anyone trying to do template creation, cloning, and disaster recovery work.  Given my focus on disaster recovery, for example, the ability to get a farm’s solution store backed-up in a form that can be restored easily at a later time is a huge benefit – one that would really ease the process of farm recovery in a true disaster scenario.

Additional Resources and References

  1. Book: SharePoint 2010 Disaster Recovery Guide
  2. Netcast: Todd Klindt’s Netcast 54
  3. Blog: Benjamin Athawes’ Tales from a SharePoint Farm
  4. Blog: Bill Baer’s TechNet Blog
  5. TechNet: Backup and recovery overview (SharePoint 2010)
  6. API: IBackupRestoreConfiguration
  7. API: IBackupRestore
  8. Product: Red Gate’s Reflector
  9. MSDN: What’s New: Service Application Framework
  10. TechNet: Document Farm Configuration Settings (PowerShell Script)

Author: Sean McDonough

I am a consultant for Bitstream Foundry LLC, a SharePoint solutions, services, and consulting company headquartered in Cincinnati, Ohio. My professional development background goes back to the COM and pre-COM days - as well as SharePoint (since 2004) - and I've spent a tremendous amount of time both in the plumbing (as an IT Pro) and APIs (as a developer) associated with SharePoint and SharePoint Online. In addition, I've been a Microsoft MVP (Most Valuable Professional) in the Office Apps & Services category since 2016.

31 thoughts on “Configuration-Only Backup and Restore in SharePoint 2010”

  1. Sean,

    Thanks for a really useful post! Just to be clear (I’m new to the Sharepoint Backup thing), we’re currently using Central Admin to make full backups (config + content dbs).

    To that, we need to add two things in order to have a complete backup:
    * Admin Powershell config backups
    * Backups of the 12 hive customizations,

    Is this correct?

    Thanks for your help!

  2. Dave,

    I’m glad you found the post useful. Let me address each of your questions in turn, but to be clear: configuration-only backup and restore is a SharePoint 2010-only feature. Your second bullet mentioned the “12 hive,” not the “14 hive” or “SharePoint Root” (the latter two terms indicating that you have a 2010 farm instead of a 2007 farm). I’m going to assume you meant “14 hive” and that you’re running SharePoint 2010.

    1. If you’re already doing a complete farm backup via Central Administration, you’re actually already capturing configuration data along with your content. Your two options are either “configuration-only” or “configuration + content.” You can use the backup set you’re generating with a full farm backup to do a configuration-only restore (from PowerShell — no Central Admin functionality for this), so you’re covered in that regard.

    2. “Complete backup” is sometimes a matter of opinion, and completely backing everything up depends on your environment. The full farm backup you’re running through Central Administration will cover the bulk of SharePoint-specific “stuff”: content, service applications, configuration database, Web application configuration, etc. As you noted, one thing it will not cover is “decentralized customizations;” i.e., files that are simply dumped (loosely) into the SharePoint Root/14 hive. If modifications are only made via solution packages (WSPs), then you’re okay — a configuration-only restore will bring in the farm solution store, so your trusted solution packages will be available.

    The SharePoint Root is only one item that isn’t covered by farm backups, though. You still may need to worry about SSL certificates, IIS configuration/settings, dependent external stores (BCS and/or RBS if they’re in use), assemblies that may have been manually registered in the global assembly cache (GAC), potential Registry additions (less likely), machine.config or default web.config changes in the .NET framework folders, and possibly a few other things. Whether or not each of these areas/items is in-play for you depends on your environment, how governance is handled, and how disciplined all parties were during setup and subsequent (potential) development/deployment.

    I’m really only skimming the surface. Since you’re “new to the SharePoint Backup thing” (as you put it), I’d encourage you to grab a copy of my book (recently blogged about here):

    The types of questions you’re asking are exactly the sort of thing that the book covers in-depth.

    I hope that helps, and thanks for the comment!

    – Sean

  3. Greetings Sean,

    Yes, this is exceptionally helpful. You were absolutely correct in assuming that I meant 14 hive (we just made the transition recently, still learning/remembering the differences).

    It’s helpful to know that the Full Backup + Config essentially includes the powershell command; I’ll probably backup the XML source every so often to ensure that we can read any config options, should the need arise.

    Furthermore, based upon what you suggest, we’ll definitely have to run a manual backup of some files; WSPs accounted for most of what we deployed, but not all; we had a messy time (read: registry edits, etc) to get things operating properly.

    Thanks again for your help; I’ll check out that book.


  4. Hi Sean,

    I learned a lot of useful information from this article.

    However my primary objective right now is to actually Clone our 2010 production farm into a test environment, 2 WFEs, 2 Apps, and 1 SQL server. Before reading your post I was planing on doing a full farm backup from the central admin and then restoring that onto my new servers that are setup, identical layout of the servers, just new names and such. But everything you guys are saying and I am reading tells me this won’t work. Now I just want to clarify here, is it that it won’t clone my farm perfectly, or is it that I can’t even duplicate my farm to the point of transferring all service applications and web apps? My impression was I was going to have to restore the farm via the full farm backup, then move over any customizations in the form of 14 hive, GAC solutions, and web.config. As well as modify what servers the service applications are running on.

    Basically I am looking for any sort of a guide or even a general direction to head in building a test farm that perfectly mirrors my production farm. Any help is appreciated,


    1. Hi Alex,

      I’ll start by saying that what you want to do is extremely common (i.e., clone a farm), but it’s a challenge that still doesn’t have an acceptable solution using out-of-the-box (OOTB) tools alone; even 3rd party tools will only get you partway to the goal.

      You mentioned that you’d be starting with a full farm backup. If so, you will be able to copy some farm components over in a piecemeal fashion without any issues; e.g., content databases. Other farm components will be hit-or-miss, such as pieces of/some service applications, for instance. Trying to restore an entire full-farm backup into a different environment will flat-out fail due to the fact that SharePoint configuration databases maintain environmentally specific information such as server names. There isn’t a supported way to “force” the restore and then go back and do “name fix-ups,” for instance.

      If your test farm matched your production exactly (numbers and names of servers, components installed on each server, security/AD/account info, etc.), you could conceivably restore a full farm backup from your production environment into your test environment … but you’ve already indicated that server names are different. That’s going to be a deal breaker.

      Configuration-only backup and restore, as I mentioned in the article, is only going to allow you to move a few configuration database items across to your test environment. The ability to move the farm solution store is definitely a plus provided your solutions are packaged as WSPs. If they aren’t and exist as “decentralized customizations” (Microsoft’s gentle way of saying “stuff that’s simply dumped into the file system”), then you will need to customizations over by plucking files from the SharePoint Root, GAC, web roots, etc.

      So, you have a variety of options available to you when it comes to addressing the cloning challenge, but none of them are going to be point-and-click:

      * If cloning an environment is something you see yourself doing semi-frequently, it’s worth investing some time into scripting your actual install and configuration of the SharePoint environment. You can get a healthy jumpstart on this using the AutoSPInstaller project found on CodePlex (

      * If this is a one-time affair, it may actually be more effective to simply duplicate the configuration (manually) in your test environment. If this case, a tool like the Documentation Toolkit for SharePoint from Toni Frankola and the folks at Acceleratio ( is invaluable in gathering up your production farm’s configuration and transforming that into something you can use to set up your test environment.

      * If configuration is a one-time affair but data needs to be frequently refreshed in the test environment, consider scripting out backup/restore operations of content databases, leveraging SharePoint’s content deployment mechanism, establishing SQL Server log shipping or mirroring, etc., to keep content fresh.

      Of course, the use of virtualization (running SharePoint farm members as VMs, creating VM clones, etc.) adds a different layer on top of all of these actions. There’s no single path to duplicating your production environment, but hopefully what I’ve supplied is enough to get you started.

      Good luck!

      1. Thanks for the prompt response Sean!

        I certainly hope I only need to create this test farm once ;) But we should be moving to using this test farm heavily for development testing, so keeping the content up to date will be needed.

        So I guess my plan of action will be this;
        – Have my fresh test servers setup with SharePoint installed (same version as prod), and a blank farm configured including all servers.
        – Roll out a config-only restore on the farm from the production backup.
        – Move over all non-restored files (14 Hive, web.config, etc)
        – Tediously verify and update all other configuration settings in central admin including the service applications.
        – Restore my content databases to the test sql server, then attach to web applications in sharepoint
        – Celebrate/Cry?

        Obviously each one of those bullet points is going to be very time consuming and have plenty of hiccups associated with it, but is there anything major I am forgetting or will cause me issues?

        Again thanks,


  5. It looks like you’ve got the bulk of the laundry list. If you terminate SSL on any of your WFEs, be sure to get your certificates into the cert store of each WFE in the test environment. Other checklist items (if you’ve got them implemented) might include SQL Server TDE, RBS, making sure that file paths for logging and such line-up with available drives in your test environment, etc.

    All of those are lesser concerns (or potential non-issues), but I mention them purely to illustrate some of the clean-up you might have to do with files, security, etc.

    Good luck!

  6. In SharePoint 2013, if you back up the whole farm – Configuration and Content, then restore it to a different farm such as a new test farm, will the Central Admin Backup and Restore tool work? If it does, are there anything to tweak or redo after restore? Thanks!

    1. The simple answer to your question, Sharon, is “yes.” As with all things SharePoint, though, there are more than a few caveats.

      Although SharePoint’s built-in farm-level backup and restore capability (whether accessed from Central Administration or the command line, e.g., Backup-SPFarm) will allow you to essentially capture the overwhelming majority of your farm and restore it somewhere else, you’re somewhat constrained in how that farm is restored. What I mean by that is that SharePoint is going to expect roughly the same server and service topology. You do have some flexibility in specifying accounts and what-not, but you’ll have to play with the restore capability to see if it allows you to switch what you want to switch.

      Another thing worth noting is that full-farm backup is only as “full-farm” as SharePoint is aware of something. For example, built-in full-farm backup will capture databases, Search configuration (include index files), service applications, and the other items that you see listed in the farm hierarchy when you go to back up … but it doesn’t get everything. For example, any web.config changes you made manually won’t get captured. If you’ve manually made any changes to the SharePoint Root, other parts of the file system, etc., those won’t get captured. If you don’t see something listed in the farm backup hierarchy, it’s safe to assume it won’t get captured.

      You asked if there was anything to tweak or redo, and the answer is likely “yes.” I tell people that “backup is a science, but restore is an art.” When SharePoint is restoring a farm from backup, there are a LOT of moving parts in action. Sometimes things fail and need to be retried. Sometimes they simply don’t work. Persistence tends to pay off, though.

      I hope that helps.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: