WHITE PAPER: ENTERPRISE SECURITY Data Protection for...

WH

IT

E P

AP

ER

: E

NT

ER

PR

IS

E S

EC

UR

IT

Y

Symantec Backup Exec™ 11d

for Windows® Servers

Data Protection for Microsoft®

SharePoint® Portal Server 2003

Using the Agent for Microsoft

SharePoint Portal Server

Contents

Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Product highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

A SharePoint deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Conceptual overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Data-protection planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Individual SharePoint disaster recovery tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

SQL Enterprise Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Internet information services (IIS) metabase backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Overview of backup and restore utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Utilities not working in concert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Backup Exec 11d Agent for SharePoint Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Backup Exec Components for SharePoint Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Backup Exec 11d Media Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Backup Exec 11d Media Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Backup Exec 11d Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Reusing selection lists, policies, and jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Monitoring and reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Licensing of Backup Exec in the SPS environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Backing up a SharePpoint Portal Server environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Viewing the SharePoint topology from within Backup Exec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Backing up SharePoint configuration and content databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Individual document recovery foresight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

White Paper: Enterprise Security

Symantec Backup Exec 11d

for Windows Servers

Contents (cont’d)

Advantages of staging backups to disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

Single sign-on service database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Snapshot Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Restoring SharePoint from a backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Individual document recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Backwards compatibility library—file version recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

Full SharePoint farm or database server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

Additional resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

SharePoint configuration anaylzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

SharePoint running on SQL Server 2005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Best practices for SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Executive Summary

Microsoft SharePoint Portal Server (SPS) 2003 offers a second-generation document

management, project collaboration, and intranet site management tool with improved scalability

and flexibility for Windows servers. It facilitates easy organization, sharing, retrieval, and

publishing of information over corporate intranets and seamlessly integrates with Microsoft Office

and Web development tools.

SharePoint is fast becoming an industry platform for information distribution and content

management. Its importance in the corporate environment is beginning to reach that of mission-

critical status as it becomes a vital link for internal communications. The loss of SPS data stores

could potentially cause a large disruption should any one of the SharePoint components become

corrupt or lost.

There are many utilities and tools available for backing up the various SharePoint

components, but the complexity of coordinating the efforts of each to ensure proper recovery of

the SPS server is time consuming—and they do not provide the capability to recover individual

documents from the backup sets.

This white paper provides a detailed review of how to comprehensively protect and recover

SharePoint Portal Server 2003 and Windows SharePoint Services on the Windows Server 2003

platform using Backup Exec 11d for Windows Servers and the optional Backup Exec Agent for

SharePoint Portal Server.

The release of SharePoint Portal Server 2003 and Windows SharePoint Services has

dramatically changed the SharePoint architecture, requiring new methods for presenting data to

the user as well as for backing up this data. This format not only is different from the previous

version of SharePoint but also introduces many complexities in supporting data that is passed

freely between servers. The exchange of information between servers in the farm will not only

change how an administrator backs up this data but how the user goes about selecting backup

and restore methods without having to know the details about the servers’ or server farms’

configuration.

Product Highlights

The new Backup Exec Agent for Microsoft SharePoint Portal Server automates the many steps

required to comprehensively protect an SPS environment. The methods involved in protecting

SharePoint Portal Server 2003 require the use of the Backup Exec media server and the SPS

agent, which includes the necessary remote agent for a single server or small server-farm

configuration.

Key Benefits

• Protects and recovers business-critical

Microsoft SharePoint Portal Server 2003

and server farms

• Via Granular Restore Technology, enables

the individual document restore from

SharePoint Server SP2 and Windows

SharePoint Services 2.0

• Simplifies and helps to ensure that the

necessary components of SharePoint

Portal Server 2003 are comprehensively

protected and available for restoration

and complete disaster recovery

Symantec Backup Exec 11d for Windows Servers

6

7

This agent supports backup and restore of SQL databases, document libraries, index

databases, and some additional metadata. The Backup Exec Agent for SharePoint Portal Server

enables administrators scale their backup and recovery activities from a single-server SharePoint

Portal environment to large, distributed server-farm environments. The use of server farms lets an

administrator break out the various components of a SPS configuration to many servers in an

enterprise (Each server is a component of a server farm.) The SPS agent also lets administrators

browse the farm independent from the rest of the servers in the enterprise to customize their data

protection strategy.

What’s new:

• Restore individual documents from full backups of SharePoint Portal Server 2003

• Protects and restores Windows SharePoint Services (WSS), including individual document

restore

A SharePoint Deployment

Conceptual overview

A SharePoint Portal Server 2003 deployment contains one or more servers and/or server

farms within a domain. SharePoint Portal Server 2003 consists of the following components:

a configuration database, portal sites and their associated databases (content, user profile,

services, index, and team), a Windows SharePoint Services site, a Single Sign-On database,

Document Library Store/Document Libraries (Web Storage System–based) and Document

Libraries/Picture Libraries (Microsoft SQL Server–based).

Figure 1. A typical SharePoint Portal Server deployment.

ClientsSYMC-SPS

Microsoft Office Sharepoint

Portal Server 2003

(Web, search, index, job)

SYMC-SQL

SQL Server 2000

(Databases for SYMC-SPS)


To clarify various SharePoint Portal Server 2003 configurations, note these baseline

configurations for establishing common terminology when referring to standard farm deployments:

• Single-server configuration: Single server hosting all SharePoint components, including either

an MSDE or SQL Server database

