Here we are again, and this time it is the series finale on SharePoint business continuity planning. In the first two parts of the series, we got our fist around Recovery Time Objective (RTO), Recovery Point Objective (RPO), and Recovery Level Objective (RLO). Within these objectives we identified cold, warm and hot redundant servers and the cost of implementation. All our discussions centered around two points, namely identifying and defining your SharePoint business requirement, and identifying and choosing what to recover. In this last part we will look at three more items, namely:

  • A. Identify and choose the tools to be used.
  • B. Identify and define the strategies to be used.
  • C. Test-run your entire plan at least once a year.

IDENTIFY AND CHOOSE THE TOOLS TO BE USED

The first tool I am going to recommend is the web-based SharePoint Central Administration. The next is cmdlet commands in Windows PowerShell. In previous versions of SharePoint we called it STSADM. There is also SharePoint Designer. Microsoft also has System Center Data Protection Manager (DPM), which is very powerful. The last set of tools is any third party tools such as Axceler’s ControlPoint, AvePoint’s DocAve, EMC’s Networker, Idera SharePoint Backup, Metalogix’s Selective Restore Manager, and numerous others. All you have to do is opt into the trial program of the company offering the product, evaluate as many products as you possibly can and make your buying decision. Be aware that from a sales and marketing standpoint you will be bombarded with calls, emails and webinars to test the product, and if you don’t know precisely what you want, you will buy from the team that gave you no breathing space. Test your products for ease of use, complexity, efficiency, effectiveness, failover, error reporting (if it is user friendly, or it is all verbose logging), infrastructure required to set it up, and several other factors, including but not limited to after-sales support and what to do when the product fails. It is for this last reason I am going to stay with Central Administration and PowerShell.

IDENTIFY AND DEFINE THE STRATEGIES TO BE USED

On this side of things, let’s start by “identifying,” and it is important to bring to light at this time “customizations.” This is the next thing that always happens to SharePoint after it has been deployed. Every SharePoint farm looks simple, nearly the same, everyone is smiling, and in some instances, complaining. The most miserable person usually is the agile administrator who always has to remember everything or consult a manual he wrote (if he did). Mostly, he is hardly ever finished reading the manual before he begins to remember what he put in there. Customizations have to be backed up. The following kinds of customizations can be made to sites:

Customizations packaged as solutions (.wsp files). These solutions contain site elements that have been developed and are typically created by SharePoint developers (internal team, consultant, or even from 3rd part tools bought). These elements include the following:
  • * Web parts
  • * Workflows
  • * Site and list definitions
  • * Document converters
  • * Event receivers
  • * Timer jobs
  • * Assemblies
Authored site elements, which are typically created by SharePoint Web designers, are not explicitly compiled and they reside in a content database. They include the following:
  • * Master pages
  • * Cascading style sheets
  • * Forms
  • * Layout pages
  • * Changes to the Web.config file
  • * Third-party solutions and their associated binary files and registry keys, such as IFilters
  • * Changes to sites created by direct editing through the browser
  • * Developed customizations that are not packaged as solutions

Each of these kinds of customizations requires a different type of backup, otherwise if something goes wrong and you do a restore you will end up with Frankenstein farm, where nothing works the way it used to.

So I have identified what needs to be backed up, and here is the strategy to be used:

  • * Backing up solution packages
  • * Backing up authored site elements
  • * Backing up workflows
  • * Backing up changes to the Web.config file
  • * Backing up third-party products
  • * Backing up developed customizations that are not packaged as solutions
  • * Finally backing up the entire farm

1. Backing up Solution Packages

Solution packages can be created by using SharePoint Designer or Visual Studio. Microsoft strongly recommends that all customizations be deployed as solution packages. Solution packages are deployable, reusable, can contain a set of features, site definitions and assemblies that apply to sites, and you can enable or disable individually as you require. They 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 you use to back up solution packages is determined by whether the customizations are deployed as:

Trusted solutions – where trusted solutions are solution packages that farm administrators deploy to the entire farm and can be used on any site within the farm. When deployed they are stored in the configuration database. This makes them easy to backup because they are backed up when a farm is backed up by using SharePoint server backup, and is included in configuration-only backups. You can also back them up as a group or individually because they are visible in the backup hierarchy.

Sandboxed solutions – are solution packages that site collection administrators can deploy to a single site collection. They are stored in the content database that is associated with the site collection to which the solution packages are deployed. They are included in the SharePoint server 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.

In order to be safe and not sorry, you should 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 do the backup via Central Administration

  1. In Central Administration on the Home page in the Backup and Restore section, click Perform a backup.
  2. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select Solutions, and then clickNext.

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

  3. On the Start Backup — Step 2 of 2: Select Backup Options page, in theBackup Typesection, select eitherFullorDifferential. If you are backing up the solution for the first time, you must use the Full option. You must perform a full back-up before you can perform a differential backup.
  4. In the Backup File Locationsection, type the Universal Naming Convention (UNC) path of the backup folder, and then click Start Backup.

    You can view the general status of all backup jobs at the top of the Backup and Restore Job Status page in theReadinesssection. You can view the status of the current backup job in the lower part of the page in the Backupsection. The status page updates every 30 seconds automatically. You can manually update the status details by clickingRefresh.Backup and recovery are Timer service jobs. 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 four. Expect some of those failure messages.

    This method of backup looks easy, but the best way is through PowerShell. It is shorter, faster, and is more concise. You will see no error messages, except the syntax error.

To do the backup via PowerShell

  1. On theStart menu, clickAll Programs.
  2. Click Microsoft SharePoint 2010 Products.
  3. ClickSharePoint 2010 Management Shell.
  4. 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.

