334 CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs Backing Up and Restoring Service Applications The new service application architecture not only provides new and compelling scenarios previously not possible under Offi ce SharePoint Server 2007’s SSP design, but also introduces new services, some with databases associated, that must be considered when planning your overall backup and restore strategies. Fortunately, SharePoint 2010’s native backup and restore capabilities enable both backup and restore of individual service applications, with their respective content where applicable, and backup and restore of only their unique confi guration settings. Backing Up and Restoring Service Applications with Windows PowerShell To back up a service application using Windows PowerShell, enter the following command in the Microsoft SharePoint 2010 Management Shell: Backup-SPFarm -Directory < Backup folder > -BackupMethod {Full | Differential} -Item < Service application name > [-Verbose] To perform a restore, use this command: Restore-SPFarm -Directory < Backup folder > -Item < Service application name > -RecoveryMethod Overwrite [ -BackupId < GUID >] [-Verbose] To specify which backup to use, use the BackupId parameter. You can view the backups for the farm by entering the following cmdlet from the SharePoint Management Shell: Get-SPBackupHistory -Directory < Backup folder > -ShowBackup If you do not specify the BackupId, the most recent backup will be used. You cannot restore a service application from a confi guration-only backup. Backing Up and Restoring Service Applications with Central Administration Follow these steps to back up a service application using Central Administration: 1. From the Central Administration home page, select Backup and Restore Perform a backup. 2. First you will choose which service application you want to back up. As with backing up content databases above, you can back up one, or all, but nothing in between. Click a service application to back up and click Next. 3. Next you can choose a full or differential backup. If you’re not sure which you want, or if you haven’t done a full backup yet, select full. 4. Enter a UNC path for the backup location and click Start Backup. Disaster Recovery 335 Of course backups are only part of the solution. Let’s walk through restoring a service application from Central Adminstration. 1. From the home page in Central Administration, select Backup and Restore Restore from a backup. 2. When doing a restore, the first thing you need to do is choose which backup you want to restore from. Verify the backup location is correct, then choose the backup job that contains the service application backup you want to restore. When you have the correct one selected, click Next. 3. After Central Admin churns on your backup for a minute you’ll get a page showing you which objects you can restore from this backup. Choose the server application or applica- tions you want to restore and click Next. 4. The next page asks a very important question: do you want to restore this service application as a new service application, or overwrite the old one? If you choose to restore it as a new configuration you’ll need to specify a service account password and a service name. Click Same Configuration and click OK to the warning box. 5. Click Start Restore. Now that you’ve given SharePoint its marching orders it will fire off a Timer Job and start restoring your service application. Backing Up and Restoring a Farm A farm backup is useful when you would like to recover all elements of a server farm back to the same overall topology in addition to preserving the original farm’s content and configuration. As a result, a full backup should only be considered in scenarios with extended RPO and RTO objectives due to the lengthy downtime required to effectively bring the service online on standby hardware. Most large organizations with complex topologies will elect to leverage more granular protection options that provide a warm standby solution, such as SQL Server Log Shipping, rather than imple- ment a solution based on backup and restore. Some of the limitations when performing a farm-level backup and restore include the following: The farm where the restore will be performed must have the same topology as the original source farm. You cannot downgrade or upgrade topologies with farm backup and restore; for example, a multi-server farm backup cannot be restored to a single-server farm, and vice versa. Farm backups cannot be restored to other product versions, such as SharePoint Server 2007. A recovery farm should not be considered to be adequate protection unless specific RTO and RPO objectives allow for such a scenario. Warm standby solutions are always preferable in disaster-recovery scenarios. In multiple-server topologies, the backup directory must be a common share that all servers in the topology can write to and read from, and all accounts in the farm should have ade- quate access to that common share. 336 CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs Backing Up and Restoring a Farm with Windows PowerShell To perform a farm backup using Windows PowerShell, enter the following command in the Microsoft SharePoint 2010 Management Shell: Backup-SPFarm -Directory < Backup folder > -BackupMethod {Full | Differential} [ -Verbose] If an error occurs during the backup, you can view the spbackup.log fi le created in the backup directory. As a best practice, you should always use the Verbose switch to monitor the operation and its status. For farms that have not been previously backed up, you must use the -Full switch. To perform a farm restore, enter the following command: Restore-SPFarm -Directory <Backup folder> -RestoreMethod {New | Overwrite} [ -Verbose] As with a farm backup, if an error occurs during the restore, you can view the spbackup.log fi le created in the backup directory. As a best practice, you should always use the Verbose switch to monitor the operation and its status. When using Backup-SPFarm or Restore-SPFarm, you should verify that you are a member of the SharePoint_Shell_Access role on the confi guration database, and a member of the WSS_ADMIN_WPG local group on the computer where SharePoint 2010 is installed. Backing Up and Restoring a Farm with Central Administration Backing up your SharePoint farm in SharePoint 2010 is much the same as it was in SharePoint 2007, but in the interest of being thorough, let’s go ahead and walk through the steps: 1. In Central Administration click Backup and Restore. 2. Click Perform a Backup at the top of the page. 3. On the next page click Farm under Components to back up. The entire list of options should then be selected and highlighted. Click Next. 4. Select a Full backup unless you have already done a full backup; in that case you can choose Differential. Leave the radio button next to Back up content and confi guration settings checked. Type a UNC path in for the backup location and click Start Backup. SharePoint will now kick off a timer job to back up your farm. You can view its progress on the backup job status page that shows up after the backup starts. Disaster Recovery 337 Backing Up and Restoring Confi guration Settings In Offi ce SharePoint Server 2007, a limitation of the Backup/Restore feature was that farmwide con- fi guration settings and information could not be backed up and restored to another server farm. In SharePoint 2010, you can back up and restore only the confi guration settings that apply to a specifi c component. This capability to seamlessly back up and restore confi guration settings provides robust support for scenarios such as hardware migrations, replicating settings to preproduction or develop- ment environments, or facilitating the rapid build and deployment of production environments that share common settings and topologies. When performing a complete server farm backup in SharePoint 2010, the confi guration database is included; however, it cannot be restored. There are several challenges associated with restoring the confi guration database — most notably, the confi guration database stores server names and topology information. Therefore, when the restore operation is taking place on a new farm, there is uncer- tainty about how that information should be treated. The new farm will likely have different machine names and possibly a new topology. The new “confi guration only” backup capabilities mitigate these constraints, enabling you to restore the confi guration database settings that are not affected by these unique properties. The confi gura- tion only backup extracts and backs up confi guration settings from any confi guration database, including the current farm’s confi guration database, the confi guration database on another farm, or a confi guration database that is not associated with any farm. Backing Up and Restoring Confi guration Settings with Windows PowerShell To back up confi guration settings using Windows PowerShell, enter the following cmdlet in the Microsoft SharePoint 2010 Management Shell: Backup-SPConfigurationDatabase -Directory < Backup folder > -DatabaseServer < Database server name > -DatabaseName < Database name > -DatabaseCredentials < PowerShell Credential Object > [-Verbose] In order to successfully back up confi guration with Windows PowerShell, you should be logged on with an account with the db_backupoperator fi xed data- base role on the database server where the confi guration database is stored; oth- erwise, you must specify the value for the DatabaseCredentials parameter. To restore confi guration settings with Windows PowerShell, enter the following cmdlet: Restore-SPFarm -Directory < Backup folder > -RestoreMethod Overwrite -ConfigurationOnly [-Verbose] 338 CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs Backing Up and Restoring Configuration Settings with Central Administration Doing a Configuration only backup in Central Administration is nearly identical to the farm backup shown earlier in this chapter. The steps are the same, but to do a configuration only backup, select Back up only configuration settings in step 4, instead of leaving the Data to back up at the default value. See Figure 12-19. FIGURE 1219 This backup will go very quickly: don’t blink or you’ll miss it. The steps to perform a restore of configuration settings nearly mirror the earlier steps for doing a farm recovery with content. Select the Restore from a backup option in Central Administration and choose the configuration only backup you just did. You can choose to restore the entire farm configuration, or the configuration of certain components. Once you’ve chosen which configuration you want to restore, click Next. You’re greeted with a familiar page asking if you want this restored as a new configuration or the same one. If you are restoring a farm with new computer names, web applications, or SQL servers, click New configuration, as in Figure 12-20, and click Start Restore. Disaster Recovery 339 FIGURE 1220 Customizations Just because you have all of your content doesn’t mean you have everything covered. A lot of work goes into making that pretty SharePoint page, and you have to make sure you get every last bit of supporting material. Customizations are a big part of that. Customizations can be the most challenging piece of any recovery planning due to the dynamic nature of customizations in terms of life cycle, purpose, and location on a server. For example, with SharePoint, customizations commonly include the following: Assemblies deployed to the global assembly cache (GAC) Feature or site definition XML manifests Master pages, page layouts, and cascading style sheets (these objects are typically content database contained) Web Parts, site or list definitions, custom columns, new content types, custom fields, custom actions, etc. Coded workflow 340 CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs iFilters and corresponding Registry modifi cations Third-party solutions Resource fi les (. resx) The most appropriate and seamless method of containing and managing the recovery of customiza- tions is to leverage the capabilities provided by the development environment, such as Visual Studio Team Foundation, by which the developer or developers can maintain both the deployed build and version tree in a centrally managed system, in addition to any corresponding documentation. Using the native development environment, the development team can align its high-availability and disaster- recovery solutions with those tied to the SharePoint deployment, while mitigating the administrator’s need to document and protect customizations separately. Customizations that fall outside of the scope of those that are self-contained within the development environment include the SharePoint 14 “hive” ( %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14) , inetpub (%WINDIR%\Assembly), and the global assembly cache. These cus- tomizations should be protected through fi le system backup and documented accordingly, to include changes made to Web.Config manually outside of the object model. IIS 7 Like customizations, there are a lot of SharePoint nuggets hidden in IIS, so it should be part of your backup plan too. The process of backing up and restoring a confi guration has been made more convenient to administrators by adding command-line support through AppCmd.exe. You can use AppCmd.exe with the add backup, restore backup, and delete backup parameters to perform a full backup of the \ windows\system32\inetsrv\config directory and subdirectories. In addition to simplifying the process by which administrators can back up and restore IIS 7 confi gura- tion, IIS also includes a new feature that captures confi guration history. With this new capability, IIS will automatically create history snapshots of ApplicationHost.config when a change is detected, which enables you to easily restore to a prior version. By default, IIS checks for a new version every 120 seconds and retains 10 prior versions of the fi le, which are stored in the %systemdrive%\inetpub\history folder. You can change any of these settings by editing the <system.applicationHost/configHistory> section in ApplicationHost.config. While IIS 7 enables you to perform backup and restore of confi guration set- tings, it is not recommended to use the restore function with SharePoint 2010. These confi guration settings should be used only for documentation and sup- port-related issues when necessary, not as a recovery solution. Warm Standby Solutions Cold standby solutions such as backup and restore account for only a small percentage of a business continuity management plan. In addition to those solutions, you should evaluate the available technologies and capabilities of warm standby solutions that enable recovery of a SharePoint 2010 High Availability 341 deployment with minimal disruption in the event of a disaster or major failure in the primary site. Warm standby solutions provide a second copy of the data that can be leveraged in a secondary data center if necessary. HIGH AVAILABILITY High availability is the implementation of a system to ensure a certain degree of operational conti- nuity during a given measurement period, typically defined by service-level agreements (SLAs), and can encompass the entirety of a solution or just a portion thereof. Service-level agreements are a form of contractual agreement whereby the level of service is for- mally defined, and they can include both performance and delivery time. For example, a guarantee of 99.9% system availability may be a facet of a service-level agreement. Service-level agreements are commonly mapped to operational-level agreements, which define internal support relation- ships, such as those defined between two services — for example, infrastructure and the consuming application. SharePoint 2010 offers new high-availability scenarios that provide capabilities to mitigate downtime, promote redundancy, increase resiliency, and drive a highly scalable architecture. Among these improvements are a new service application architecture, native support for SQL Server database mirroring, and improvements to the methods by which costly operations such as large list querying and site collection deletion are handled. Load Balancing Load balancing can be a combination of software- and hardware-based solutions designed to distrib- ute workload evenly across two or more computers, such as two front-end web, query, or indexing servers in a SharePoint 2010 topology. The decision to leverage a software or hardware load-balanced solution is determined by the capabilities and scale you require to meet your objectives. These can include compliance requirements, geographic needs, and overall scale and performance in addition to manageability. SQL Server Database Mirroring SQL Server database mirroring is becoming a popular option not only to provide a highly resilient and performance-oriented data replication solution, but also to move toward commodity storage servers and inexpensive direct-access storage (DAS). SQL Server database mirroring can serve as either a high-availability solution or a disaster-recovery solution, but it cannot be both. SQL Server database mirroring works by maintaining two copies of a single database on separate SQL Server instances. In a database mirroring session, one database, the principal, serves the database to clients; while the other, the mirror, provides a hot or warm standby server. Whether a database is a hot standby or a warm standby is dictated by the operating mode of the mirroring session: Synchronous — In a synchronous database mirroring configuration, database mirroring provides a hot standby solution that provides rapid failover without data loss (committed transactions). This is accomplished because each transaction must be acknowledged by the . and Restoring a Farm with Central Administration Backing up your SharePoint farm in SharePoint 2010 is much the same as it was in SharePoint 2007, but in the interest of being thorough, let’s. you are a member of the SharePoint_ Shell_Access role on the confi guration database, and a member of the WSS_ADMIN_WPG local group on the computer where SharePoint 2010 is installed. Backing. contained) Web Parts, site or list definitions, custom columns, new content types, custom fields, custom actions, etc. Coded workflow 340 CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high