• Small server farm: All SPS components on a single server except for the SQL Server database,

which has been installed on a separate server

• Medium server farm: One or more front-end Web servers with the search component enabled;

one or more index management and job servers; and one or more servers running a SQL Server

database

• Large server farm: Two or more front-end Web servers; two or more search servers; one or more

index servers, one of which is the job server; and one or more SQL Server database servers

Figure 2. A more complex SharePoint Portal Server architecture layout.

Front-end Web

SPS–Index

Management

Server

SPS–

Search

Server

SPS–

Job Server

SQL Server 1

Front-end Web

SQL Server 2


8

9

Data protection planning

Without the proper tools and processes in place, the time-consuming tasks of collaborating,

publishing, and controlling access to documents within an organization could easily result in data

being lost, overwritten, duplicated, or misplaced. While SharePoint Portal Server 2003 solves

these and other problems, it needs additional data protection tools for reliable disaster recovery,

scalability, and ease of use. Without the proper data protection strategy, an organization places

its documents and data at risk—the environment has no defined data protection schemes, and

recovery processes have not been defined. It is crucial that organizations research, evaluate, and

deploy a comprehensive data protection solution for SharePoint Portal Server 2003.

As organizations deploy SharePoint Portal Server 2003, the common question will arise of

how to effectively protect and recover valuable data stored within SharePoint Portal Server 2003.

This white paper answers this simple, yet crucial question. It also presents various tools, processes,

and strategies available to back up, restore, and duplicate SharePoint Portal 2003 servers. Each

organization must decide—based on size, infrastructure, and type of SharePoint Portal Server

2003 deployment—what combination of these tools best fits its environment. Additionally, when

determining specific SharePoint Portal Server 2003 data protection needs, organizations must

consider these questions:

• Will backup processes be performed while SharePoint Portal Server 2003 is online or offline?

• Will backup processes be performed from a central location or distributed among multiple

servers?

• Will backups be stored on tape media or disk volumes?

• Will backup processes be performed individually or combined with Symantec File System

software and other protected resource backups such as Exchange, SQL, or Domino®?

• How frequently should a backup of SharePoint Portal Server 2003 be performed?

• How can a corrupted or accidentally deleted file be recovered?

• How is protecting a SharePoint Portal 2003 server farm different from a single-server

installation?

• What tools exist to help automate and simplify SharePoint Portal Server 2003 data protection?

• What steps are involved for quickly and reliably recovering from catastrophic data loss or an

individual document?


Individual SharePoint disaster recovery tools

The two most common scenarios of data loss typically involve loss of individual documents and

the loss of the SPS server or portal itself. Microsoft provides administrators with several tools for

backup and recovery of critical SPS information, whether it is from a single team site or an entire

SPS server. The functionality varies per tool, and several are needed to work in concert to ensure

proper recovery for any given disaster scenario. The following sections outline the tools that can

be used to protect components of the SharePoint deployment.

SharePoint Portal Server Data Backup and Restore tool

This very basic graphical backup and recovery tool from within the Admin Console for SharePoint

is essentially used for portal-level recovery operations. It is installed on the SPS server and allows

administrators to back up portal databases to a network location or a shared folder on the machine

running SharePoint Portal Server. Additionally, the Backup and Restore tool can be called from the

command line (Spsbackup.exe), and savvy administrators can call the application from a script for

convenient scheduling via the Windows Scheduler.

Figure 3. SharePoint Portal Server Data Backup and Restore tool.


10

11

Essentially the Data Backup and Restore tool performs SQL database backups across the

network. However, using this tool rather than traditional SQL Server backups enables the

administrator to retain the SPS index. If there is a large index of searchable content, adminstrators

will appreciate the ability to protect this valuable asset. The key limitation of the Data Backup

and Restore tool is its inability to perform lossless restores. That is, if administrators restore with

a portal backup using this tool, all existing portal data will be overwritten with the restore. The

only way to work around this is to restore the portal to a separate standby SPS server; from which

information can b extracted; and from there move over to the target SPS server. This is time-

consuming and may require additional investment in hardware.

stsadm.exe

This command-line administration tool, which is installed on all servers running WSS and SPS,

must be run locally on the server in question. This versatile tool performs numerous operations—

but when used with the –o backup switch, stsadm.exe can back up one or more sites, including

the unique My Site for each user

Here is an example stsadm.exe backup job for a site called “Marketing” on SYMC-SPS:

Stsadm.exe –o backup –url http://symc-sps/sites/marketing -filename

c:\stsadm_bak\marketing.dat -overwrite

This command backs up the Marketing site to a single file called marketing.dat on the local

system drive. This is a full-fidelity backup, meaning all security and metadata information is

included. To restore the data, simply replace the –o backup switch with –o restore.

Administrator privileges (both within SharePoint Central Administration and on the server itself)

are required for both backup and restore operations using stsadm.exe.

Keep in mind, stsadm.exe is not a replacement for the SPS Backup and Restore tool.

Microsoft recommends against running stsadm.exe backups during times when users are

accessing SPS due to a likely increase in the processing burden on the SQL Server during this

operation. Nevertheless, stsadm.exe is still a useful tool for recovering from accidental site or

document deletions.


smigrate.exe

The Microsoft SharePoint Migration Tool (smigrate.exe) was originally designed to migrate sites

from one server to another, but smigrate.exe can also be useful for site backup and recovery. A

key difference between this tool and stsadm.exe is its lack of support for full-fidelity backups

