Back up customizations (Search Server 2010)

Backing up solution packages

Solution packages can be created by using Microsoft SharePoint Designer 2010 or Microsoft Visual Studio 2010. We strongly recommend that all customizations be deployed as solution packages.

A solution package is a deployable, reusable file that can contain a set of Features, site definitions, and assemblies that apply to sites, and that you can enable or disable individually. Solution packages can include Web Parts, site or list definitions, custom columns, new content types, custom fields, custom actions, coded workflows, or workflow activities and conditions.

The method that you use to back up solution packages is determined by whether the customizations are deployed as trusted solutions or sandboxed solutions.

Trusted solutions are solution packages that farm administrators deploy. Trusted solutions are deployed to the entire farm and can be used on any site within the farm. Trusted solutions are stored in the configuration database. Trusted solutions are backed up when a farm is backed up by using Search Server 2010 backup, and are included in configuration-only backups. You can also back up trusted solutions as a group or individually. Trusted solutions are visible in the backup hierarchy.

Sandboxed solutions are solution packages that site collection administrators can deploy to a single site collection. Sandboxed solutions are stored in the content database that is associated with the site collection to which the solution packages are deployed. They are included in Search Server 2010 farm, Web application, content database, and site collection backups, but are not visible in the backup hierarchy and cannot be selected or backed up individually.

We recommend that you keep a backup of the original .wsp file as well as the source code used to build the .wsp file for both trusted solutions and sandboxed solutions.

To back up trusted solutions by using Central Administration

1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

2. In Central Administration, on the Home page, in the Backup and Restore section, click Perform a backup.

3. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select Solutions, and then click Next.

   You can also select an individual solution, if you only want to back up a single solution.

4. On the Start Backup — Step 2 of 2: Select Backup Options page, in the Backup Type section, select either Full or Differential.

   Nota

   If you are backing up the solution for the first time, you must use the Full option. You must perform a full backup before you can perform a differential backup.

5. In the Backup File Location section, type the Universal Naming Convention (UNC) path of the backup folder, and then click Start Backup.

6. You can view the general status of all backup jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status of the current backup job in the lower part of the page in the Backup section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the backup to start.

   If you receive any errors, review the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Spbackup.log file at the UNC path that you specified in step 4.

To back up trusted solutions by using Windows PowerShell

1. Verify that you meet the following minimum requirements: Consulte Add-SPShellAdmin.

2. On the Start menu, click All Programs.

3. Click Microsoft SharePoint 2010 Products.

4. Click SharePoint 2010 Management Shell.

5. At the Windows PowerShell command prompt, type the following command to back up all of the solutions in the farm. To back up a single solution, add the name of the solution to the item path "farm\solutions".

   Backup-SPFarm -backupmethod full -directory <UNC location> -item "farm\solutions" 
   

   Where:

   • <UNC location> is UNC location of the directory that you want to back up to.

For more information, see Backup-SPFarm.

Backing up authored site elements

You cannot back up only authored site elements. Instead, you must back up the farm, Web application, or content database with which the authored site element is associated. For more information about these methods of backing up, see Related content.

Backing up workflows

Workflows are a special case of customizations that you can back up. Make sure that your backup and recovery plan addresses any of the following scenarios that apply to your environment:

• Declarative workflows, such as those created in Microsoft SharePoint Designer 2010, are stored in the content database for the site collection to which they are they are deployed. Backing up the content database protects these workflows.

• Custom declarative workflow actions have components in the following three locations:

  1. The Visual Studio 2010 assemblies for the actions are stored in the global assembly cache (GAC).

  2. The XML definition files (.ACTIONS files) are stored in the 14\TEMPLATE\<LCID>\Workflow directory.

  3. An XML entry to mark the action as an authorized type is stored in the Web.config file for the Web applications in which it is used.

  If the farm workflows use custom actions, you should use a file backup system to protect these files and XML entries. Similar to Search Server features such as Web Parts and event receivers, these files should be reapplied to the farm as needed after recovery.

• Workflows that depend on custom code, such as those that are created by using Visual Studio 2010, are stored in two locations. The Visual Studio 2010 assemblies for the workflow are stored in the GAC, and the XML definition files are stored in the Features directory. This is the same as other types of Search Server features such as Web Parts and event receivers. If the workflow was installed as part of a solution package, backing up the farm, Web application, content database, or site collection protects these workflows.

• If you create a custom workflow that interacts with a site collection other than the one where the workflow is deployed, you must back up both site collections to protect the workflow. This includes workflows that write to a history list or other custom list in another site collection. Performing a farm backup is sufficient to back up all site collections in the farm and all workflows that are associated with them.

• Workflows that are not yet deployed must be backed up and restored separately. When you are developing a new workflow but have not yet deployed it to the Search Server farm, make sure that you back up the folder where you store the workflow project files by a file system backup application.

Backing up changes to the Web.config file

A common customization to Search Server 2010 is to change the Web.config file. We strongly recommend that you make changes to the Web.config file by using Central Administration or the Search Server 2010 APIs and object model. Because these changes are stored in the configuration database, they can be recovered from a farm or configuration-only backup.

Changes to the Web.config file that are not made by using Central Administration or the Search Server 2010 APIs and object model should be protected by using a file system backup.

Backing up third-party products

If third-party products are deployed as solution packages, they are protected by Search Server 2010 backup. We recommend that you keep all the original files, distribution media, documentation, and the license and product keys that are required for installation.

Backing up changes made by direct editing

Changes made directly to a site by directly editing through the browser can be difficult to back up. The following table describes backup strategies for specific objects.

Backing up developed customizations that are not packaged as solutions

Backing up developed customizations that are not deployed as solution packages can be a complex process because the customization file locations might not be stored in standardized places and Search Server 2010 does not automatically back them up.

Consult with the development team or customization vendor to determine whether the customizations involve additional add-in software or files in other locations. We recommend that you back up these directories with a file system backup solution. The following table lists locations where developed customizations are typically stored on Web servers.

Related content