Thủ thuật Sharepoint 2010 part 51 ppsx

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 1219
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 1220
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