(meaning permissions will be lost after a restore). Like stsadm.exe, this tool applies to both WSS

and SPS installations, but it only works primarily at the Web level. Smigrate.exe will not back up

site collections.

Here is an example smigrate.exe backup job for a site called Sales on SYMC-SPS:

Smigrate.exe –w http://symc-sps/sites/sales -f c:\smigrate_bak\sales.fwp

Ntbackup

It is critical that administsrators run local file system backups on a regular basis as part of a SPS

disaster recovery plan. The previous utilities are tools for backup and recovery that are specific to

SharePoint. However, to extend protection to the server on which the application resides requires

the use of another backup and recovery tool. Microsoft supplies Ntbackup with each server license.

It is used to capture files that reside on the local file system that fall outside the SPS data held in

SQL Server. Examples include web.config files in the \InetPub directory, Web Part assemblies in

%systemroot%\assembly, and custom templates in various directories under C:\Program Files.

SQL Enterprise Manager

Considering the value and the likely size of the amount of data that is being managed by a

SharePoint deployment, it would make sense to protect the SQL Server database in which the

data resides. SQL Enterprise Manager provides basic data protection and recovery tools as

part of its SQL Server administration tool set. SharePoint Portal Server maintains data in four

separate databases: portal, services site, configuration, and an optional Single Sign-On database.

Database Description

Portalname_PROF Portal profile database, which contains user profile information and audiences

Portalname_SERV Information on portal services, such as search and alerts

Portalname_SITE Site content database (may be more than one depending on size of SPS farm)

SPS01_Config_db Configuration database (one per SPS farm)

SSO Optional Single-Sign-On database used in large SPS farms


12

13

More information on SQL Server data protection utilities is available from Microsoft or from

the many online and printed books on SQL Server operations. Typically, SQL Enterprise Manager

would be used to recover the databases in the event of a database or file system corruption or

hardware failure.

Internet information services (IIS) metabase backup

One overlooked aspect of SharePoint data protection and recovery is the ability to recover the IIS

metabase. The IIS metabase contains critical information about virtual servers that is not covered

by any of the SharePoint backup tools. Without a functional IIS metabase, all portal content is

inaccessible. IIS 6.0 provides automatic metabase backups. However, it is likely that once you

discover the metabase as the source of your problems, the automatic backups will be too recent

to be useful. To avoid this problem, you should maintain an archive by scheduling daily metabase

backups using the IISBack.vbs script, which is included in all editions of Windows Server 2003.

Here is a sample IIS metabase backup job using IISBack.vbs:

C:\windows\system32\cscript IISBack.vbs /backup /b SYMCBackup

Overview of backup and restore utilities

Tool Purpose and Deficiency

SharePoint Portal Server

Data Backup and Restore

tool (Spsbackup.exe)

Backs up and restores all databases, except the configuration database. Restores

content indexes and content sources.

Must be run from the SPS server; restore overwrites current data; can be time

and/or hardware-consuming to recover from an alternate recovery server; only

allows full database backups via VDI.

stsadm.exe Makes a full-fidelity backup of site collections.

Microsoft SharePoint

Migration Tool

(smigrate.exe)

Backs up and restores sites and subsites. Does not make a full-fidelity backup;

you might lose some customizations or settings during the process.

Will not back up site information.

SPBackup.exe Determines which site collections have changed and generates a batch file that

backs up changed site collections using the stsadm.exe tool.

Ntbackup Back up and restore the operating system and files for the SPS server; basic system

protection.

Lacks the depth of SQL Server and SPS-specific file protection; must be scheduled

via the Windows Scheduler.

Cscript IISBack.vbs Backs up the IIS metabase.

Requires scheduling and running the script more frequently, as well as archiving

the backups more frequently than the default backups created by SPS.



14

Utilities not working in concert

As has been discussed, Microsoft has provided many tools and utilities for administrators to use for

the protection and recovery of a SharePoint Portal Server deployment. However, it is apparent that

the coordinated use of these disparate tools and the complexity in the amount of configuration,

scheduling, and maintenance involved could possibly leave the SharePoint deployment vulnerable to

adequate and timely protection. Add to the ability to quickly and accurately restore lost documents

or an entire server and the coordination of recovering the right components in the right order

compounds the complexity and effort of an accurate restoration of data.

The impact of a SharePoint server loss can cost a company enormous amounts of time and

resources when trying to recover these components. The logical conclusion is to seek out a third-

party application to fill the need of backup and recovery. SharePoint administrators should consider

the questions posed at the beginning of this section and determine the following: Are the utilities

enough for the task of protecting and recovering the critical data in a timely manner? Can I meet

the service-level agreement time frames that our business requires and not impact bottom-line

revenues by not having the data available for end users? What alternative solutions are available?

Backup Exec 11d Agent for SharePoint Portal Server

The Backup Exec Agent for SharePoint Portal Server allows comprehensive protection of business-

critical content management stores and seamlessly integrates as part of a comprehensive network

backup and recovery solution. The agent now offers the restoration of individual documents that

may have become corrupted or deleted from the content database. It also provides additional

application support: Administrators can now use the agent with Windows SharePoint Services as well

as with SharePoint Portal Server. This agent safeguards SharePoint Portal Server 2001 and 2003

corporate knowledge-based systems with online, fast, and reliable data protection and recovery.

Protected portal components include the Web Storage System, Search Service, Server

Configuration files, and Applications folders. Restore options include individual document

recovery, full database and dependent data restores, or redirection to an alternate SharePoint

