Backing Up and Restoring Servers (Windows SharePoint Services 2.0)

Data on three types of servers were backed up: front-end Web servers, Active Directory servers, and servers running SQL Server.

Front-End Web Servers

The data backed up from front-end Web servers was archived for analysis and long-term off-line reference, and never intended to be restored to the server. The following log files were backed up from these servers:

  • Internet Information Services (IIS) logs C:\Winnt\System32\Logfiles\W3svc1\*.log

  • Usage analysis log C:\Windows\System32\LogFiles\STS\ if usage analysis is enabled

  • Other Windows SharePoint Services logs STSAdm.log and OWSTimer.log from the C:\Documents and Settings\ Windows_SharePoint_Services_Administrator_Account \Local Settings\Temp directory.

Active Directory Servers

Backing Up Active Directory Servers

In this deployment, user accounts were replicated between the two peer Active Directory domain controller servers. In addition, the system state data on each Active Directory server was first saved to disk and then picked up nightly by the backup tape device. To avoid possible timing, performance, and replication issues, the system state was saved to disk at different start times for each Active Directory server. For example, the system state for the first server was saved at 19:30, the system state for the second server was saved at 21:30, and then the backup of the system states and user accounts began at 22:00. The Internet Platform and Operations Group used the Scheduled Tasks tool in Microsoft Windows Server 2003 to schedule these tasks.

System state data on the Active Directory serves included Active Directory and all other system components and services on which Active Directory is dependent, the system startup files, system registry, file replication service (the SYSVOL directory), and Domain Name System (DNS, if it is installed). The DNS data includes DNS zone information that is integrated with Active Directory. Active Directory includes the following files:

  • Ntds.dit The Active Directory database.

  • Edb.chk The checkpoint file.

  • Edb*.log The transaction logs

  • Res1.log and Res2.log Reserved transaction logs

Note

You must be a member of the local Administrators group on the Active Directory servers to back up Active Directory data.

Restoring Active Directory Servers

If data on disks is destroyed, an administrator can copy the data from tapes to a newly allocated hard disk, and then restore the Active Directory by using either a normal (non-authoritative) restore or an authoritative restore.

The normal restore allows the Active Directory server that was not restored to replicate changes to the restored Active Directory server. The restored server therefore reflects changes made after the backup that was used to restore it. The authoritative restore through the Ntdsutil utility prevents replication between servers for all items created before the restore. For example, you may only want to restore the users or OUs (Organizational Units) that are accidentally deleted from Active Directory, so that the deleted objects are recovered and replicated.

For more information about the different kinds of restores and restoring Active Directory servers, see Windows Server 2003 and Active Directory documentation.

Servers Running SQL Server

Backing Up Servers Running SQL Server

Windows SharePoint Services content and configuration databases and the MSSQL database were backed up first to disk by using SQL Server 200 Enterprise Manager, and then to the tape device by using Veritas Backup Exec software. Separate SAN partitions were configured for the data and backup drives.

Because the Internet Platform and Operations deployment of Windows SharePoint Services hosted test sites for beta users and the deployment was designed with enough fault tolerance to survive during some disk and server failures, the Internet Platform and Operations group used the SQL Server simple recovery model. In the SQL Server simple recovery model, log files are not backed up. For business-critical deployments, administrators should use full recovery mode. For information about the different recovery modes, see SQL Server documentation.

SQL Server Enterprise Manager allows administrators to schedule backups for each database in the system. In SQL Server Enterprise Manager, the Internet Platform and Operations Group entered backup tasks for daily and weekly backups of each database on both virtual servers.

The following diagram illustrates the scheduled job activity on the first virtual server. Similarly, on the second virtual server, the content and system databases are written to disk before they are copied to tape.

SQL Server Agent in SQL Server Enterprise Manager shows the status of the disk backup jobs in Figure 6, so administrators can determine whether backups are successful.

Figure 6 – SQL Server Enterprise Manager

SQL Server Enterprise Manager

SQL Server Enterprise Manager

Table 6 – Disk backup schedule for SQL Server databases

Database Server Type Sun Mon Tues Wed Thurs Fri Sat

MSSQL

Virtual servers 1 and 2

Full

19:00

19:00

19:00

19:00

19:00

19:00

19:00

Configuration database

Virtual server 1

Full

19:30

19:30

19:30

19:30

19:30

19:30

19:30

Content database 1

Virtual server 1

Diff.

20:30

20:30

20:30

20:30

20:30

20:30

Full

20:30

Restoring Servers Running SQL Server

SQL Server provides command-line options and graphical user interface options that administrators can use to restore data to servers. For more information, see SQL Server documentation.

Backup Failures

Administrators should choose backup software that alerts them if a backup job does not run or stops prematurely. Software should also track jobs that run successfully. Refer to your backup software documentation for specific setup and configuration.