Backing Up and Restoring SharePoint Server 2007

There are several methods of backing up and restoring SharePoint Server 2007 content, and you should use a combination of these methods as needed for complete protection. You should test each of these in your environment and see what combination works best for you. Table 30-1 provides an overview of the methods available and their advantages and disadvantages.

Table 30-1: Disaster Recovery Methods for SharePoint Server 2007
Open table as spreadsheet

Method	Ease of use	Operates on	Notes
Versioning	Document library feature	Documents Lists Web pages	Native functionality.
Recycle Bin	Easy end-user interface	Lists List items Document libraries Documents	Not for disaster recovery.
Stsadm.exe	Requires script	Site collections Sites	Best for restoring sites.
Central Administration backup Farm Web application Content database	Graphical user interface (GUI) or command line	GUI is easy to use. Command line is required for scheduled backups.
SQL backup	Complex, but complete	Databases only	Full fidelity. Must recrawl content.
Mirror farm	Very complex	Content only	Fastest disaster recovery failover.
Microsoft Volume Shadow Copy Service Writer	Server backup/restore	Farm level Individual restore	Requires Microsoft SQL Server 2005 and 'Longhorn' Server.

There are two primary methods of recovering content in SharePoint Server 2007: content recovery and disaster recovery. Content recovery should always be considered before resorting to disaster recovery methods. Content recovery methods are usually quick and easy, allowing faster return to service than disaster recovery methods. Examples of content recovery are using the native versioning and recycle bin functionality. Disaster recovery methods are used when all other options have failed, or there is a loss of hardware due to natural or man-made disasters. Disaster recovery usually means some loss of data, but this can be minimized with diligent preparation. Examples of disaster recovery are database restores and system rebuilds.

Performing Content Recovery

Content recovery refers to common activities performed to restore data, usually from accidental deletion or data corruption. Depending on the severity of the data loss, there are three standard methods for recovering data: document versioning, two-stage Recycle Bin, and the command-line tool stsadm.exe. There is also a custom option called Web Delete Event, but it requires custom development. With this feature, you can automatically back up a site in the event of site deletion. Although this could be a great feature for critical sites, it is probably a bad idea to use it for enterprise-wide implementations because it doesn't scale well.

Document Versioning

The most common method for restoring corrupted content is the native versioning functionality available in all document libraries in SharePoint Server 2007. This functionality is disabled by default, but enabling this feature provides several improvements over the basic versioning in SharePoint Portal Server 2003. Examples of the improvements are limiting the number of minor and major versions, forcing approval and archival before deletion, and forced checkout. Document versioning is your first line of defense against data corruption and user changes. Be cautioned-if users have the ability to modify a document, they can delete it. Document versioning does not protect content; it only preserves history by saving a copy each time the content was saved. If a document is deleted, it must be recovered from the Recycle Bin.

Two-Stage Recycle Bin for Documents and Lists

One of the most anticipated features of SharePoint Server 2007 is the two-stage Recycle Bin, which is enabled by default. This should be your first method for restoring deleted files, and it is the easiest of the tools to use for recovering content. The Recycle Bin is envisioned to be primarily controlled by the end user, but site administrators can always restore files in the event of first-stage deletion. Remember-the Recycle Bin is a function of a Web application, not a site collection. You can modify the Recycle Bin settings by opening Central Administration, then Application Management, then Web Application Settings and scrolling down to the bottom of the page. You can modify the settings for both stages of the Recycle Bin, as shown in Figure 30-3

Figure 30-3: Two-stage Recycle Bin and configurable options

If you disable the Recycle Bin, as shown Figure 30-3, all Recycle Bins in that Web application are emptied, freeing up all disk space occupied by Recycle Bin content. This behavior is useful in an out-of-storage emergency, but otherwise it is best left alone. This should only be done when there are no other options, and should be re-enabled after your disk problem is resolved.

The Recycle Bin is a great content recovery tool, but it is not meant for disaster recovery. The Recycle Bin nearly eliminates the need for other restore methods when objects are deleted. By default, the second stage of your Recycle Bin is limited to 50 percent of your site quota, but it should be lowered to fit your storage needs. Raising this quota should be carefully considered given that incorrect stage configurations can waste large volumes of disk space. Keep in mind your site administrators have the ability to permanently delete objects in site collections. This is another reason to choose administrators for your critical sites carefully and provide all site administrators with adequate training.