Portal Server. Restores can be made to the original SPS information store or redirected to another

SPS information store without affecting other workspaces.

Specifically, administrators can use the Backup Exec SharePoint Agent to back up and restore

SharePoint Portal Server 2003 farm components, including:

• Configuration database

• Portal sites and their associated databases

• Content database

15


• User Profile database

• Services database

• Index databases

• Team databases

• Windows SharePoint Services sites and their associated databases

• Single Sign-On database

• Document Library Store (Web Storage System–based)

• Document Libraries (Web Storage System–based)

• Individual documents, which can be backed up from and restored to Web Storage

System–based document libraries, or redirected to file paths

• Document Libraries/Picture Libraries (Microsoft SQL Server–based)

• Individual documents, which can be restored from full database backups

In addition, users can back up and restore Windows SharePoint Services components,

which include:

• Configuration database

• Team sites and their associated Content database

• Document Libraries/Picture Libraries (Microsoft SQL Server–based)

• Individual documents, which can be restored from full database backups

Backup Exec components for SharePoint Portal Server

Backup Exec 11d media server

Before implementing your SharePoint Portal Server 2003 data protection plan, administrators

must have installed and configured a Backup Exec 11d media server. Installation and

configuration instructions are available in the Symantec Backup Exec 11d for Windows Servers

Administrator’s Guide. The Backup Exec media server must have the following options licensed:

• Backup Exec 11d for Windows Servers

• Backup Exec Agent for Microsoft SharePoint Portal Server

• Backup Exec Agent for Microsoft SQL Server (optional for multiple SQL Server instance

deployments)


16

Backup Exec 11d media sets

Once a media server is available, depending on the present media management scheme,

administrators may want to define one or more media sets for the SharePoint Portal Server 2003

servers at this site. A media set is a group of media, most likely a set of tapes or backup-to-disk

folders, to which backup jobs are saved. The media set controls the overwrite protection period,

which is how long that data is retained before being eligible to be overwritten, and the append

period, which is how long that data can be appended to media. Defining a media set lets an

administrator customize backup-job retention policies and makes it easier to view SharePoint

Portal Server backup entries in the Backup Exec media catalog, since entries are grouped by

media set.

Backup Exec 11d Remote Agent

Before administrators can create jobs, they must install the Backup Exec 11d Agent for Windows

Systems on each SharePoint Portal Server 2003 server that will be backed up.

Reusing selection lists, policies, and jobs

Selection lists, policies, and jobs can be copied from one Backup Exec 11d media server to

another. Follow these steps to do so (the procedure to move policies and jobs is similar):

1. Launch the Backup Exec 11d Administration application.

2. Open the Job Setup window.

3. Right-click the selection list to copy to another media server.

4. Select Copy.

5. In the Copy Selection List popup window, select Copy to other media servers, and then

click Add.

6. Enter the destination media server name and logon account information in the Add Server

popup window, and click OK when done.

7. Repeat for any other destination media servers.

8. Click OK to start the copy.

17

Backup Exec Agent for MOM

Backup Exec 11d offers a management

pack for use with the Microsoft Operations

Manager (MOM) at no additional cost.

The MOM management pack monitors the

health and availability of Backup Exec for

Windows Servers software. By detecting,

alerting, and automatically responding to

critical conditions, the management pack

helps identify, correct, and prevent possible

service outages. The management pack is

available for download at

http://seer.support.veritas.com/

docs/272197.htm.


Monitoring and reporting

Regular monitoring of backup jobs is an important task for backup administrators. If backups of a

SharePoint Portal Server 2003 server fail for any reason, it will not be possible to restore that

server to its most recent state. For this reason, the SharePoint Portal Server administrator should

also monitor the backup status.

There are more than 40 reports included with Backup Exec 11d that show detailed

information about protected servers, media, and devices. When generating most of the reports,

administrators can specify settings that serve as filter parameters or a time range for the data

that need inclusion in the report. This makes it possible to create a report that includes the set of

SharePoint Portal Server 2003 servers. A report can be run and viewed immediately, or

administrators can create a job that saves the report data in the job history.

Backup Exec 11d can schedule a report to run at a specified time or on a recurring schedule,

and it can distribute reports through email notifications. This makes it possible to run scheduled

reports that supply the data protection status of a set of SharePoint Portal Server 2003 servers,

as well to distribute the reports to all members of the organization responsible for the

maintenance of these servers.

Reports are generated using XML and can be viewed and printed in an HTML, XML, or XLS file

format. If Backup Exec detects that Adobe® Reader is available, it displays reports in the Adobe

Portable Document Format (PDF). (The free Adobe Reader software is available at

www.adobe.com/acrobat.)

Below is a list of Backup Exec 11d reports that will help backup and SharePoint Portal Server

administrators effectively monitor the data protection status of a set of SharePoint Portal Server

2003 servers:

• Backup Job Success Rate—shows the success rate for jobs run on a set of selected servers.

• Backup Resource Success Rate—shows the success rate for each resource on a set of selected

servers.

• Backup Set Details by Resource—shows detailed information for each resource backed up on

a set of selected servers.

• Backup Sets by Media Set—shows detailed information about all backup sets on selected media

sets.


18

• Failed Backup Jobs—lists failed jobs for a set of selected servers, over a user-definable time

period.

• Media Set—lists all the media used for a user-selectable group of media sets.

• Overnight Summary—provides an easy-to-view list of all backups within the last 24 hours for

a set of selected servers.