2. 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. So this will be covered in the farm configuration backup.

3. Backing up Workflows

This is a slightly tricky part, and cannot be addressed with the command line The following scenarios are to be carefully considered:

  • A. Declarative workflows, such as those created in SharePoint Designer 2010, are stored in the content database for the site collection to which they are deployed. Backing up the content database protects these workflows.
  • B. Custom declarative workflow actions have components spread 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 SharePoint Server features such as Web parts and event receivers, these files should be reapplied to the farm as needed after recovery.

  • C. 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 SharePoint 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.
  • D. 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.
  • E. 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 SharePoint Server farm, make sure that you back up the folder where you store the workflow project files by a file system backup application.
4. Backing up Changes to the Web.config File

A common customization to SharePoint Server 2010 is to change the Web.config file. Microsoft strongly recommends that changes to the Web.config file be done by using Central Administration or the SharePoint 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 SharePoint Server 2010 APIs and object model should be protected by using a file system backup, and you should be careful of applying updates if you are in the habit of manually editing the file directly, because updates have a way of resetting the config file back to its default, but when done through the Central Administration, it auto-keeps the previous versions by suffixing the filename with a datetime.

5. Backing up Third-Party Products

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

6. Backing up Developed Customizations that are not Packaged as Solutions
  1. This can be a complex process because the customization file locations might not be stored in standardized places and the SharePoint Server does not automatically back them up. You will need to consult with the development team or customization vendor to determine whether the customizations involve additional add-in software or files in other locations. This is common and you should be wary of this during the handover of any solution to you by a customization vendor. A file system backup of the directories where the vendor keeps these files is the solution. Common locations where developed customizations are typically stored on Web servers include:
Location Description
%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14 Commonly updated files, custom assemblies, custom templates, custom site definitions
Inetpub Location of IIS virtual directories
%WINDIR%\Assembly Global assembly cache (GAC): a protected operating system location where the Microsoft .NET Framework code assemblies are installed to provide full system access
7. Finally Backing up the Entire Farm – Configuration Only.
  1. You can use Central Administration to back up the configuration of the farm that Central Administration is running on. To back up the configuration of a remote farm, you must use the Central Administration website that is running on the remote farm. You cannot use Central Administration to back up an unattached configuration database.

To backup a farm configuration by using Central Administration

  1. On the Central Administration Home page in theBackup and Restoresection clickPerform a backup.
  2. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the farm from the list of components, and then clickNext.
  3. On the Start Backup — Step 2 of 2: Select Backup Options page, in the

    Backup Typesection, selectFull.
  4. In theBackup Only Configuration Settingssection, select theBackup only configuration settingsoption.
  5. In theBackup File Locationsection, type the Universal Naming Convention (UNC) path of the backup folder, and then clickStart Backup

To backup a farm configuration by using PowerShell

  1. On theStart menu, clickAll Programs.
  2. ClickMicrosoft SharePoint 2010 Products
  3. Click SharePoint 2010 Management Shell
  4. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:
    Backup-SPConfigurationDatabase -Directory <BackupFolder> -DatabaseServer <DatabaseServerName> -DatabaseName <DatabaseName> -DatabaseCredentials <WindowsPowerShellCredentialObject> [-Verbose]

Where:

  • * <BackupFolder> is the path to the folder with the correct backup files.
  • * <DatabaseServerName> is the name of the database server for the farm that you are backing up.
  • * <DatabaseName> is the name of the farm configuration database.
  • * If you are not logged on with an account with db_backupoperator fixed database role on the database server where the configuration database is stored, you must specify the value for DatabaseCredentials parameter.
8. Finally Backing up the Entire Farm – Content and Configuration by Using Central Administration
  1. In Central Administration, on the Home page, in the Backup and Restore section, click Perform a backup.
  2. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the farm from the list of components, and then click Next.
  3. On the Start Backup — Step 2 of 2: Select Backup Options page, in the Backup Type section, select either Full or Differential.
  4. In the Back Up Only Configuration Settings section, click Back up content and configuration settings.
  5. In the Backup File Location section, type the UNC path of the backup folder, and then click Start Backup.

Finally Backing up the Entire Farm – Content and Configuration by Using PowerShell

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2010 Products.
  3. Click SharePoint 2010 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} [-Verbose]

    Where <BackUpFolder> is the path of a folder on the local computer or the network in which you want to store the backups.

Finally Backing up the Entire Farm – Content and Configuration by Using SQL Server Tools

If you want to back up the complete farm, you must use either Windows PowerShell or Central Administration. You cannot back up the complete farm by using the SQL Server tools alone because you cannot use the tools to back up the farm’s configuration like we have done above. However, you can back up all the databases that are associated with the farm.

  1. To use SQL Server tools to back up SharePoint Server 2010 databases, the account that is used to back up the databases must be a member of the SQL Server db_backupoperator fixed database role on the database server where each database is stored.
  2. Open SQL Server Management Studio and connect to the database server.
  3. In Object Explorer, expand Databases.
  4. Right-click the database that you want to back up, point to Tasks, and then click Back Up.
  5. In the Backup Database dialog box, in the Source area, select the kind of backup that you want to perform from the Backup type list.
  6. In the Backup component area, click Database. Either use the default name provided or specify a name for the backup set in the Name text box.
  7. Specify the expiration date for the backup set. This date determines how long, or when, the backup set can be overwritten by any later backups that have the same name. By default, the backup set is set to never expire (0 days).
  8. In the Destination area, specify where you want to store the backup.
  9. Click OK to back up the database.
  10. Repeat steps 1-10 for each farm database.

Voila! Here is the end of the BCP series. Thank you for reading.