Command-Line Tool stsadm.exe

In the directory %SystemDrive%\Program Files\Common Files\Microsoft Shared\Web server extensions\12\BIN resides the very powerful command-line tool stsadm.exe. Many SharePoint administrators include this directory in their system path for ease of use. Alternatively, you can create a batch file in %SystemRoot% that changes to that directory for you. The stsadm.exe command-line tool retains all the functionality from SharePoint Portal Server 2003 in addition to providing many of the new features in SharePoint Server 2007.

Site Migration

One of the new features of stsadm.exe is the replacement of smigrate.exe with stsadm.exe using the -o [import | export] options. Here is an example of exporting a site with stsadm.exe:

 stsadm.exe -o export -url http://portal.contoso.msft/sites/HR -filename c:\OSSBackups\HRBackup.bak 

stsadm.exe, when used with the [import | export] option, is primarily a tool for developers moving or restoring content, as well as for administrators who might incrementally migrate sites. Monitor system usage carefully when frequently exporting or importing large sites because stsadm.exe is a very process-intensive application. Using this tool to consistently to back up large, busy site collections is not recommended. Here is a list of commonly used options when using the -o [export | import] option for exporting and importing sites:

• -url <URL to be exported>

• -filename <path and filename to export> (can append with -overwrite)

• -includeusersecurity (using this flag will include the permissions associated with object)

• (export only) -versions (1 = last major, 2 = current, 3 = last major and minor, 4 = all versions)

• (import only) -updateversions (1 = add new version to current, 2 = overwrite, 3 = ignore, 4 = terminate with conflicts)

Site Backup and Restore

You can also use stsadm.exe to back up and restore individual site collections when using the -backup option. Using this option creates full site backups that can be restored to any SharePoint server farm of the same version, with the added benefit of restoring the site with a different name. Having recent copies of site collections from stsadm.exe can dramatically decrease the amount of time required to restore object-level content when deleted. For example, items emptied from the second stage of the Recycle Bin, or Web pages deleted from a site collection, can be restored from a full-fidelity backup created with stsadm.exe -o backup. Be cautioned, backing up with this method is very processor intensive and might require large amounts of disk space. It does not scale well and should be used only on small farms or on your most critical sites. The following is an example of backing up a site using stsadm.exe:

 stsadm.exe -o backup -url http://portal.contoso.msft/sites/HR - filename c:\OSSBackups\HRBackup.bak 

You can create a Microsoft Visual Basic script or batch file and use Scheduled Tasks in Control Panel to automate the process. The following options are commonly used when using the -o [backup | restore] option for backing up and restoring sites using stsadm.exe:

• -url <full URL> (for example, http://portal.contoso.msft/sites/HR)

• -filename (Include the path; this can be a drive letter or Universal Naming Convention name)

• -overwrite (using the overwrite flag will completely overwrite the destination)

The stsadm.exe backup and restore options are useful when restoring data that has been deleted, in spite of the protections offered by document versioning and the second-stage Recycle Bin. When this occurs, you must restore the entire content database containing the deleted items and restore the data to an alternate server farm.

Real World Restoring Content to an Alternate Server Farm

If you lose content that must be restored from farm-level backups, you have two choices: restore the content databases from the last backup and overwrite all current data, or restore content databases to a secondary farm and migrate them into the production farm. The first choice isn't generally acceptable, so this section will focus on restoring to an alternate server farm. Most organizations have a test environment, and this is the first logical location to use when attaching content databases and retrieving previously backed-up content. The following steps allow you to restore data from a farm-level or SQL Server database backup and restore it to the production server farm:

1. Restore the content database that held the deleted content to another SQL server or to a different database name if restoring to the same SQL server.

2. Attach the content database to a Web application by opening Central Administration, then Application Management, then SharePoint Web Application Management, and finally Content Databases, as shown in Figure 30-4.

3. When you attach a content database to an existing Web application, the sites are automatically populated in the configuration database.

4. If you need only a single file, retrieve the file using the same URL as for the production server, replacing the server namespace. For example, if the URL for the production server is http://portal.contoso.msft/sites/HR and the URL to your test server is http://test.portal.contoso.msft, browse to http://test.portal.contoso.msft/sites/HR to retrieve the file.

5. If you need to restore an entire site, use stsadm.exe to back up from the test server and restore to the production server. For example, if your disaster recovery name is OSSBackups and your test server is http://test.portal.contoso.msft, use the following command:

    stsadm.exe -o backup -url http://test.portal.contoso.msft/sites/HR - filename \\backupservername\OSSBackups\HRBackup.bak 

   To restore the site with the original version history and permissions, run the following command from your production server:

    stsadm.exe -o restore -url http://test.portal.contoso.msft/sites/HR - filename \\backupservername\OSSBackups\HRBackup.bak 

Figure 30-4: Attaching a content database to a Web application

Both server farms must be in the same Active Directory domain. If they are not, you will lose all site-level and object-level permissions when restoring to the alternate server farm.

Performing Disaster Recovery

Many IT professionals today consider the entire methodology of backing up and restoring disaster recovery, but this section is specifically tailored to providing restoration of services after hardware failure, man-made disasters, or natural disasters. SharePoint Server 2007 now offers four methods of backing up data when preparing for disasters:

• Central Administration Backup/Restore utility

• Command Line Backup/Restore utility

• SQL Server backups and restores

• Volume Shadow Copy Service Writer in Windows Server "Longhorn"

This section will cover each of these methods and end with a section on backing up Microsoft Internet Information Services when using SharePoint Server 2007.

SharePoint Server Native Backup and Restore

A benefit of upgrading to SharePoint Server 2007 is that you gain the ability to back up and restore content directly from the Central Administration Web application. This is a very powerful tool, but it is primarily used when restoring content because it lacks the ability to schedule jobs from the user interface (UI). Administrators who want to schedule backups must create scripts using the command-line tool and schedule the script from Control Panel.

File Location

The native backup functionality in SharePoint Server does not provide a method of backing up data to tape. When using either the Central Administration UI or the command-line backup interface, you must back up data to a Universal Naming Convention (UNC) share. The backup process automatically creates subfolders in this share for each subsequent backup. It is very important that the SQL setup server account is using a domain account and that each farm server has direct access to this file share.

Note 

If there are any errors when using the Central Administration UI, you must delete the timer job at http://<adminsite:port>/_admin/ServicejobDefinitions.aspx before successfully beginning any new backup/restore jobs. Otherwise, you receive the error, "The same item is already in the process of being backed up." You can find details of the associated errors in the Spsbackup.log file located in the root of the previously defined UNC.

The following accounts require Change and Read share permissions on the target file share, and all NTFS security permissions, with the exception of Full Control:

• The account authenticated to Central Administration when using the UI

• The logged-on account when manually running stsadm.exe

• The Run As account when scheduling scripted backups in Control Panel

• The Central Administration pool account in Internet Information Services, as shown in Figure 30-5

• SQL Server account, if Local System is the SQL service account

• The SPTimer service account, if using the Central Administration UI (by default, the same account used by the Central Administration application pool)

Figure 30-5: Verifying Central Administration IIS application pool account information

Best Practices 

It is best to use a centrally located file share for backups, and they should be accessible by all production and test servers and backed up on a regular basis. This can be the same file share used for SQL Server database dumps, but be careful of overloading storage spindles or network bandwidth if multiple backups are occurring simultaneously. Large organizations are best served by using a storage area network (SAN), with the UNC served from a Windows Server, for this purpose.

User Interface

Using the Central Administration UI is the easiest way to back up your farm for disaster recovery. Upon opening the Operations tab in Central Administration, you select Perform A Backup to begin the process. Figure 30-6 shows an example of components available for backup using the UI.

Figure 30-6: Components available in the backup and restore UI

You can also specify a location for your file backups when using the Perform A Backup UI. If you need to change this location at a later time, be sure to leave your original backup location available for the length of time required to meet your SLAs. If you need to restore from a previously created backup source, change the location when viewing the backup and restore history.

Important 

You cannot perform a differential backup of the entire farm when a new Web application is created. You must perform at least one full backup before successfully completing a differential backup, whether using the UI or the command-line tool.

The downside to using the Central Administration Restore From Backup UI is the inability to restore items at the object level within site collections. Refer to the earlier sidebar on restoring content for a solution to use when restoring to an alternate server farm.

Farm-Level Backup and Restores with stsadm.exe

New in SharePoint 2007 is the ability to perform farm-level and Web application-level backup and restore from the command prompt. Farm-level backup and restore, also referred to as catastrophic backup and restore, is defined by using the -directory switch using stsadm.exe. The following is an example of a farm-level backup in its simplest form:

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

Backups

Backing up using this method prevents SPTimer job errors and assures you that your backups won't fail. In addition, it provides a method for automated scripting and scheduling capabilities. The following are options when using stsadm.exe for farm-level backups.

• Mandatory

  q

  -directory <UNC path> The UNC path should be created on a server in the same domain, with share and security permissions set as previously defined.

  q

  -backupmethod <Full | Differential> At least one full backup should be performed on a new farm or when adding a new Web application. Be cautioned that all previous differential backups are required when restoring content. For this reason, best practices should be followed when using differential backups. More information can be found by going to http://www.microsoft.com/technet/windowsserver/default.mspx and searching for disaster recovery.

• Optional

  q	-item This option allows the backup of a single Web application. Information must be entered exactly or the backup will fail. The following is an example of using -item if Portal is the Web application to back up: stsadm -o backup -directory \\backupservername\backups - backupmethod full - item "Farm\Windows SharePoint Services Web Application\Portal"
  q	-percentage The percentage option controls the granularity of on-screen feedback as the operation progresses. If you are scripting, this is of no value.
  q	-backupthreads If you have a large implementation and require significant throughput on your backups, this option can increase the amount of processing time allocated to backups. Be careful, increasing this on a production server can degrade the quality of service experienced by the end user.
  q	-showtree The showtree option is primarily used to define single items that you want to back up, but it is also useful for providing a comprehensive view of your server farm.
  q	-quiet This option suppresses output.

Restoring

Restoring from a previously created backup is accomplished by using one of the following two methods:

• Restoring to the same farm

• Restoring to an alternate farm

You need not change anything in your backup procedure-the same source media is used either way. The following options are available when using stsadm.exe for restoring to the same farm.

• Mandatory

  q	-directory <UNC path> The directory that contains specific backup data you want to restore.
  q	-restoremethod <overwrite | new> Using overwrite restores over existing data, and all content is lost. The new option allows you to back up to an alternate name, recovering data as required.

• Optional

  q	-backupid <ID from backuphistory> This option can be found by using the following command: [stsadm.exe -o backuphistory -directory <UNC path> -backup]
  q	-item This option restores a single Web application.
  q	-percentage This option shows the granular process status of the restore.
  q	-showtree This option shows content available for restores.
  q	-suppressprompt This option uses the current username and password for username/password prompts.
  q	-username This option assigns the username for the Web application process account.
  q	-password This option assignes the password for the Web application process account.
  q	-quiet This option suppresses output.

Restoring to an Alternate Server Farm

Restoring to an alternate farm using the command-line tool is similar to restoring to the same farm, but there are some differences. The first difference is the option to restore the configuration database. Restoring the configuration database to an existing server farm can cause severe failures, sometimes beyond repair. Use [-restoreconfigurationdatabase] only as the last option on the same farm. You use this primarily when installing or migrating to a new server farm. Note that all noncommitted configuration database transaction logs will be rolled back if this option is used, and all content in those transaction logs will be permanently lost. The following are additional options to use when restoring to an alternate server farm:

• -restoreconfigurationdatabase This option is particularly useful for complete farm restoration on an alternate server farm. Use this restore option in conjunction with an IIS Metabase backup and complete restoration of the farm. It can be used with the -newdatabaseserver option and requires that Named Pipes be enabled on the destination SQL Server.

• -newdatabaseserver This option is most likely used when restoring the entire farm to a different set of hardware. It can also be used for restoring to an alternate location when choosing not to use database mirroring, transaction log shipping, or SAN replication for business continuance.

The -newdatabaseserver option gives you the ability to restore to a new database server. Again, this option should be used only in worst case situations or when migrating content to a new database server.

SQL Server Backup and Restore

If you could back up only one server in your SharePoint Server 2007 server farm, it would be the SQL server that hosts your content databases. This can be accomplished by using the previously discussed farm-level backups, or through direct SQL Server backups. Although by backing up this server alone you would lose customizations on the WFE servers or content indexes in the event of a catastrophe, you would retain all your valuable content from site collections. Whichever combination of methods you choose to back up your server farm, complete SQL databases are the foundation.

Note 

Office SharePoint Server Central Administration backup and restore, along with stsadm.exe in catastrophic mode (catastrophic mode is when invoking farm-level backups with the -directory option), back up SQL databases and truncate transaction logs. This is a huge advancement from SharePoint Portal Server 2003 and negates the need to periodically back up databases, therefore truncating logs, with SQL Server.

Although the native backup tools now back up your databases, many large organizations might use SQL backups as their primary method for restoration in a disaster. Backing up using existing SQL Server procedures might allow for reuse of a pre-existing disaster recovery plan. If you decide to use SQL backups, be sure to verify all content databases using Central Administration.

In SharePoint Portal Server 2003, 50 gigabytes was the recommended maximum size for a database. The primary reason for this limit was the time it took to restore databases in the event of a disaster. With the improvements in SharePoint Sever 2007, there are no limits within the confines of SharePoint technologies. There are limits with SQL Server, however. An example is the 2-terabyte limit on databases when using Microsoft Clustering for fault tolerance. Before you let your databases grow larger than 50 gigabytes, determine the rate at which you can restore them and verify you will meet any SLAs in place. For example, a database size of 2 terabytes could take longer than seven hours to restore, even if you are using high-speed tape or backup to disk technologies. In these instances, using SAN snapshots or SQL Server transaction log shipping should be investigated.

Note 

If you have multiple, very large databases on a SAN, you could benefit from disk pivoting. Disk pivoting is when SQL Server backups are dumped to a SAN logical unit (LUN) attached to your SQL Server Active node in a cluster. Using SAN technology, this LUN is then moved to the Passive node and backups to media performed there. This approach uses the often wasted processing power of the passive node while increasing available resources on your active SQL Server node.

Internet Information Services Backup and Restore

The foundation of Internet Information Services (IIS) is the Metabase. The Metabase is a plain-text XML file that is usually modified via the IIS Manager application. The Metabase is the repository for IIS configuration data and is included in system-state backups selected from the Windows Server Backup Or Restore Wizard. The problem with this method of backing up the Metabase is that the entire system state must be restored, including the system registry. Although this is fine when a system is completely restored from bare metal, it is unacceptable when restoring only the Metabase. To overcome this limitation, you should back up all your IIS Metabases regularly and have them included in your backup routine. Create a batch file and schedule it as a weekly activity from Control Panel. The following is a sample batch file that backs up multiple IIS Metabases from a single location to their respective host's %systemroot%\system32\inetsrv\ directory:

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

In this example, Web1 is the system being backed up, administrator is the username, WeeklyBackup is the name of the backup, and NEXT_VERSION defines how the backup file is incremented. You can add as many lines to this file as required for IIS servers in your environment. The resulting backups on multiple servers will be in their respective %SystemRoot%\System32\Inetsrv\ directories.

Note 

Back up the Metabase with a password. Doing so allows the Metabase to be restored to a different Windows Server if needed. Using the password option makes the Metabase portable, whereas not using the password means that the Metabase can be restored only to that particular instance of IIS. See http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/.mspx?mfr=true for complete details.

Another commonly overlooked component when planning for IIS disaster recovery is your Secure Sockets Layer (SSL) certificate. Many organizations use third-party certificate authorities for browser compatibility and verifiable security. If you lose a server and do not have the certificate backed up, interaction by the certificate vendor will be required if you cannot restore the IIS Metabase. Back up your SSL certificate whenever you are renewing or installing it. This can be done by viewing and exporting your certificate with the private key. Without the private key, you cannot reassign this certificate in the future. Use the same file location as your system images, patches, and other disaster recovery content.

More Info 

To export the private key, reference http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/.mspx?mfr=true for more information.

Implementing Fault Tolerance

If days or weeks are too long to wait to recover from a disaster, consider implementing some form of fault-tolerance. Many organizations that serve critical functions from their SharePoint Server 2007 installations implement some form of fault tolerance. Many times the failover server farms are smaller and less expensive, albeit in a degraded state. This is an acceptable solution for most implementations, but verify that you don't have a requirement to build identical server farms. This section will assist you in planning and implementing several forms of fault tolerance with several levels to meet your needs and budget.

Web Application Load Balancing

The first step in creating simple and affordable disaster recovery is by scaling your WFE servers to handle hardware or service failure. Windows Server includes native functionality for load balancing servers and creating a virtual IP address (VIP) that is used for user connections. You can have up to 32 servers in a Network Load Balancing (NLB) configuration, but it is recommended that you have no more than eight WFE servers per SQL server, so this limitation shouldn't be applicable. Implementations larger than this can benefit by using multiple namespaces, SQL Server clusters, and possibly multiple server farms. If SSL is being used, Microsoft Internet Security And Acceleration Server can be used to terminate SSL connections, thereby reducing processor utilization on your WFE servers.

SharePoint Server 2007 also provides the option to make a WFE server a standalone server. This option allows WFE servers to be dedicated to serving Web content with no other SharePoint Server applications installed. This arrangement increases performance because application services, such as Excel Calculation Services or Search, are performed by other servers. Note that standalone WFE servers cannot be upgraded to accommodate application services in the event of a disaster. You need to uninstall and reinstall, choosing the complete option in the SharePoint Products and Technologies Configuration Wizard.

Figure 30-7: Using Windows Server Network Load Balancing

More Info 

More information on Network Load Balancing can be found at http://technet.microsoft.com/WindowsServer. Search for NLB or clustering for detailed information for your implementation.

Application Server Load Balancing and Fault Tolerance

High availability for an Application Server is implemented differently than fault tolerance for a WFE. While WFEs use NLB to provide fault tolerance, the SPTimer service manages the traffic destined for application servers. Simply creating multiple Excel Calculation Services servers, for example, implements basic load balancing and fault tolerance for Excel Calculation Services in your farm. Query services are, by default, provided by the WFEs, so additional Query servers are not required unless you have specific search needs. You can have standalone Query servers, but this approach is not recommended unless it is driven by absolute business requirements.

SQL Server Clustering

Creating a load balanced Web front-end cluster is a great start, but having this cluster serve content from a standalone SQL server is of little use when the SQL Server hardware fails. Most medium scale and larger SharePoint 2007 implementations require a SQL Server cluster for fault tolerance.

In a basic two-server Active/Passive cluster configuration, a SQL Server cluster does not provide enhanced performance, only fault tolerance. This fault tolerance provided by SQL Server clustering can take several seconds to several minutes to fail over, depending on the size of your databases and transaction logs. Note that all transaction logs must be replayed when the passive node is made active. If you have large amounts of untruncated data, this failover could take several hours. Refer to SQL Server best practices at http://www.microsoft.com/sql for information on configuring and truncating transaction logs. Frequently truncating transaction logs increases SQL Server CPU and disk utilization, but it minimizes the failover time in the event of an SQL Server cluster active node failure. Figure 30-8 shows the configuration of a basic SQL cluster.

Figure 30-8: SQL clustering with SharePoint Server 2007

More Info 

For more information on clustering SQL servers, refer to http://www.microsoft.com/technet/windowsserver/default.mspx and search for clustering.

SQL Transaction Log Shipping

SQL transaction log shipping is a function of the SQL Server agent that backs up and restores transaction logs to a failover SQL server. The basic idea behind log shipping is that you have a "warm" failover farm introducing minimal delays in the event of a primary farm failure. All updates to your primary SQL Server content databases are replicated to a failover SQL server. This arrangement requires advanced SharePoint Server 2007 configuration of the failover farm. The following task list provides a starting point for doing this:

1. Make sure you are using the same domain and accounts for all similar processes (Farm, SSP, IIS processes, SQL SA account).

2. Make sure you are using the same version (including updates) of SQL Server on both farms.

3. Document content database to Web application mappings.

4. Create the failover farm using a second SQL server (not a second instance).

5. Make sure you are using identical, corresponding content database names when creating Web applications on the second farm.

6. Do not log ship config or Central Administration databases.

7. Ship logs to second SQL server, and verify integrity.

8. Take primary farm offline to test.

9. Bring failover farm content databases online.

10. Bring failover farm online.

11. Browse using a different namespace, change DNS, or purchase third-party software.

12. Use the same TCP port for both Central Administration Web applications for ease of configuration.

When using log shipping, it is important to overwrite the primary databases with the failover databases before bringing the primary server farm back online. Not doing so loses changes made on the failover farm when the primary farm is brought back online. Figure 30-9 is an example of log shipping when both farms are located at the same geographical location.

Figure 30-9: Using SQL Server transaction log shipping

As shown in Figure 30-9, transaction log shipping on a single local area network (LAN) can work quite well to provide a failover farm in the event of a catastrophic hardware failure. The downside to transaction log shipping is the manual intervention required on the failover server farm, because the databases will be in recovery mode and must be brought online manually. The failover server farm must also be taken out of quiesced mode in Central Administration. Remember to change any settings in your DNS servers to publish the new farm's IP address, or educate users of a second namespace that can be used in the event of a disaster.

Important 

When using SQL Server transaction log shipping or database mirroring, remember that any errors, such as file corruption or user mistakes, are replicated from the primary farm to the failover farm.

SQL Database Mirroring

A new feature in SQL Server 2005 Service Pack 1, database mirroring, has advantages over log shipping because it is a function of the SQL Server engine and can provide synchronous replication. Database mirroring is more expensive and complex to implement because it requires three SQL servers when configured in synchronous mode. The third server is a "witness" SQL server and provides automatic failover, which is the main advantage over transaction log shipping.

More Info 

For more information on using an SQL witness server, browse to http://msdn2.microsoft.com/en-us/library/ms188712.aspx.

When using database mirroring, you must manually intervene and bring the failover farm online, along with any namespace or DNS changes. Although database mirroring does not require the databases to be copied back to the primary farm (this is done automatically), it does not create secondary backups of databases on the failover farm. This is the main disadvantage compared to SQL Server transaction log shipping. With this in mind, you need to have current backups of your primary SQL Server cluster at your failover site.

More Info 

For detailed information on SQL Server database mirroring, visit http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx.

Hardware Load Balancing

Some organizations find that the native load balancing provided by Windows Server is incapable of providing the granularity of services offered by hardware load balancing. Hardware load balancing can offer options such as session control, immediate failover, reporting, routing, VLAN trunking, and many other options. Keep in mind that hardware load balancing can introduce many complexities into your SharePoint Server 2007 environment because Windows Server is not aware that load balancing is occurring. Organizations that require hardware load balancing need to test for performance and compatibility in a lab before implementing.

Storage Area Networks

A storage area network (SAN) is a great addition to almost any SharePoint Server 2007 farm implementation. SANs vary from very simple frames using iSCSI technology to large, complex systems with multiple storage frames and fiber-channel fabrics. Which-ever SAN solution you choose, be sure to check the Windows Server Catalog at http://www.windowsservercatalog.com to make sure your solution is supported.

Storage area networks provide a convenient way to provision and manipulate disk space for applications. Most storage frames add the benefit of intelligent software that manages bad blocks and sectors, as well as managing mirroring and parity. This offloads processing from the server hardware and minimizes the number of reboots required due to disk failures. With the storage frame software managing bad blocks, the days of waiting hours for chkdsk to run are over. SANs also provide for bit-level backups of your data for disaster recovery and can connect directly to tape subsystems, decreasing the amount of time and bandwidth required to back up your data. Be forewarned that bit-level copies require all information to be restored. The only way to restore object-level items from a bit-level backup is by attaching content databases to a secondary farm. Large enterprises should seriously consider a secondary farm for recovering production data, whether from SAN snapshots or by traditional backup methods.

Many SANs now include functionality to take snapshots of storage and replicate for quick failback of data. This method overwrites all data written from the time of the previous snapshot. You should consider using it only in an emergency, or you should restore data to an alternate location for content retrieval. SANs also provide for data replication that can be used to create warm server farms for business continuance.Warm server farms are powered on with all base software installed and ready to take the place of the primary farm. Before using this method, carefully test and verify that your installation is supported by Microsoft. Most organizations do well using SQL Server transaction log shipping or database mirroring to provide business continuance.