Microsoft Press: Backup and restore

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

This book excerpt is from Microsoft SharePoint Products and Technologies Administrator’s Pocket Consultant, Microsoft Press, January 2007.

Buy this book (https://go.microsoft.com/fwlink/?LinkId=151961)

Microsoft SharePoint Products and Technologies Administrator’s Pocket Consultant (https://go.microsoft.com/fwlink/?LinkId=151961) is a definitive guide for administering Microsoft Office SharePoint Server 2007-with field-tested technical information and solutions developed by Microsoft Most Valuable Professionals (MVPs) with the Office SharePoint Server team. This comprehensive reference delivers all the information you need to plan, design, deploy, and manage strategic solutions using Office SharePoint Server 2007 and Microsoft Windows® SharePoint Services. Topics include architecture; deployment scenarios; design considerations; security best practices; high availability; performance; centralized administration; disaster recovery; customization and solution development; and upgrade and migration strategies. Key solutions include building sites and integrating Windows Workflow Foundation Services, enterprise search, application management, records and document management, Microsoft Office Excel® Calculation Services solutions and business intelligence, Microsoft Office Forms Server solutions, and mobile devices. The companion CD features a fully searchable eBook and job aids-everything you need to help build enterprise collaboration solutions that improve worker productivity, save time, and help reduce IT deployment and management costs.

Author

Ben Curry CISSP, MCP, CNE, CCNA, is a trainer and consultant who specializes in SharePoint Products and Technologies. He has more than 15 years of experience designing, implementing, and helping secure datacenter solutions, and previously worked as a network architect at NASA.

Book excerpt -- Chapter 14: Backup and Restore

The new versions of Windows SharePoint Services and SharePoint Server include improved tools for backing up and restoring content. Most notably, they give you the ability to back up and restore the entire farm from the command line. This allows for the automated scripting and scheduling in Windows Server 2003 for enterprise-level SharePoint Products backups. Yet, to complete successfully a backup of your SharePoint Products Web applications and associated content, you are still required to use additional tools, such as the Internet Information Services (IIS) configuration backup and restore tool. The backup and restore features of SharePoint Products does both content recovery and disaster recovery as follows:

• Content recovery

  • Document Versioning

  • Recycle Bin

  • Stsadm.exe -o [import | export] (site migration tool)

• Disaster recovery

  • Central Administration Graphical User Interface (GUI) Backup And Restore

  • Stsadm.exe -o [backup | restore] (site collection backup and restore)

  • Stsadm.exe -o [backup | restore] -directory (catastrophic backup and restore)

Many organizations require a combination of these backup methods to ensure a fully restored and functional server farm in the event of a disaster. The following items must be backed up and are discussed within this chapter:

• Complete operating system backups of all servers in the farm

• Individual IIS Metabase backups

• All InetPub folders when modifying IIS directories, as is the case with the Web.config file

• Indexes and associated Shared Services Provider Search database

• Web application configuration not stored in the configuration database (SSL certificates, assigned IP addresses, multiple host headers)

Content Recovery

Always use a content recovery method before using a disaster recovery method because it lessens the impact on other users. For example, using a site collection restore method for a single user’s deleted file would overwrite everyone else’s content as well, because you must overwrite the entire site collection when restoring. Start with the simplest method and progress as required to restore content. Depending on the severity of the file loss, corruption, or deletion, there are three native tools available to restore content to a usable state: document versioning, using the Recycle Bin, and using the migration tool.

Document Versioning

An often overlooked method of restoring content is the native document versioning. When a user calls you or your Helpdesk about a corrupted file, always check the document library and try to restore the last version if possible. For this reason, always store at least a few Major Versions of a document. To enable Major Versioning for a document library, do the following:

1. From the Document Library Settings menu, select Document Library Settings.

2. Under the General Settings column, select Versioning Settings.

3. At a minimum, select Create Major Versions, as shown in Figure 14-1. If disk space is of concern, limit the number of Major Versions to be retained. Selecting at least two Major Versions will give you some comfort room should a file corruption occur.

4. Click OK.

   Figure 14-1_ You should select at least two Major Versions for every document library if you want to use versioning as a content recovery method.

   

Configuring the Recycle Bin

One of the most useful and anticipated features of both Windows SharePoint Services and SharePoint Server is the Recycle Bin. Although most small to medium organizations can function quite nicely with the out-of-the-box settings, larger organizations will want to finely tune the Recycle Bin to prevent problems. Before configuring your Recycle Bin settings, it is important to understand that the Recycle Bin retention policies are set in Central Administration on a per-Web application basis. The actual management of deleted content, however, is performed on a per-site collection basis. This feature allows site collection administrators to manage deleted content, but does not give them the ability to modify retention settings.

In its default state, the Recycle Bin has two stages: First Stage (user deleted) and Second Stage (administrator/system deleted). The settings for these are not as straightforward as they appear and can have a wide-ranging system impact if not thought out and configured carefully.

Configuring the Recycle Bin Global Settings

Configure the Recycle Bin from Central Administration > Application Management > Web Application General Settings. Figure 14-2 shows an example of the Recycle Bin settings in Central Administration.

Figure 14-2_ Verify that you are in the correct Web application before changing Recycle Bin settings.

Modifying the Global Recycle Bin Settings for a Web Application

1. From Web Application General Settings, select the Web application you want to modify.

2. At the bottom of the Web Application General Settings interface, verify that the Recycle Bin Status is set to On.

3. Select the number of days that items should remain in the Recycle Bin before they are deleted.

4. Optionally, turn off time-based deletion. If this is selected, then items are only moved from the first stage when a user manually empties his or her Recycle Bin, and items are only automatically emptied from the second stage if a Site Quota is used and % Of Quota is defined. Changing the Recycle Bin expiration policy to Never does not turn off the first stage of the Recycle Bin. In fact, the first stage is not configurable.

It is important to note that contents deleted to the first stage of the Recycle Bin count against the site quota and individual quota. If you do not set a site quota, there is no maximum size limitation on the first-stage Recycle Bin. It is only constrained by the number of days you set.

Warning

If you turn the Recycle Bin off for a Web application and click OK, all Recycle Bins in that Web application, in both the first and second stage, are emptied. Although this action is useful for resolving an immediate low disk space situation, it should generally be avoided.

Configuring the Second Stage of the Recycle Bin

When a user deletes an item, that item is moved into the second stage of the Recycle Bin. The second stage does not count against the site quota or individual quota. However, its size is limited to a percentage of site quota size or is unlimited if you do not use a site quota. The second stage uses the “first in, first out” methodology for deleting files. That is, once the maximum size for the second stage of the Recycle Bin is reached, the oldest file in the stage is deleted to make room for newly deleted content.

Configuring the Second Stage of the Recycle Bin

1. Open Central Administration > Application Management > Web Application General Settings.

2. Select and verify the Web application you want to modify.

3. At the bottom of the interface are shown the Recycle Bin settings.

4. Change the percentage of the live site quota for second-stage items. The default is 50%, but a better starting point for most organizations is about 20% of live site quota. Depending on the amount of activity in your site collections, you may need to adjust this number to meet your needs. Figure 14-3 shows an example of both the global and second-stage settings of the Recycle Bin.

   Figure 14-3_ Consider 20% of live site quota for a second-stage starting point.

   

Optionally, you may turn off the second stage of the Recycle Bin. If you select this option, items removed in the first stage (user stage) of the Recycle Bin are deleted permanently. This option removes the ability for a site collection administrator to restore content that users have deleted from their Recycle Bin.

Important

Remember that you are adding the percentage of live site quota for a Web application when modifying the second stage. This means if you have designed your site quotas for 100-GB content databases, they can now grow to 150 GB to include the second stage.

Managing the Recycle Bin in a Site Collection

Site collection administrators manage content in both stages of the Recycle Bin from Site Actions > Site Settings > Site Collection Administration > Recycle Bin. In the Quick Launch, you can select which stage to manage. Checking an item in either stage and restoring that item will restore a full fidelity copy to its original location. This copy will include all versions and will be restored with the last user modified date, not the deleted or restored date. Figure 14-4 shows an example of both stages of the Recycle Bin management in a site collection.

Figure 14-4_ Click on a stage to manage deleted content for users.

Using the Migration Tool

The tool Smigrate.exe found in Windows SharePoint Services 2.0 and SharePoint Portal Server 2003 has been replaced and enhanced with the stsadm.exe -o [import | export] command-line options. The Stsadm.exe command is located in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin directory and is available in both Windows SharePoint Services and SharePoint Server. Both products support the creation of Content Migration Packages, which are XML files that allow sites and site collections to be imported and exported along with their dependencies, such as security features, user roles, workflows, and metadata. One major enhancement is the ability to migrate content including user permissions. This feature allows you to back up and restore single lists or items from a site collection or subsite and to include the associated user permissions. The following are examples of exporting and importing a site collection using Stsadm.exe:

stsadm.exe -o export -url 
http://portal.contoso.msft/sites/team1 
-filename c:\backups\team1.bak 
-includeusersecurity -versions 3

stsadm.exe -o import -url 
http://portal.contoso.msft/sites/team1 
-filename c:\backups\team1.bak 
-includeusersecurity -updateversions 1

In this example, the imported versions of objects were added to the existing objects, instead of overwriting them. In addition, all file permissions were retained. The SharePoint Products team does not recommend using command-line migration for bulk backup and restore because doing so is CPU intensive. Instead, use command-line migration to move content between farms, as when recovering content using an alternate server farm. Alternatively, some organizations script this command to back up high-profile sites and site collections.

Tip

You can import and export subsites when using Stsadm.exe with the -import and -export parameters. Doing so is not possible with Stsadm.exe using the -o backup and -o restore options.

When using stsadm.exe -o export, you can define the following parameters:

• -url   The -url parameter specifies the site collection to be exported; for instance, http://portal.contoso.msft.

• -filename   The export file is created with the name Filename.cmp, or you can specify a filename extension, such as .bak.

• -overwrite   This optional overwrite parameter causes previous export attempts to be overwritten. If the overwrite parameter is not used, both the .export.log file and the .cmp file from previous attempts must be deleted or the process will fail.

• -includeusersecurity   The optional -includeusersecurity parameter causes groups and group membership information to be included, as well as preserving timestamps, security information, and users.

• -haltonwarning   The optional -haltonwarning parameter stops execution when a warning is encountered.

• -haltonfatalerror   The optional parameter -haltonfatalerror stops execution when a fatal error occurs.

• -nologfile   The optional -nologfile parameter prevents the creation of a log file.

• -versions   The optional -versions parameter defines which versions of files and list items will be exported. There are four versioning options.

  1. Option 1 exports only the last major version for files and list items. This is the default setting.

  2. Option 2 exports the most current version, either major or minor.

  3. Option 3 exports both the last major and last minor versions.

  4. Option 4 exports all versions for file and list items.

• -cabsize   The -cabsize parameter specifies the maximum file size, in megabytes, for the Content Migration Package (.cmp) file. The default file size is 25 MB, and the maximum size is 1024 MB.

  Tip

  To export content larger than the default 1024 MB limit, use Stsadm.exe to increase the default template size in bytes:
  stsadm -o setproperty -pn max-template-document-size -pv 30000000

• -nofilecompression   In addition to not compressing the file, the optional -nofilecompression parameter causes a directory with the appropriate XML files to be created instead of a .cmp file.

  Important

  You cannot import from an NTFS directory created with the nofilecompression option.

• -quiet   The optional -quiet parameter suppresses output to the console, except for a notification on completion.

When using stsadm.exe -o import, you can define the following parameters:

• -url   The URL parameter specifies where to import the Content Migration Package (.cmp) file to; for example, http://portal.contoso.msft.

• -filename   The filename parameter specifies the name of the file to import from.

• -includeusersecurity   The optional -includeusersecurity parameter causes groups, timestamps, security information, and user information to be imported.

• -haltonwarning   The optional -haltonwarning parameter stops execution when a warning is encountered.

• -haltonfatalerror   The optional -haltonfatalerror stops execution when a fatal error occurs.

• -nologfile   The optional -nologfile parameter suppresses the creation of a log file.

• -updateversions   The -updateversions parameter specifies how versions will be merged on import and has three options:

  1. Option 1, the default, adds new versions to those that already exist in the .cmp file.

  2. Option 2 overwrites the file and all its versions, keeping only those already in the destination.

  3. Option 3 causes files that already exist in the destination to be ignored.

• -quiet   The optional -quiet parameter suppresses output to the console except for a notification on completion.

Disaster Recovery

When content level recovery methods do not work or when you have a complete farm failure, disaster recovery methods should be used to restore content. Be aware that disaster recovery methods may cause a loss of data. For example, if you restore a content database from a previous night’s backup, all content written to that database since that backup occurred will be lost. For this reason, always attempt a restore using a content recovery method first.

Note

All native SharePoint Products tools must be backed up to a disk drive. You must use an additional backup program, such as Windows Server 2003 Backup or Restore, to move that content to tape.

Using Central Administration Backup and Restore

The new backup and restore tool for Windows SharePoint Services 3.0 and SharePoint Server 2007 is greatly improved over the last version. You now have the ability to restore entire farms, including the configuration database. The backup and restore tool even allows restoration to an alternate SQL Server instance to permit alternate server farm restoration and testing. Unfortunately, you still do not have the ability to back up to tape or schedule backups from the GUI. You access the GUI Backup interface from Central Administration > Operations > Backup And Restore > Perform A Backup, as shown in Figure 14-5. On opening the Perform A Backup Web page, you are presented with all of the available components that can be backed up.

Figure 14-5_ To back up or restore SharePoint Products content, browse to Central Administration > Operations > Backup And Restore.

In the following discussion, the term items refers to Web applications, content databases, SSPs, or content indexes and their associated search databases.

Performing a Farm-Level Backup from the GUI

1. Select the item you would like to back up. To back up the entire farm, check the box next to Farm, as shown in Figure 14-6.

   Figure 14-6_ Select the component or set of components you want to back up.

   

2. After selecting the entire farm, all components should be highlighted.

3. Select Continue To Backup Operations.

4. If this is the first backup of the farm, check Full for the backup type.

   Important

   You cannot perform a differential backup of the farm until at least one full backup has occurred. You also cannot perform a differential backup after adding a content database or Web application. Whenever you add any of these components to the farm, you must run another full backup before a differential backup will be successful.

5. You must enter a location to back up to. You cannot back up to tape. The backup location should be in the same domain and shared. The following accounts should have write access to the NTFS directory and File Share:

   • The account authenticated to Central Administration

   • The Farm account (should be the Central Administration application pool identity)

   • The SQL Server instance account, if you are using SQL authentication

   • The SPTimer service account, which should be the farm account in most implementations

6. Select OK.

After selecting OK, the job is scheduled with Owstimer.exe (SPtimer). If your job should fail for any reason, you must manually delete the Timer Job Definition. Failing to do so prevents any further backup or restore from succeeding, whether the backup was initiated from the GUI or the command line.

Deleting a Failed Backup/Restore Job

1. Open Central Administration > Operations > Global Configuration > Timer Job Definitions.

2. Select Backup/Restore in the Title column.

3. Click on the Delete button.

Restoring Items from an Existing Backup

1. Open Central Administration > Operations > Backup And Restore > Restore From Backup.

2. Enter the location where the backup exists. There must be an Spbrtoc.xml file in the root of this backup location, or the restore will fail.

3. Select the backup that contains the item you wish to restore, and select Continue Restore Process. If you use multiple backup locations for disk management and do not see the correct backup listed, you may also change the directory from this interface from the menu.

4. From the Select Component To Restore screen, select the component to restore, such as an individual content database or an entire Web application that includes the IIS Virtual Server and associated content database(s).

5. Select Continue Restore Process.

6. Select the Type of restore you want to perform. You have two choices, as shown in Figure 14-7:

   • Selecting New Configuration allows you to restore the Web application, content database, or both as a different name and thereby recover content. In addition, you can restore the content to a different SQL Server instance.

   • The option Same Configuration actually means Overwrite. It completely overwrites any selected components, such as Web applications and content databases, with the backed-up content.

   Figure 14-7_ You must select New Configuration or Same Configuration to continue. Selecting Same Configuration overwrites your existing content.

   

7. Select OK.

If you choose to restore content to a different SQL Server instance or restore content databases with a different name to the same SQL Server instance, you must associate the content database with a Web application to retrieve the content. Never associate the restored content databases with Web applications that hosted the original content. Site collections, which are stored in those content databases, are assigned a unique identifier (UID) when created. UID conflicts are caused when associating restored content databases with a Web application with which the original content database is still associated. Therefore, always associate content databases that are restored, with the new option, to a different Web application from the one with which they were originally associated.

Important

The only time the configuration database is backed up is during a farm-level backup. The only way to restore the configuration database is by performing a farm-level restore.

Command-Line Farm-Level Backup and Restore

You can also back up your entire farm by using stsadm.exe -o backup -directory, also known as STSADM Catastrophic Mode. Using the -directory command-line option invokes additional options that you can use to back up the entire farm or individual items, such as Web applications or content databases. However, you cannot restore object-level items such as documents. Because you cannot schedule backup jobs from the Central Administration GUI, using the command line is the best way to reliably schedule backup jobs on your server farm. The following is an example of backing up an entire server farm using Stsadm.exe in Catastrophic Mode:

stsadm.exe -o backup -directory 
\\backupservername\backups\ -backupmethod full

This example is the simplest form of backing up your entire server using the Full option. There are several optional parameters you can define when backing up, such as -backupthreads, that are useful and you may use them as well.

The parameters available using stsadm.exe -o backup -directory are as follows:

• -item   The -item option must be used in conjunction with the -showtree option. An item from the list generated by -showtree must be specified and the command run again omitting the -showtree parameter.

• -percentage   The -percentage parameter shows the progress increments on screen. For example, 10 would show the progress in 10% increments.

• -backupthreads   This value should be between 1 and 10. Be careful not to use high thread counts during content indexing or other system maintenance.

• -showtree   The -showtree parameter shows all items that can be backed up. This information can also be found in Central Administration Backup And Restore.

• -quiet   This option suppresses output and is used when scripting backups.

For example, the following command backs up a Web application named Portal and uses five CPU threads for the backup process:

stsadm -o backup -directory 
\\backupservername\backups -backupmethod full 
-item "Portal" -backupthreads 5 -quiet

Automating SharePoint Products and Technologies Backups

1. Create a batch file containing a tested command-line Catastrophic backup string, as shown previously.

2. Open Scheduled Tasks in Windows Server 2003 Control Panel.

3. Add a scheduled task, and click Next.

4. Select Browse and choose the batch file you created in step 1.

5. Name the Task; SharePoint Server backup, for example.

6. Select the frequency, usually Daily, and click Next.

7. Select the Start time. Be careful not to overlap with content indexing or other scheduled system maintenance.

8. Click Next.

9. Enter the username and password to execute the scheduled task. This user must have write access to the backup share destination and be a farm administrator.

10. Click Finish.

Restoring a Server Farm from a Farm-Level Backup

1. Find the backup ID either by running

   stsadm.exe -o backuphistory -directory 
   \\backupserver\sharename -restore
   

   or by viewing the history in Central Administration > Operations > Backup And Restore > Backup And Restore History. Every backup or restore job is assigned a unique identifier.

2. From the 12 Hive\Bin directory, execute

   stsadm.exe -o restore -directory 
   \\backupservername\sharename -restoremethod [ new | overwrite ] 
   -item <item>
   

   If you do not select the item, such as a Web application or content database, the entire farm is restored.

3. If prompted, you must enter the Web application pool identity and associated password for each component restored. Alternatively, you can define these in the script using the -username and -password command-line options.

4. After restoring components to a server farm, it is always a good idea to perform an IISReset on every server in the farm.

From the command line, you also have the option to select a new database server. For example, you would execute the following command to restore databases to a new SQL Server instance named DEV:

stsadm.exe -o restore -directory 
\\backupservername\sharename -restoremethod new 
-backupid <id> -newdatabaserver DEV

Command-Line Site Collection Backup and Restore

If you used the previous versions of SharePoint Products, you may be familiar with the stsadm.exe -o [backup | restore] commands. Without the -directory option, Stsadm.exe backs up and restores site collections instead of farm-level components. Although using Stsadm.exe to back up and restore site collections does indeed do a complete backup of these site collections, it does not back up any configuration database information, content indexes, or search databases. It is possible to back up an SSP’s site collection with Stsadm.exe, but the restoration will not be complete. For this reason, only use stsadm.exe -o [backup | restore] to back up and restore standard site collections.

To back up a site collection using Stsadm.exe, execute the following from the 12 Hive\Bin directory:

stsadm.exe -o backup -url <Site Collection URL>-filename*<backup file name>*

The URL should include the site collection name—for example, http://portal.contoso.msft/sites/accounting—if accounting is a site collection. You can also include the -overwrite option if you wish to write to the same file repeatedly. This backup file can be restored to the same server farm or to another server farm.

To restore a site collection using Stsadm.exe, execute the following from the 12 Hive\Bin directory:

stsadm.exe -o restore -url*<Site Collection URL>-filename<backup file name>*

Although it is possible to restore this site collection with a different URL, thus creating a cloned site collection in the original Web application, doing so introduces the possibility of a site collection ID conflict. When a site collection is created, it is assigned a Unique ID in the server farm. You should remove or overwrite the original site collection if you need to restore the backup to the same Web application.

Restoring Application Server Roles to the Farm

There may be times when you need to restore individual physical servers to a farm. Remember that most application server configuration data are stored in the configuration database. So, if the server farm is intact and you have only lost a single server, restoration is usually a simple matter. This section provides an overview of restoring a single physical application server to a farm.

Restoring Index Servers

Content indexes cannot be restored with an Window Server 2003 operating system backup and restore. The only way to restore content indexes is by using SharePoint Products Backup And Restore to restore the entire Shared Services Provider (SSP) that managed a single content index. Therefore, if multiple indexes existed on an Index server, you would have to restore each SSP that managed each of those individual content indexes. As part of this restore process, the associated Search database is restored as well. If either the content index or search database fails during restore, you must reset the index and re-crawl all content sources before search and indexing will resume successfully.

Resetting and Re-crawling All Content Sources After a Failure

1. Open Shared Services Provider Administration.

2. Open Search Settings.

3. Select Reset All Crawled Content, as shown at the bottom of Figure 14-8.

4. Open Content Sources And Crawl Schedules.

5. From the Quick Launch, select Start All Crawls.

   Figure 14-8_ Resetting all crawled content does not automate the rebuilding of the content index.

   

If you use a third-party tool to back up your SharePoint Products implementation, it is still wise to use the native tools to back up your Shared Services Providers; doing so ensures the ability to restore your content indexes successfully. If your indexes are quite small, you can simply add a new index server to the farm, associate it with an SSP, and use the previous numbered list to re-crawl all content sources.

Restoring a Shared Services Provider and the Associated Content Index

1. Open Central Administration > Operations > Backup And Restore > Restore From Backup.

2. Select the backup location that contains the most recent backup of this SSP.

3. Select the desired existing backup, and choose Continue Restore Process from the menu.

4. Select the SSP that managed the content index you wish to restore.

5. Select Continue Restore Process from the menu.

6. Select either a New configuration or Same (overwrite) configuration. You will usually select the Same configuration.

   When selecting the Same configuration, you must enter the farm account’s username and password and the SSP application pool identity username and password when using SQL Server authentication. Otherwise, the restore process uses your currently logged-on account for authentication.

7. Click OK.

Restoring Query Servers

Query servers that are dedicated to the service are updated automatically after a server or server farm failure if the following are true:

• They connect to the server farm configuration database.

• The original index location exists.

• The file share for propagation is configured correctly.

If dedicated Query servers do not function after a failure, the simplest way to restore them is to remove the server from the farm, re-add the server to the farm, and follow the steps in Chapter 13, “Scaling Out to a SharePoint Technologies Server Farm,” to add a Query server to a farm.

Generic Application Servers

The settings for Document Conversion Launcher Services, Document Conversions Load Balancer Service, and Excel Calculation Services server roles are stored in the configuration database. Therefore, simply adding any of these application servers back to a farm will re-enable them as application servers. Alternatively, you can rebuild these servers and run the SharePoint Products and Technologies Configuration Wizard to add them back to the server farm. Remember to enable the correct services in Central Administration > Operations > Topology And Services > Services On Server after running the wizard.

Likewise, the Windows SharePoint Services Help Search server can be restored in much the same manner. You can always select the Windows SharePoint Services Help content in a farm-level restore, but you may alternatively add a new server to the farm and enable it to service this role from the Farm Topology Web Part.

Backing Up Other Required Content

In addition to backing up all SharePoint Products content, you must also back up information that is not stored in the configuration or content databases. The following items must be backed up independently of your SharePoint Products and Technologies backups.

Operating System Files

Using the native Windows Server 2003 Backup or Restore tool, you can back up all files on the server including the system state. Verify in your complete operating system backup that you include the following:

• System State   Verify you are backing up the System State that includes the Certificate Store and system logs. These are required to restore a server to a functional state, should the server fail.

• 12 Hive   You must also verify you are backing up the 12 Hive at \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\. All customized site definitions and trace logs are located there.

• SharePoint Server Binaries   Configuration items, such as your Search and Indexing noise word files and thesaurus files, are located in the \program files\Microsoft Office Servers\12.0\ directory.

• Inetpub Folder(s)   By default, this folder is c:\inetpub\wwwroot. Wherever this folder resides, be sure to include it in your backups because the subdirectory \wss\VirtualDirectories includes all of your Web application specific information. For example, you may have modified the Web.config file in these directories to change authentication or allow a longer timeout for uploading large files.

IIS Metabase

You must back up the IIS Metabase on each Web front-end (WFE) server in the farm. The IIS Metabase includes such information as SSL certificates, assigned IP addresses, and multiple host headers. Because this information is not stored in the configuration database, it is not restored when using the native SharePoint Products backup and restore tools.

Backing Up the IIS Metabase

1. Open Internet Information Services (IIS) Manager from Start > All Programs, Administrative Tools.

2. Right-click on the server name and select All Tasks > Backup/Restore Configuration, as shown in Figure 14-9.

   Figure 14-9_ Right-click on the IIS Server name to begin the backup and restore process.

   

3. Select Create Backup.

4. Enter an easy-to-remember configuration backup name, such as the server name plus the backup date. For example, use WFE0106222007 for a server named WFE01 and a backup date of June 22, 2007.

5. Optionally, select Encrypt Backup Using Password. This allows the backup to become “portable,” thus giving you the ability to restore the IIS Metabase to any server. Choose a simple password, such as PASSWORD, that is documented and all members of the IT staff know. This password is primarily for portability, not for security.

   Note

   If you wish to restore the IIS Metabase to another server, you must change or remove machine-specific information in the backup file. This process is explained in detail at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/IIS/21972953-44d3-4177-b0d2-f8e2cdef2efd.mspx?mfr=true.

Backing Up and Restoring the IIS Metabase from the Command Line

1. Either on every WFE server in the farm or on a centralized backup server, create a batch file with the command:

   cscript.exe %systemroot%\system32\iisback.vbs 
   /backup /s Web1 /u administrator /p password 
   /b WeeklyBackup /v NEXT_VERSION /e backuppassword
   

2. In the previous command, Web1 was the target server, administrator was the username, password was the username administrator’s password, WeeklyBackup was the backup type, and NEXT_VERSION appended a version number, such as 2, to the backup name. Optionally, you may use the /e flag to include a backup password, thus making the backup portable.

3. Add as many lines to this batch file as necessary to back up all WFE servers in the farm. Each backup will reside in the respective WFE server’s %systemroot%\system32\inetsrv\ directory.

4. Schedule this backup from the Windows Server 2003 Control Panel using Scheduled Tasks. Simply add a scheduled task by browsing to the batch file you just created and selecting the desired schedule. Verify that the username and password that will run the task have permissions both to back up the server farm and to have write access to each WFE server.