Backup - From The Field

10/1/2009

DPM and SharePoint - Part 4 - Why do I get this error?

Now that you know how DPM works with SharePoint, it’s time to delve into the much more interesting topic of troubleshooting errors thrown by DPM. This post will focus purely on SharePoint related DPM error messages and how to troubleshoot any of these errors you may see in the UI. If you are looking for guidance on generic DPM troubleshooting, please see http://technet.microsoft.com/en-us/library/bb808913.aspx or refer to the error code catalog: http://technet.microsoft.com/en-us/library/bb795681.aspx.

Where to start?

Let’s take this error message from the DPM UI and walk through the troubleshooting steps:

DPM Error

In this case we are trying to restore the /projects sub-site to the www.contoso.com site collection. The real error message amongst all the above is “DPM was unable to import the item http://www.contoso.com/projects/ to the protected farm (ID 32005 Details: The system cannot find the file specified (0x80070002))”.

OK so now what? Not very helpful is it? It looks like we are missing a file. If you read the recommended action second there are some helpful suggestions for common failure causes including missing features and language packs. But this isn’t enough for us to resolve the problem.

At this point, you have 2 options. As a DPM administrator you may prefer to check the DPM error logs on each Web front-end server (production and recovery farm). However, as a SharePoint admin you may be more familiar with the SharePoint ULS logs on the servers. Either should give you the information you need!

The DPM Log Files

First a look at the DPM error log for SharePoint recoveries. You will need to log on to the production Web front-end that is used to protect your farm (and possibly the recovery farm server if the problem is caused there). The log file you need is located in %systemdrive%\Program Files\Microsoft Data Protection Manager\DPM and is called WssCmdletsWrapperCurr.errlog.

There are a number of log files here and yep you guessed it, SharePoint has its own which is actually quite helpful. If you think back to part 2 in this series, you will remember WssCmdletsWrapper.exe. This is the application used to connect the SharePoint Object Model (managed code) to the unmanaged DPMRA service. Therefore, the WssCmdletsWrapperCurr.errlog file is where we need to look for exceptions passed from the SharePoint Object Model to DPM!

Here are the contents of the log file for the above error:

DPM Error Log

Based on this, we can see the main exception is: “The site http://www.contoso.com/projects/ could not be found in the Web application SPWebApplication Name=ContosoPortal“... and this occurs once an SPImport has been attempted. This means the data was successfully restored from the database to the recovery farm and then copied to the live Web front-end ready for import.

The job failed because it is expecting a site at the given location. But wait, isn’t that the point, aren’t we restoring the site in the first place because it was accidentally deleted?

Yes we are! However, in the above case the /projects subsite cannot be restored because its parent site collection also no longer exists and the import process is trying to import /projects into www.contoso.com as a child object.

As SharePoint administrators we are all sighing right now (yep – remember DPM uses the content migration (PRIME) API, therefore all the same caveats apply as if you were using stsadm –o import). As DPM administrators you may be a little confused, if so and you want to learn a little more about the SharePoint containment hierarchy, I suggest you take a look at: http://technet.microsoft.com/en-us/library/cc287815.aspx and if you are feeling a little braver try http://msdn.microsoft.com/en-us/library/cc768619.aspx.

The SharePoint Log Files

I mentioned previously that it is also possible to find this information from the SharePoint ULS logs. WssCmdletsWrapper.exe will write directly into the ULS logs as it interacts with the SharePoint Object Model. Therefore, if you prefer, you can use the ULS logs to determine the error instead.

To do this, log on to the production Web front-end that is used to protect the farm and open the relevant log according to the time of the recovery failure. Search for “wsscmdletswrapper.exe” and look at each entry. For the error in this example I am given entries which correspond to those in the WssCmdletsWrapperCurr.errlog file:

SharePoint Error Log

You may also see success messages from other restores. This is perfectly normal and can be used for verification purposes if you wish.

Note the message: “ULS Init Completed (WSSCmdletsWrapper.exe, onetnative.dll)” occurs at the beginning. This shows the WSSCmdletsWrapper.exe application is hooking into the ULS logging system. You should see one of these entries at the beginning of any DPM related operations. Therefore, you can use this string to filter your search for new operations and not every line from each operation.

Common Error Causes

As you have seen above, errors may be caused purely because DPM uses the SharePoint Content Migration APIs, and because restrictions on the way objects are organised within SharePoint.