• Policy Jobs by Resource Summary—shows details for a set of selected servers about each

resource backed up in a user-defined period using policy-defined jobs.

• Policy Jobs Summary—shows all the jobs derived from selected policies in a specified time range.

• Policy Protected Resources—shows a list of resources, and the policy and templates assigned

to them, for a set of selected servers.

• Problem Files—shows a list of files that Backup Exec had a problem backing up, by resource,

for a set of selected servers.

• Resource Backup Policy Performance—shows the success rate of policy-derived jobs for a

user-defined time period, on a set of selected servers.

• Resource Risk Assessment—provides a list of resources for which the most recent backup

failed, for a set of selected servers.

• Restore Set Details by Resource—shows detailed restore information by resource, in a user-

defined time period, and for a set of selected servers.

To view or schedule reports, open the Backup Exec 11d administration application, and click

the Reports tab. Right-click a listed report to see its run and scheduling options.

Licensing of Backup Exec in the SPS environment

The Backup Exec Agent for SharePoint consists of the following components: one component to

protect a single SQL Server database instance and one Agent for Windows Systems that is

installed on the stand-alone SPS server.

In its simplest form, SharePoint Portal Server 2003 is installed on a single server. The SPS

server consists of the SharePoint application and an MSDE or SQL Server 2000/2005 database

running on Microsoft Windows Server 2003. The Backup Exec SPS agent includes all the

necessary components to protect this configuration.

19

A typical small server farm consists of two servers: a server running SharePoint Portal Server

2003 on Windows Server 2003 and a second server running SQL Server 2000 on Windows 2000

Server or Windows Server 2003. A single Backup Exec Agent for SPS license and an Agent for

Windows Systems are required to protect this small server-farm configuration.

A medium or large server farm consists of a minimum of the following components: one SPS

2003 server on Windows Server 2003, one or more SQL servers running on Windows 2000 Server or

Windows Server 2003, one or more Web servers, one or more job servers, and one or more search

servers. To comprehensively protect these large server-farm configurations, the software need would

be one Backup Exec Agent for SPS 2003t, a Agent for SQL Server for each additional SQL Server, and

a Agent for Windows Systems for each additional server beyond the initial SPS server.

Figure 4. Licensing Examples for protecting a SharePoint Farm

In the example above, the following licenses are required:

• One Agent for SharePoint Portal Server

• One additional Agent for SQL Server for the second SQL database instance

• Five additional Agent for Windows Systems

Note: In cases where multiple SPS farms share a single SQL database, each farm requires a

separate SharePoint license.

Index Managemant

Job Server

Two Web Front-end Servers Two SQL Search Servers SharePoint Portal server


Backing up a SharePoint Portal Server environment

Viewing the SharePoint topology from within Backup Exec

If the local server has SharePoint components installed, from the local selections node in the file

selection view, select the node called Microsoft SharePoint Resources. This node will display the

list of the SharePoint components installed on the machine. The node will display all of the

components in the farm, not just the components installed on the local machine. However, only

the local components can be selected from this node.

With Backup Exec 11d, a SharePoint farm node is added to the top level of selection choices.

If the Backup Exec Agent for SharePoint Portal Server is installed and has run its discovery, the

check box will be enabled. When the administrator expands the tree view of the farm, and if the

SharePoint configuration includes remote selections, each of the resources will be displayed.

Typically these nodes are loaded automatically; however, an administrator can add nodes manually.

To add these nodes manually, select Add Server Farms in the context menu. To add nodes

automatically, browse to a front-end Web server that participates in a server farm. Administrators

can automatically select the entire server farm to back up the entire set of servers and components

for your environment.

Backing up SharePoint configuration and content databases

In Microsoft Office SharePoint Portal Server 2003, all farm, server, and site configuration

information is stored in the configuration database, and all site content is stored in content

database(s). If administrators want to individually restore all the SharePoint Portal Server 2003

information on the existing server or server farm, they must back up these databases with the

Backup Exec Agent for Microsoft SharePoint Portal Server 2003 as part of a full backup. If there

is a server farm configuration, the Backup Exec Agent for SharePoint Portal Server contacts the

front-end Web server for the SharePoint schema. The Web server is running a process that queries

all the database(s) (and/or servers) and collects the necessary data for backup.

The databases for SharePoint Portal Server 2003 are usually created in either the default

instance or a SharePoint specific instance. These resources are displayed in the Backup Exec

selections list when administrators define the backup job.


20

21

Figure 5: The backup Job Properties box displays the backup selection list.

The following components are interrelated and must be backed up together in a SharePoint

Portal Server 2003 environment so that the databases will be in sync. The following examples use

Team Portal as the portal name:

• To maintain consistency, the site and profile databases must always be backed up together. For

example, the following databases must be backed up together.

– TeamPort1_PROF

– TeamPort1_SITE

• To fully recover a SharePoint portal site, three components are needed: the Site, Profile, and

Server databases. For example, the following databases must be backed up:

– TeamPort1_PROF

– TeamPort1_SITE

– TeamPort1_SERV


When the SPS farm is backed up, it includes the configuration database, and administrators

must ensure that the portals (profile, site, and server databases) are all backed up at the same

time. If all databases are restored, the SharePoint Portal Server 2003 server or farm will be

restored to same state that it was in when it was backed up. (This is due to the restore of the

configuration database.) However, problems may result if the configuration database is restored

individually without the other databases. If configuration information is lost, the SharePoint Portal

