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
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.