A full overview of the Content Migration APIs and what cannot be exported/imported is documented here: http://msdn.microsoft.com/en-us/library/ms453426.aspx.

Other common issues were covered in part 3, but for completeness I will include the list here too. The DPM UI may not show you the message in the format given below, so it is worth noting that whatever the error message given in the DPM UI, you can use the method shown above to retrieve the full exception message and stack trace.

· Not enough space on the recovery farm temporary storage volume. This is for the initial database restore process during item level recovery.

· A site already exists at the recovery location but uses a different template to that being restored. For example, SharePoint will not allow a site created by using a Wiki Site template to be restored onto a site created by using the Team Site template.

· A sub-site, list or item is being restored to a location without a parent Site collection. You must have a parent object in place to restore any child objects.

· The recovery farm is a different version or build of SharePoint. The build must be the same since MOSS 2007 Enterprise contains features that are not available in Standard and WSS 3.0. The farm must also be patched to the same build and have the same language packs installed.

· The recovery farm does not contain all customisations that are deployed to the production farm. If an object being recovered depends on these the recovery may fail.

Stay Up To Date

It goes without saying that all software has bugs and staying up to date with the latest patches will help ensure an error free environment. Using the above method may help when there is a suspected bug, but only a Microsoft Support Case will get you a fix!