Server 2003 farm or server may be compromised, which may result in data loss. To ensure that

the SharePoint Portal Server 2003 server or farm can be restored in its entirety, administrators

must include the configuration database when they back up all the databases. For example, the

following databases must be backed up to ensure a complete restore of the configuration

database:

• TeamPort1_PROF

• TeamPort1_SITE

• TeamPort1_SERV

• SPS01_Config_db

• Index

If the farm is distributed among several servers and each of these components is on a

separate server, each resource will require its own backup set. Best practices for restore would be

to select all sets in one job and bring all databases online after the restore job is completed rather

than bring each database online after the individual database restore is complete. See the Backup

Exec Administrators Guide for details on how to configure a database restore so that it does not

automatically start up on completion of the restore.

Important: Proceed with caution. Restoring individual databases will only be useful if the

configuration on the farm has changed (e.g., server names) between the time of the backup and

the restore. The configuration database holds all of the topology information. If administrators

restore the configuration database and the topology changed, then it will no longer be valid. In

that case it would be better to create a new configuration database and restructure the topology.


22

23

Individual document recovery foresight

If the recovery plan involves the potential recovery of individual documents, administrators will

need to follow the guidelines listed in the previous section and ensure that the “Enable the restore

of individual documents from the database backup” has been checked (this is the default setting).

The only backup method enabled to perform this recovery is from a “full” backup only. The backup

sets are then staged to disk in the Backup To Disk (B2D) folder, so administrators will need to

ensure that enough disk space exists on the Backup Exec media server at the time of the backup.

Figure 6. To ensure document-level recovery, check “Enable the restore of individual documents….”

Advantages of staging backups to disk

The apparent advantages of staging SharePoint backups to disk media are speed of both backup

and recovery. Backup Exec uses a proprietary technology, Granular Restore Technology (GRT),

to encapsulate a backup of the SharePoint resources to a local B2D folder on the Backup Exec

media server (or other network NTFS-based resource). This patent-pending technology enables

the granular recovery of individual documents within SharePoint SQL Server-based Document

Libraries from a full backup. Each backup is sent to disk and can later be copied from disk to tape

for archival purposes.


The key advantage with this technology is that backing up to and recovery from files stored

locally on disk are going to be significantly faster than with those stored to tape. It is notable that

most restorations are typically document-oriented and usually requested within a 7- to 10-day

window of the file’s creation. So if a policy is created to maintain regular backups for a period of 7 to

10 days on disk, SLA times for backup and recovery are lower and more economical. Administrators

can then move older backups to tape. However, recovery times will be slower once data is moved

to tape. For these situations, the file would have to be retrieved from tape before it’s restaged to

disk and finally back into the location from which it originated. This operation is transparent to

the administrator, but there will be a noticeable time difference.

There are some considerations to keep in mind when using GRT for individual document

recovery:

• Backups must be performed to a local B2D folder on the Backup Exec media server running

Windows Server 2003 or later.

• The B2D folder must be on an NTFS volume; it can be redirected to another disk-based resource

such as a NAS.

• When the backup job is created, the B2D folder must be explicitly selected, or the job may be

sent to an alternate media selection and the job may fail.

• Backup to tape with encryption is fully supported; encryption of data on the B2D files is not

supported. Symantec recommends OS encryption at the B2D folder level to prevent access to

the content stored there.

• Database files are backed up in native file format (*.MDF). Symantec suggests that customers

put an Access Control List (ACL) on the B2D folder to prevent unauthorized access.

• Granular restore from tape, while supported, requires a two-stage restore from tape then to

disk. It is transparent to the administrator, but increases the length of time for recovery.

Where is the data stored on disk? It is stored on the volume and directory administrators

create when they initially set up media sets within Backup Exec. Backup Exec will then create a

B2D folder. The GRT backups will be placed in the folder and labeled as IMGXXXX, where XXXX

is a sequential number. An example in Figure 7 shows “IMG0001.”


24

25

Figure 7. Examples of the Backup To Disk/GRT location and folder content

Table 1. Traditional tape- versus disk-based backups

Single Sign-On Service database

If the Microsoft SharePoint Portal Server farm uses Single Sign-On Service, that database as well

as the encryption key must be backed up. The database can be automatically backed up using

the Backup Exec SPS 2003 agent; the encryption key is automatically backed up by the Backup

ExecSPS 2003 agent. The Single Sign-On Service database is given the name SSO by default. Both

of these items are backed up together.

Setup Staged restoration Resource utilization

Disk Simple setup: Data is stored

in the GRT folder inside the

B2D folder

Single-Stage Fast Backup and

Recovery

Uses disk resources on a local

or remote server for staging

of data

Tape More complex to set up; must

create a duplicate job to move

data from disk to tape

Two-phase restore: from

tape to disk to SPS directory

(transparent to the user, but

requires more time)

Less expensive storage of

archived files


Snapshot technology

When backing up SharePoint Portal Server with SQL Server-based repositories, the administrator

can leverage snapshot technology to minimize the impact on the production servers. Currently,

the technology available for snapshot is Volume Shadow Copy Service (VSS) on Windows Server

2003. VSS snaps are the only ones applicable to the Backup Exec Agent for SharePoint Portal

Server. The use of VSS for SharePoint backups is enabled by making the selection on the

Advanced Open File Option property page, the same as it is for specifying VSS snapshot backups

of other resource types (Exchange, SQL, etc.).

Note that the Index database is not snap-aware, so it will be backed up in the traditional

manner. It must be included as part of the selection list.

Figure 8. Use the Advanced Open File Dialog to set VSS snapshot capabilities to “on.”


26

27

Restoring SharePoint from a backup

Administrators can restore the entire SharePoint Portal Server farm, server, or the individual

documents that are contained in the Document Library if the documents were backed up

separately. Another option is to redirect the restore of a SharePoint Portal Server 2003

deployment to a different server than the one from which it was backed up. Lastly, administrators

can redirect the restore of Document Library or its objects to an alternate workspace or file share.

Restorable SharePoint Portal Server resources include:

• The entire SharePoint farm or SharePoint server (depending on how distributed a deployment is).

• Portal sites and their associated databases. Each portal site will have a minimum of three

databases: Content database, Services database, and the User Profile database. Symantec

recommends that you restore these databases together.

• Windows SharePoint Services sites and their associated databases.

• Individual documents that are contained in Document Library (SQL-based) or Picture Libraries

(Web Storage System–based or Microsoft SQL Server–based).

• Backward-compatibility Document Library stores (Web Storage System–based).

• Configuration database. This database contains all of the configuration information for the

entire SharePoint server farm.

• Single Sign-On database.

Individual document recovery

The Backup Exec Agent for SharePoint Portal Server 2003 enables the recovery of individual

documents from a full backup of SQL Server–based repositories. To recover an individual

document, administrators simply open a new Restore Job and drill down to the full backup and

document library they wish to recover from to make their selection(s). Once committed, the agent

will then recover and overwrite the existing file with the recovered file(s), bring the database back

online, and reconnect any links.


There are some limitations as to what information can be restored from Document Libraries.

The interface in Backup Exec is intended to provide backup and restore of individual documents

stored in the Document Library subfolder for each workspace and should not be used as a

substitute for SharePoint Portal Server database backup. Many of the other files and folders

contained in the workspace are controlled by the SharePoint Portal Server software and may not

restore successfully into the workspace even though they are available for backup. In addition,

when restoring individual documents, the creation date and modification date properties do not

restore—so it is up to the users to recapture this data.

Other limitations are:

• Individual document recovery is only pulled from full database backups. It cannot be performed

from incremental backups.

• Only user documents located in document stores can be restored individually. Administrators

cannot perform individual restores of other SharePoint components such as generated Web sites

or content; generated lists, sub-lists, announcements, news, etc.; individual site re-creation; or

individual Document Library re-creation. Examples of what is excluded are:

– Events

– Links

– Tasks

– Contacts

– Announcements

– Discussion boards

– Surveys

– Issues

– Custom lists


28

29

Figure 9. Administrators can recover individual documents by simply selecting

the documents from the content database within a backup set.

Backward-compatibility library—file version recovery

There may be instances where users require that a past version of a document be recovered from

the Web Storage System–based Libraries for either SharePoint Portal Server 2001 or SharePoint

Portal Server 2003. For these cases administrators will need to recover files from the SHADOW

folder, at the root of the workspace. It contains previous versions of the documents that exist in

the workspace at the time of the last backup. If you selected the SHADOW folder to include in a

workspace backup, you can have access to the previous versions of the documents in the

workspace. However, due to SharePoint limitations, you cannot restore the previous versions

directly back into the workspace. These files must be restored to an alternate location and then

manually copied back into the workspace.

The Backup Exec Agent for SharePoint does not maintain “versioned” files for SQL-based

Document Library content. To recover a particular version of a file from a past backup, locate that

file and restore it to the library, but be sure to unselect the “Restore over selected documents”

checkbox. That will send a “copy” of the file into the Document Library.


Full SharePoint farm or database server

There are two ways to restore the SQL database server components: (1) restore to the same server

from which the data was backed up or (2) redirect the databases to another SQL Server instance.

Restoring to the same database server

Running regular backups of the SPS servers and sites enables a restore in case there is a failure.

Recovering a SharePoint server is similar to other recovery operations: From any full backup,

make the restore selection from the desired backup set and run the restore. In the case of a

differential recovery, administrators need to select the most recent full along with any differential

backup in between the full and the differential recovery set required.

Within the SharePoint Restore Job Properties, be sure to check the “Bring restored databases

online and reconnect previous database links” checkbox to enable SharePoint to come back online

with the completion of the recovery. In the event of a multi-stage restore, select this option only

for the last recovery set. (If the administrator has created a single job, Backup Exec will apply the

connection after the final set is applied.)

Note: Backup Exec adheres to the design principals within SharePoint Portal Server that allow

for the restoration of both the Single Sign-On database and the Configuration database to their

original locations only.

Figure 10. Restore Job Properties enables the administrator flexible restore functionality.


30

31

Performing a redirected restore

The Backup Exec Agent for SharePoint simplifies the redirected restore process for administrators.

From the Restore Job Properties, select Microsoft SharePoint Redirection to establish the route

for the data to follow. When a redirected restore is performed to the same server, administrators

must rename the databases. (Note: Administrators can rename only one database at a time.)

SharePoint Portal sites and Windows SharePoint Services sites can be redirected to other sites in

either the same or a different farm, under the following conditions:

1. A site with the same ID doesn't already exist in the target farm (i.e., the original site can't

already exist at a different target URL within the same target farm).

2. A site does already exist in the target farm at the target site URL, having the same database

structure as the original source site (same number of content databases, etc.).

After the data is posted, the Backup Exec Agent for SharePoint will reconnect the servers as

part of the recovery process if the “Bring data bases online…” checkbox under the Restore Job