For this reason I recommend all customers ensure they have at least Service Pack 2 for WSS 3.0 and MOSS 2007 installed on both their live farm(s) and their recovery environment. If possible, the latest SharePoint cumulative updates should also be installed. (http://technet.microsoft.com/en-us/office/sharepointserver/bb735839.aspx).

You should also have Service Pack 1 for DPM installed (http://technet.microsoft.com/en-gb/dpm/dd296757.aspx) and I highly recommend that you install the latest rollup package (http://support.microsoft.com/kb/970868), which includes all fixes since SP1, including many SharePoint related fixes and dependant ones to DPM and the VSS framework. I have included the SharePoint specific ones below:

· When you restore a SharePoint site that is configured to use a host header, an incorrect SharePoint site is restored.

· Data Protection Manager 2007 cannot protect the content databases if Microsoft Office SharePoint Server 2007 Service Pack 2 is configured to connect to a content database by using a SQL Server alias. Additionally, the following error is logged:

o This Windows SharePoint Services farm cannot be protected because DPM did not find any dependent databases and search indices to be protected. (ID: 32008)

· If a Microsoft Office SharePoint Server 2007 farm is configured by using a fully qualified domain name (FQDN), consistency checks or initial replication fails with error 0x80042308:VSS Object not found.

· Restoring a Windows SharePoint Services-related content database that is detached from the server farm fails with a 0x80070003 error.

· SharePoint catalog generation fails with a "The number of WaitHandles must be less than or equal to 64" message.

· The SharePoint backup process fails if DPM 2007 cannot back up a content database. If you install this update, the SharePoint backup process will finish. However, an alert will be raised if DPM 2007 cannot back up a content database.

· If a parent backup job of a SharePoint farm fails, but the child backup succeeds, the DPM 2007 service crashes.

Posted at 2:58 AM by Chris Whitehead | Category: Backup; DPM; Restore; Troubleshooting | Permalink | Email this Post | Comments (0)

6/1/2009

DPM and SharePoint - Part 3 - How does DPM restore SharePoint data?

In part 2, I looked at how DPM protects SharePoint data. Part 3 focuses on how DPM recovers SharePoint data. I will focus on the prerequisites, components used and data flow that occurs when recovering data at various levels in a SharePoint farm.

Restoration of objects in SharePoint by using DPM can be broken into a few key recovery scenarios:

· The entire farm

· Content databases

· An SSP, its associated enterprise search data, and Windows SharePoint Services Search

· Sites, Lists and Items (everything below the content database level)

· Customisations and configuration settings outside of SharePoint databases

Restoration of data from each of these categories can involve a different process, supportability implications and prerequisites. For example, restoration of the farm configuration database and associated Central Administration content database is only supported as part of a FULL farm recovery. In this scenario all content databases must be restored to the exact same point in time also. With that in mind it is easier to discuss each of the recovery scenarios and how they work separately...

The entire farm

As already discussed above, recovery of an ENTIRE SharePoint farm is possible when using DPM. This includes the configuration and Central Administration databases. However, it is important to consider that this recovery option requires these databases, and all other databases in the farm are recovered together to the same point in time.

This is made possible because DPM uses VSS which allows for a point in time snapshot of all databases in a SharePoint farm. For this exact reason, restoration of the configuration and Central Administration databases is supported when recovering an entire farm.

Note: It is possible to select these databases for restore individually, but this is not a supported operation.

To recover an entire farm (except the search components which are covered separately), you simply select the ‘All Protected SharePoint Data’ option, followed by hitting recover on the configuration database as shown below.

Farm Recovery Screen Shot

This may not seem obvious at first but it is the correct way to restore an entire farm. By selecting the item shown above, you are really selecting the entire farm (its name is of course given by the name of the configuration database). At this point you can follow the wizard to recover the farm and all its content.

You do need to consider the 2 possible scenarios for farm recovery: the production farm is still live and the WFE used to protect it is available; the production farm is unavailable due to complete configuration database loss or corruption. Rather than repeat documentation already out there I will point you to the TechNet article that covers farm recovery in each of these scenarios: http://technet.microsoft.com/en-us/library/cc262562.aspx.

During the recovery process, DPM will recover all databases to the SQL Server instance(s) used by the farm. The DPM Agent and SQL VSS Writer are used for this process.

Content databases

Restoration of SharePoint content databases is very simple. Although backed up as part of the farm, the content databases are treated like any other SQL Server database and can be selected for restore individually. You have a few operations for restore: recover to original location; recover to alternate SQL Server instance; or copy to a network folder.

The wizard is fairly intuitive, so I won’t explain each step any further. I would however like to point out that the copy to network folder option is great and can be used to properly verify your backups and keep that all important test farm data up to date. Of course the option is less valuable when performed manually in the UI, but how about you use a PowerShell script to do this for you?! Now you can test the restore of your SharePoint content databases routinely...

$DPMServer = "DPM server name"

$pgName = "SharePoint protection group Name"

$dsName = "The DataSource name in the format WFE\config database name"

$db = "Name of database to be recovered"

$targetServer = "Target server name"

$targetPath = "C:\restore"

$pg = Get-ProtectionGroup $DPMServer | where { $_.FriendlyName -eq $pgName }

$ds = Get-Datasource $pg | where { $_.Name -eq $dsName }

$rp = Get-RecoveryPoint -Datasource $ds | where { $_.DataLocation -eq "Disk" }

$lastitem = $rp.count-1

$ri = Get-RecoverableItem -RecoverableItem $rp[$lastitem] -BrowseType child | where { $_.UserFriendlyName -eq $db }

$rop = New-RecoveryOption -TargetServer $targetServer -TargetLocation $targetPath -RecoveryLocation CopyToFolder -RecoveryType Restore -SharePoint

Recover-RecoverableItem -RecoverableItem $ri -RecoveryOption $rop

Warning: This script does not contain error handling and is based on my rather primitive PowerShell skillz J. That said you should be able to take it away and add to it. Once you have the database restored to a file share you can just run a routine SQL job or of course script out the restore to your test farm.

Note: Be sure to detach and reattach the database in SharePoint once it is restored so to update the sitemap table in the farm configuration database.

An SSP, its associated search data, and Windows SharePoint Services Search

Full support for backup and recovery of Shared Services Providers and SharePoint Search data was added in DPM 2007 SP1. Due to the intricacies and caveats of protecting and restoring this data, I have dedicated an entire post to it which is coming soon.

Sites, Lists and Items

Recovery at this level can be classed as item level recovery. In essence this is anything in the SharePoint object hierarchy that is stored within a SharePoint content database. Restoration of these items is only possible (in a supported manner) via the SharePoint Object Model. Whilst it is technically possible to extract these objects from content database and insert them into another, this may lead to corruption of the databases and related data and is therefore not supported.

The DPM product team worked with the SharePoint product team to ensure this recovery scenario could be implemented in DPM in a way fully supported by SharePoint. As such, DPM uses the SharePoint Object Model when performing item level restores.

For this to work, a ‘recovery’ farm is required and is used to temporarily host a recovered version of the content database that holds the SharePoint object you wish to recover. The object is then exported using the SharePoint Object Model and imported back into the production farm.

The following diagram explains the process in more detail:

DPM Recovery Farm Dataflow

Full details of how to create a recovery farm are available from here: http://technet.microsoft.com/en-us/library/dd180789.aspx. It is recommended that you take advantage of virtualisation technology for the recovery farm and possibly even use Hyper-V to host the recovery farm directly on the DPM server.

Be sure to read the short TechNet article referenced above as it contains a list of key points to consider, such as how to name the recovery Web application and the following requirements amongst others:

· If you protect a MOSS farm, then the recovery farm must also be MOSS.

· The features and templates installed on the recovery farm must match those of the target farm as it was at the time of backup. Any customized templates, added or modified, on the production farm, must be added to the recovery farm to ensure a successful recovery.

· The target farm must contain a site collection with the same path as the original protected site. If the site collection does not exist, you can create an empty site collection with the correct path on the target farm before you perform the recovery.

Those familiar with the stsadm export and import commands (which use the same APIs) will know that these requirements are down to caveats and limitations of the SharePoint Content Migration APIs and not DPM. They are not hard to work around but are the cause of most item level recovery failures and issues.

A full overview of the Content Migration APIs and what cannot be exported/imported is documented here: http://msdn.microsoft.com/en-us/library/ms453426.aspx.

OK, so now you know how item level recovery works let’s take a look at it in action. You can use the DPM UI to search or drill down through a content database down to the item level. As you can see below it’s as simple as navigating the SharePoint object hierarchy and selecting the item you wish to recover, be it a site collection or single document.

Item Restore Screenshot

You are able to navigate the SharePoint object hierarchy like this because DPM catalogues your farm when it creates a recovery point (see post 2), storing it locally for search and navigation during a restore.

When the wizard fires up, you get a couple of recovery choices; recover to original site or recover to an alternate site. Either way you need the recovery farm in place first. Again I won’t speak you through the whole wizard; you can refer to TechNet for that: http://technet.microsoft.com/en-us/library/bb795893.aspx (Item recovery) and http://technet.microsoft.com/en-us/library/bb795899.aspx (Site recovery).

I will however cover some of the most common mistakes which include some of those already discussed above:

· Not enough space on the recovery farm temporary storage volume. This is for the initial database restore process of item level recovery.

· A sub-site, list or item is being restored to a location without a parent Site collection. You must have a parent object in place to restore any child objects.

· The recovery farm does not contain all customisations that are deployed to the production farm. If an object being recovered depends on these the recovery may fail.

And finally a few points worth mentioning about the site/list/item recovery process and the use of a recovery farm:

· The last section of the wizard will NOT show the details of the object being restored. This is by design for SharePoint restoration.

Item Restore Wizard Screenshot

· The files created in the temporary locations on the recovery and production farms are removed with the exception of the CMP files on the recovery farm. You will have to remove these yourself. Personally I think it is good that these are left behind as you can reuse them again. The other files are removed on a best effort basis so some manual tidy up may be required if the files are still locked when an attempt is made by DPM to remove them.

· A common question asked is about licensing of the recovery farm. This is naturally a complicated topic and I’m certainly not in a place to give an authoritative answer. For that you should speak to your local licensing expert. However, I can comment on what I currently know about the topic. In summary you do need licences for all software on the recovery farm. However it may be that you qualify for ‘Cold Server Backup for Disaster Recovery’. I’m told SharePoint recovery farms used by DPM qualify under this category. Jason Buffington has a great webcast on the topic of DPM Agent licensing if you want more information specific to DPM agents. Also check out the TechNet page here: http://technet.microsoft.com/en-us/library/bb808748.aspx.

· With so many pieces to the puzzle there is a lot to go wrong. Look out for part 4 which will cover troubleshooting issues with the backup and recovery process.

Customisations and configuration settings outside of SharePoint databases

Almost all content related to SharePoint is stored in SQL Server databases. However, some customisations and configuration settings are stored on the file system of the Web front end servers in a farm. Whilst DPM does not protect these automatically, it is possible to protect and restore these customisations and configuration settings by using the file system and system state options within DPM.

You should use DPM to protect any customisations not deployed through the use of SharePoint solutions, and any configuration changes including those to web.config files and IIS configuration files. There is no need to protect folders with customisations deployed through solution packages as these will automatically be redeployed by SharePoint in the event of Web front end failure.

Posted at 12:44 PM by Chris Whitehead | Category: Backup; DPM; Restore | Permalink | Email this Post | Comments (6)

3/17/2009

DPM and SharePoint - Part 2 - How does DPM protect SharePoint data?

It’s been a while since I posted part 1 of this series where I looked at the questions you may ask when choosing a backup and recovery tool for SharePoint, and how these questions are answered from a DPM on SharePoint point of view.

In part 2, I look at how DPM really protects SharePoint data. I won’t be getting into how VSS works and how DPM copies block level differences, for that I recommend you watch this excellent webcast by Jason Buffington: http://edge.technet.com/Media/DPM-2007-SP1-How-does-DPM-really-work. I will however be going in to detail about the components required for SharePoint protection, along with how they work and the stages in setting them up.

Prerequisites

Before attempting to protect a SharePoint farm, you should ensure your DPM server is fully configured with all required updates and storage pool disks. In addition, it is important that you have SP1 for SharePoint and the post SP1 hotfix for WSS 3.0 installed (or a newer cumulative hotfix). This hotfix has a number of fixes/enhancements for the VSS writer service used by SharePoint.

VSS and the WSS Writer Service

The Windows SharePoint Services VSS Writer is the first key component used for protecting a WSS 3.0 or MOSS 2007 farm down to the item level by using DPM.

DPM works by using application specific VSS writers to protect application data. The SharePoint VSS writer is a referential writer that enables backup applications like DPM to use a single writer interface to call upon other VSS writers such as the SQL Server VSS writer.

This is crucial from a SharePoint perspective and is what allows us to protect everything in a SharePoint farm including the Configuration database and Central Administration content database. Typically we are not supported to restore these databases as there is no way to ensure their consistency with the rest of the farm.

However, with VSS and DPM we can because VSS will used the WSS Writer to freeze and snapshot all associated content at once, thus ensuring we have a consistent point in time replica of the content being protected! The VSS Writer also means we can protect an entire SharePoint farm with a single checkbox, more on this later.

This diagram gives a very high level overview of the process and why it allows us to protect all SharePoint content:

DPM DataFlow

For much more in-depth information and some nice diagrams about the SharePoint VSS Writer, and the way it works I recommend you read the following articles: http://msdn.microsoft.com/en-us/library/bb417460.aspx and http://msdn.microsoft.com/en-us/library/bb417449.aspx.

DPM Agent

As shown in the diagram, the DPM Agent is the second key piece required to protect a SharePoint farm. The agent is used for communication between the DPM server and each server hosting protected content.

The agent should be deployed on all servers that have content requiring protection. For example in a simple 5 server farm (2 WFE's, an Index Server and a 2 Node Clustered SQL Server), you would deploy the agent to the SQL Servers, the Index Server (if you want to protect Search) and ONE of the Web Front Ends.

So why not the other WFE? Well since the Web Front End servers do not host content, you only need to protect one to protect your entire farm. In fact this server is only really used to serve as an entry point for DPM to protect your farm. There is no reason why you couldn't protect the farm by deploying the agent to just the Index Server and SQL Servers. This would however mean that you couldn't grab system state and directories on the WFE that contain customisations.

Configuring the WSS Writer Service

Once you have the agents deployed to each server requiring protection, you need to let DPM know that there is a SharePoint farm requiring protection and give it permissions to access that farm. Note: The account used should be farm administrator and local administrator on the WFE.

To do this there is a utility available called ConfigureSharePoint.exe. The utility can be found in the <DPM Installation Path>\bin folder of the WFE that you have deployed the protection agent to. This utility configures the WSS Writer service and any associated services with the correct credentials required to access the farm for backup and recovery purposes. It also allows you to configure other options such as protection for search and the temp folder location (more of this in parts 5 and 6).

ConfigureSharePoint.exe

Don’t see all the options listed above? You don’t have SP1 for DPM installed and/or the agent on this machine hasn’t been updated. Pre-SP1 there was no options for this utility, it simply prompted for a username and password.

Once this operation is complete, you will notice the ‘Windows SharePoint Services VSS Writer’ Windows service is now started and set to use the credentials you specified.

More information about using ConfigureSharePoint.exe can be found here: http://technet.microsoft.com/en-us/library/dd441708.aspx.

But what about ‘stsadm –o registerwsswriter’, what’s that command for? You do not need to run this command when you use ConfigureSharePoint.exe, it does the equivalent operation on your behalf and is just used for activating the service.

Hang on, what is WSSCmdletsWrapper?

When running ConfigureSharePoint.exe we saw a reference to another utility called WSSCmdletsWrapper. We also see entries for this in the SharePoint logs when protection is up and running (more on this in part 4), so what is it?

WSSCmdletsWrapper is a DCOM application registered as a server on the WFE. It is used to connect the SharePoint Object Model (managed code) to the unmanaged DPMRA service. So basically we use ConfigureSharePoint.exe to give the WSSCmdletsWrapper process access to the SharePoint farm via the SharePoint Object Model. This then passes information to the DPM replication agent (DPMRA) service. This process is used for all jobs requiring access to the SharePoint farm.

Creating a Protection Group

Now we have a high level understanding of how DPM works with SharePoint under the hood, let’s look at how you actually protect SharePoint from the DPM UI.

Once you have run ConfigureSharePoint.exe from the WFE being used to interface with DPM, the SharePoint farm will appear in the UI when creating a protection group using the wizard. As shown below, when protecting a SharePoint farm, you only need protect it with a single check-box in the UI via this WFE. The farm is displayed in the name format: ‘Server\ConfigDBName’.

ProtectionGroup

If you have not properly run ConfigureSharePoint.exe and registered the WSSCmdletsWrapper DCOM application, then the SharePoint farm seen in the UI above will not appear. To rectify this re-run the utility.

In the example above, you will also notice 2 other items. The SPSearchComponent and the SSPComponent. These are shown because I ran ConfigureSharePoint.exe with the ‘EnableSPSearchProtection’ parameter that is now included in DPM SP1. More on this in part 6 – What about Search?

Once you have specified your protection goals, configured any other settings and created the initial replica, DPM will be protecting your SharePoint farm according to your schedule! It’s that easy.

Note: DPM protects SharePoint by using Express Full backups only, for a complete explanation of this and the process under the hood, see the following webcast: http://edge.technet.com/Media/DPM-2007-SP1-How-does-DPM-really-work.

In part 3, I look at how DPM restores SharePoint data at the various levels available, from the entire farm down to a single item. As part of this I will look at how to create a recovery farm for item level recovery, why it is required and the caveats you should be aware of.

Posted at 2:25 AM by Chris Whitehead | Category: DPM; Backup; Restore | Permalink | Email this Post | Comments (2)

3/5/2009

Two important KB articles released recently relating to backup and restore

Two important KB articles have been released recently that relate to the important topic of backup and recovery.

Stsadm can inadvertently delete a root site collection if erroneous URL path used - http://support.microsoft.com/default.aspx/kb/968474

After using stsadm -o restore with the -overwrite parameter and getting an error you notice a site one level up from the site you were trying to restore is deleted. The root level site http://servername is deleted. The site that you were attempting to restore was http://servername/sites/sitename

This can happen if you pass an invalid URL to the stsadm –o restore command, for example http://servername/site/sitename instead of the correct URL of http://servername/sites/sitename

Microsoft Office SharePoint Server 2007 unsupported scenarios using stsadm -o export /import of subsites - http://support.microsoft.com/kb/968483

In basic terms you cannot use stsadm –o import to restore a sub-site to a root site collection if the publishing feature is enabled, this procedure is generally used to re-organize content.

The supported method to achieve this is to restore the sub-site to a sub-site within a site collection that has the publishing feature enabled and then copy across any master pages or page layouts that the sub-site relies on to the destination site collection.

Posted at 5:45 AM by Brendan Griffin | Category: Backup; Restore; stsadm | Permalink | Email this Post | Comments (0)

3/17/2008

STSADM Catastrophic Backups Failing

I recently came across an issue with a customer with their nightly stsadm farm (Catastrophic) backups which were failing.

They were using the following stsadm command to create the backups -

stsadm -o backup

-directory <UNC path or local drive>

-backupmethod <full or differential>

[-item] <created path from tree>

[-percentage] <integer between 1 and 100>

[-backupthreads] <integer between 1 and 10>

[-showtree]

[-quiet]

I took a look at the backup log file that is generated during the backup (spbackup.log) and found that the backups were backing up all components successfully but were pausing at the Index backup step for 3600 seconds (1 Hour).

I took a look in the Application Event Log and found the following entry, this occurred prior to the backups initially starting to fail.

A master merge cannot be started for catalog AnchorProject due to error The file exists. 0x80070050

To resolve the issue I launched the SSP Administration site (the customer had a single SSP) selected Search Settings, I then went into Search Settings.

Within Search Settings there is an option to Reset All Crawled Content, I selected this, and once the Index had been reset I performed a manual Full Crawl.

WARNING: Resetting the Index will delete the Index and end users will not be able to search content until a Full crawl has been performed, depending on the amount of data to be indexed this could take a significant amount of time.

I them ran a stsadm catastrophic backup which successfully backed up all components – including the Index J

Posted at 5:20 AM by EUROPE\brendg | Category: Troubleshooting; Backup; stsadm | Permalink | Email this Post | Comments (0)