properties screen has been selected.

Links inside SPS and WSS sites are stored using URLs that are relative to the parent site

where they reside, so generally if they are moved, they continue to function. However, it is

possible to create links, such as subsites and user sites, that target specific static locations, so

those might stop working unless the target locations are still accessible from the redirected site.

So for example, if you back up http://portalsite1 and redirect it to http://portalsite2, then most of

the content contained under portalsite1 would now be accessible under portalsite2 (subsites, user

sites, etc.). However, anything that was originally created to target a specific URL would still

expect that URL to be accessible in order to function properly.

There is a key consideration for individual document recovery: The new granular restore of

individual documents in SharePoint Agent for Backup Exec 11d only allows for redirecting content

to a file system location. It does not allow for redirecting content to alternate locations within

SharePoint sites.


Figure 11. Redirection properties for the Restore Job

Single Sign-On Services database

If the Microsoft SharePoint Portal farm uses Single Sign-On Services, that database as well as

the encryption key must be restored. The database and encryption key can be restored using the

Backup Exec Agent for SPS Server. The Single Sign-On Services database is given the name SSO

by default. The name can be configured at Single Sign-On Services setup time.

Additional resources

SharePoint Configuration Analyzer

SharePoint Configuration Analyzer is a diagnostic tool that verifies settings on the server which

are critical to running Microsoft Windows SharePoint Services or Microsoft Office SharePoint

Portal Server 2003 and to hosting Web Parts on your server. SharePoint Configuration Analyzer

also reports on Web Part usage on your server and retrieves a set of log files, configuration files,

and Web Part packages used by Windows SharePoint Services, SharePoint Portal Server, and

Internet Information Services (IIS). In a server farm configuration, running SharePoint


32

33

Configuration Analyzer on each front-end server is a useful way to find and repair inconsistencies

in server configurations and to ensure that all Web Part assemblies are deployed on all front-end

servers.

Download the SharePoint Configuration Analyzer from Microsoft:

www.microsoft.com/downloads/details.aspx?familyid=918f8c18-89dc-4b47-82ca-

34b393ea70e1&displaylang=en

Figure 12. View the SharePoint farm with the SharePoint Configuration Analyzer.

SharePoint running on SQL Server 2005

SharePoint requires that Service Pack 2 (SP2) be installed prior to enabling the use of SQL Server

2005 or SQL Server 2005 Express as the database server. Both platforms have been tested and

are supported.


Best practices for SharePoint Portal Server 2003

• Each portal site must have a minimum of four databases: Content databases, Service

databases, a User Profile database, and the Index database; Symantec recommends that these

databases be backed up together.

• To recover individual documents, ensure that the checkbox in the SharePoint Job Backup Dialog

labeled “Enable individual file”

• Stage backups to disk for 7 to 10 days for quicker backup and recovery of SharePoint

databases, farms, and documents. After that time period use copy jobs to migrate the data to

tape for secure storage or archiving purposes.

• Ensure that servers have not only enough disk space to handle regularly scheduled backups but

also enough space for a full recovery of the database on the local server for individual document

recovery back from tape; or on an alternate server in the event of a redirect.

• When jobs are created to protect the SharePoint resources on the server farm, make backup

selections from this server farm node. In addition, back up the default Microsoft SQL Server

databases (master, model, and msdb) for each Microsoft SQL Server instance that hosts

SharePoint databases.

Summary

Symantec Backup Exec 11d for Windows Servers offers industry-leading support of Microsoft

Office SharePoint Portal Server 2003. The Backup Exec Agent for Microsoft SharePoint Portal

Server 2003 supports SharePoint Portal Server 2003 and Windows SharePoint Services

configurations. The agent makes it possible to restore individual servers or an entire SharePoint

Portal Server farm. In addition, administrators can recover individual user documents and select

components from a full database backup.

While there are many utilities available that can be used to support SharePoint Portal Server

backup and recovery, Backup Exec is explicitly designed with Microsoft standards in mind to

simplify the process of ensuring the recoverability of SharePoint Portal Server implementations.


34

For specific country offices and

contact numbers, please visit

our Web site. For product

information in the U.S., call

toll-free 1 (800) 745 6054.

Symantec Corporation

World Headquarters

20330 Stevens Creek Boulevard

Cupertino, CA 95014 USA

+1 (408) 517 8000

1 (800) 721 3934

www.symantec.com

Copyright © 2007 Symantec Corporation. All rights

reserved. Symantec, the Symantec logo, and Backup

Exec are trademarks or registered trademarks of

Symantec Corporation or its affiliates in the U.S. and

other countries. Domino is a trademark of International

Business Machines Corporation in the United States,

other countries, or both. Microsoft, SharePoint,

Windows, and Windows Server are either registered

trademarks or trademarks of Microsoft Corporation in

the United States and/or other countries. Other names

may be trademarks of their respective owners. Printed

in the U.S.A.

01/07 10753257

About Symantec

Symantec is a global leader in

infrastructure software, enabling

businesses and consumers to have

confidence in a connected world.

The company helps customers

protect their infrastructure,

information, and interactions

by delivering software and services

that address risks to security,

availability, compliance, and

performance. Headquartered in

Cupertino, Calif., Symantec has

operations in 40 countries.

More information is available at

www.symantec.com.

WHITE PAPER: ENTERPRISE SECURITY Data Protection for...

Documents

Transcript of WHITE PAPER: ENTERPRISE SECURITY Data Protection for...