Creating Client Extranets with SharePoint 2003

Last Updated 2/3/2009 3:43:05 PM

This chapter of Creating Client Extranets with SharePoint 2003 covers four complementary backup/recovery techniques, each of which provides insurance against some, but not all, risks to your SharePoint installation. Because no single technique covers all cases, you will most likely use each of them at different times to provide a robust backup and recovery strategy. The techniques covered are:

SQL Server Backup/Restore to recover an entire server
STSADM Backup/Restore to recover a site collection or part of site collection
SMIGRATE Backup/Restore to transfer a site to another location
VSS/File System Backup/Restore to recover or roll back changes to configuration files

'

The last thing you want to be doing after a systems failure is scrambling to recover without a well-thought-out and reliable backup and recovery plan. This is especially important when clients are involved because how quickly service is restored will reflect on all aspects of your business's reputation.'

Unfortunately, configuring database and file backups is like planning for retirement or exercising; it's easy to put off until later, but doing so can have dire consequences! In this chapter, I'll discuss four complementary backup/recovery techniques, each one providing insurance against some, but not all, risks to your SharePoint installation. Because no single technique covers all cases, you will most likely use each of them at different times to provide a robust backup and recovery strategy. The techniques I'll cover are:

SQL Server Backup/Restore to recover an entire server'
STSADM Backup/Restore to recover a site collection or part of site collection
SMIGRATE Backup/Restore to transfer a site to another location
VSS/File System Backup/Restore to recover or roll back changes to configuration files

Having these backup/recovery strategies in place won't eliminate the possibility of systems failure or human error, but will enable you to recover as quickly as possible should an outage occur.

CONFIGURING SQL SERVER BACKUP

Creating regular SQL Server backups of your SharePoint databases will allow you to quickly recover in case of a systems failure; that is, if you need to rebuild the SharePoint database server from the ground up. In this section, we'll cover the steps required to configure SQL Server backups for your SharePoint databases and how to restore those databases. This technique is composed of the following tasks:

Identify the names of the configuration and all content databases in your Windows SharePoint Services installation.

Use the SQL Server Enterprise Manager to schedule periodic backups to another volume or file server.

Periodically back up the SQL Server backup files to tape or other long-term storage medium.

Identify the Names of Configuration and Content Databases

In a default Windows SharePoint Services (WSS) installation, the configuration database will be named sts_config.mdf. The content databases will be named STS_servername_1.mdf, STS_servername_.mdf, and so on.

NOTE: You can change the names of the configuration and content databases during WSS installation, so your database names may differ.

Figure 3-1 shows SQL Server Enterprise Manager for a WSS installation with a configuration database called EXTRANET and one content database called STS_extwss01_1.

NOTE: The term (Windows NT) can be misleading to those unfamiliar with SQL Server Enterprise Manager. This text will appear next to any Windows SQL Server instance, regardless of the version. In all examples in this book, Windows 2003 Server was used.

Schedule Periodic Backups Using SQL Server Enterprise Manager

To schedule periodic backups of the WSS configuration and content databases you use the SQL Server Enterprise Manager backup feature. To access this feature, follow these steps:

Right-click one of the databases to be backed up, choose All Tasks and then Backup Database.

In the SQL Server Backup dialog box's Destination section, click the Add button to specify the location and filename of the backup file. Figure 3-2 shows the completed SQL Server Backup dialog box.

CAUTION: You should specify a backup location that is on a different physical drive and ideally on a different server than your WSS databases. Such a location will ensure against the risk of the physical disk drive containing the WSS databases being unrecoverable due to a hardware malfunction and eliminate the need to move the backup drive to a functioning server in the case of a failed WSS server.

In the Select Backup Destination dialog box, enter the location and filename; then click OK.

In the SQL Server Backup dialog box's Overwrite section, choose Overwrite Existing Media.

In the Schedule section of that dialog box, check the Schedule option box and then click the ' button to specify the backup schedule. Click OK in the Edit Schedule dialog box when you're done with schedule modifications.

NOTE: If a warning message appears telling you that the SQL Server Agent Is Stopped On Target Server, you need to configure the server to automatically start it when the server boots up; otherwise, SQL Server backup will not run, and your backup files will not be created. Figure 3-3 shows the SQL Server Properties dialog box with the Autostart SQL Server Agent option selected.

Verify that the backup jobs have been successfully scheduled by opening the Management . SQL Server Agent . Jobs window for the SQL Server hosting your WSS databases. Figure 3-4 shows the backup jobs for my EXTRANET and STS_extwss01 databases.

Back Up SQL Server Backup Files to Tape

The final task is to periodically transfer the SQL Server backup files to tape or other offsite storage media. This will protect against a catastrophic disaster such as a building fire, flood, earthquake ( . . . fill in your favorite disaster here) that might destroy your datacenter or otherwise make your online backups and servers unavailable.

RESTORING FROM A SQL BACKUP

To restore a server or server farm from a database backup, do the following:

Create a virtual server on IIS, which will be used to host WSS.

Restore the backups to a SQL Server instance.

On IIS, create an application pool under which WSS will run.

CAUTION:: The domain account you use for the application pool should be a member of the Security Administrators, Process Administrators, and Database Creators roles on the SQL Server that will host the restored databases.

Install WSS on a server and then connect to the restored configuration database.

Set the default content database server to the restored database server.

Extend the Internet Information Server (IIS) virtual server using the Extend And Map To Another Virtual Server option on the Extend Virtual Server page.

USING STSADM BACKUP

Sometimes you need to restore a single site rather than the entire database, which might be the case if, for example, a user accidentally deleted a critical document library or list. In this section, we'll cover how to create individual site backups so that you can recover a single site quickly. Although only top-level websites can be backed up using the STSADM Backup command, the backup file will include any subsites of that site. If you need to back up or restore a single subsite, you can use the SMIGRATE utility, covered later in this chapter.

CAUTION: You must be a member of the server computer's administrators group or a member of the SharePoint administrators group to be able to back up or restore a site using the STSADM utility.

To perform a backup of a site using STSADM, you would use syntax similar to the following:

Stsadm.exe -o backup -url http://extwss01/clients/acme -filename acme.dat

NOTE: The STSADM command can be found in the C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN folder in a typical WSS installation.

It's often convenient to place all sites of a particular type under a given path. For example, all client sites might be created under the path http://extwss01/clients/, as in the previous example. Placing them together makes it easy to find and back up all sites of that type. To enable this, you use the Define Managed Paths page that can be accessed from the SharePoint Central Administration application. This page can be a bit difficult to find because it's buried three levels down in the menu structure. To get there, select Configure Virtual Server Settings from the main page of the SharePoint Central Administration application, then select Default Web Site (or whichever virtual server for which you wish to add a managed path), and finally select Define Managed Paths from the Virtual Server Settings page. Figure 3-5 shows the Define Managed Paths page.

AUTOMATING STSADM BACKUP

One of the advantages of placing all sites you want to back up under a specific managed path is that it makes automating the process of backing up a collection of sites possible. In this section, we'll cover the use of a simple Windows script to create backup files for all sites in a given path. The script, shown in Listing 3-1, does the following:

Defines the location of the STSADM command.

Defines the location in which the backup files will be written.

Deletes any previous backup files.

Gets a list of all top-level sites on the specified WSS server.

Iterates through the list of top-level sites, creating a backup of each one.

Listing 3-1. Windows Script to Automate WSS Site Backups

' Back up the WSS sites...
' '''''''''''''''-
Const STSADM_PATH = _
"C:\Program Files\Common Files\Microsoft Shared\" & _
"web server extensions\60\BIN\stsadm"
Dim objFso, objFolder, objFiles, objFile, objShell, objExec
Dim strResult, objXml, objSc, objUrl, strUrl
Dim strFileName, strCmd
Set objFso = CreateObject("Scripting.FileSystemObject")

' Delete all backup files currently present in the backup folder.
Set objFolder = objFso.GetFolder("\\extwss01\WSSBackups\")
Set objFiles = objFolder.Files
For Each objFile in objFiles
objFile.Delete(True)
Next

' Retrieve all site collections in XML format.
Set objShell = CreateObject("WScript.Shell")
Set objExec = objShell.Exec(STSADM_PATH & " -o enumsites -url http://extwss01/")
strResult = objExec.StdOut.ReadAll

' Load XML in DOM document so it can be processed.
Set objXml = CreateObject("MSXML2.DOMDocument")
objXml.LoadXML(strResult)

' Loop through each site collection and call stsadm.exe to make a backup.
For Each objSc in objXml.DocumentElement.ChildNodes
    strUrl = objSc.Attributes.GetNamedItem("Url").Text
    strFileName = "\\extwss01\WSSBackups\" & _
       Replace(Replace(strUrl, "http://", ""), "/", "_") & _
       ".bak"
    strCmd = STSADM_PATH & " -o backup -url """ + strUrl & _
       + """ -filename """ + strFileName + """"
    objShell.Exec(strCmd)
Next

WScript.Echo "WSS Backup complete."

NOTE: As with your SQL Server backup, these backup files should be copied to tape periodically for disaster-recovery purposes.

RESTORING FROM A STSADM BACKUP

There are three options for restoring sites from an STSADM backup file:

Option 1. Restore over an existing site. For example, to restore a site named smithco, you might use the following command:

stsadm -o restore -url http://extwss01/clients/smithco -filename =>
\\extwss01\WSSBackups\extwss01_clients_smithco.bak -overwrite

CAUTION: When you restore over an existing site, all data for the original site is destroyed and cannot be recovered.

Option 2. Restore a site to a new site on the same server. This is the option recommended by Microsoft because it allows you to restore the backup to a second site, copy just the needed content back to the original site. The following command can be used to restore the smithco client site to a new site named smithco2:
```
stsadm -o restore -url http://extwss01/clients/smithco2 =>
-filename \\extwss01\WSSBackups\extwss01_clients_smithco.bak
```
Option 3. Restore a site to a separate server, with a separate installation of WSS that uses a copy of the original server's configuration database. This option, which is a variation of Option 1, is appropriate if the original server is unavailable, or if you don't want to restore to the same WSS installation for some other reason.

USING THE SPBACKUP UTILITY TO AUTOMATE STSADM BACKUPS

One useful utility that can be found on Microsoft's SharePoint Products and Technologies Resource Kit CD is SPBackup.exe. This utility wraps the STSADM Backup command, providing the ability to create backups of sites that have been modified in the past day or week. This ability can dramatically reduce the time needed to run regular backups of large WSS installations.

NOTE: The SharePoint Products and Technologies Resource Kit can be obtained from Microsoft Press or from various other book resellers.

The SPBackup utility writes a batch file containing one STSADM Backup command for each site to be backed up. That batch file can then be executed to produce the actual backup files. To combine these two operations, a batch file similar to the following (Daily.bat) can be used:

Listing 3-2. Contents of Daily.bat

REM ''''''''''''''''''''''''''''''''
REM - Back up all sites on the current server that have been changed
REM - in the past day.
REM ''''''''''''''''''''''''''''''''
spbackup -d -f bkup.bat
CALL bkup.bat
MOVE /Y *.spb \\extwss01\WSSBackups

Unfortunately, the SPBackup utility has no option to place the backup files anywhere other than the C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN folder, so the third line of the batch file shown in Listing 3-2 copies all the backups to the desired backup folder.

SMIGRATE BACKUP/RESTORE

The SharePoint Migration (SMIGRATE) utility can be used to back up and restore an individual site or subsite. FrontPage 2003 uses this same utility when it copies a site from one location to another.

CAUTION: Unlike SQL Server backups of the content and configuration databases or the STSADM Backup utility, SMIGRATE is not full fidelity. That is, some customizations or settings will not be written to the backup and thus will not be restored. Specifically, security, personalization, and global administration settings will not be retained. For many uses, such as creating a copy of an existing site as a starting point for further customizations or to recover a single document that a user has inadvertently deleted, this may not be a problem. However, SQL Server and STSADM Backup are better options for creating backups to be used to recover from a system failure.

One advantage of SMIGRATE over STSADM Backup is that it can be run from any computer that has access to the WSS site, whereas STSADM Backup can be run from the server hosting the WSS site being backed up. The following command creates a backup of the acme client site to the file acme.fwp using the SMIGRATE utility:

smigrate -w http://extwss01/clients/acme -f acme.fwp -y -u extranet\mgerow -pw *

The SMIGRATE utility's parameters are shown in Table 3-1. The following command could be used to restore the acme site using the backup file acme.fwp:

smigrate -r -w http://extwss01/clients/acme -f acme.fwp -u extranet\mgerow -pw *

NOTE: If you want to restore your backup to a new site, you must first create a new blank site using the STSADM Createsite command. You should not assign a site template to the new site because SMIGRATE can only restore to existing sites that have either the same template as the site originally backed up or no template at all. The following two commands will create a new blank site and restores the acme site content to it:

stsadm -o createsite -url http://extwss01/clients/acme_new
-ownerlogin extranet\mgerow -owneremail mgerow@fenwick.com
smigrate -r -w http://extwss01/clients/acme_new -f acme.fwp -u extranet\mgerow -pw *

BACKING UP SHAREPOINT'S CONFIGURATION FILES

Many of the customizations you'll make to SharePoint will be stored in its configuration files on disk rather than in the configuration or content databases. Site templates, .aspx files, style sheets, and many other components of SharePoint are contained in subfolders of the C:\Program Files\Common Files\Microsoft shared\web server extensions\60\templates folder. If you make changes or additions to any of these configuration files you'll want to back them up as well.

CAUTION: Recovered sites that are based on custom site templates or other customizations will fail to open unless the custom template and configuration files are also restored.

Using Visual SourceSafe (VSS) for Backup

Although a file system backup of the C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\templates folder and all its subfolders is sufficient to allow recovery of a WSS configuration, you will gain many advantages by using some form of source control to manage your customizations and additions to the SharePoint configuration files. Specifically, a tool such as Microsoft's Visual SourceSafe (VSS) provides many benefits over a simple file system backup (see Table 3-2).

I typically add the original C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\templates folder to the VSS database I'm using to track changes and enhancements to a WSS installation, which provides an audit trail of all changes back to the original out-of-the-box configuration. With this in place, I can make edits to the configuration files with the confidence of knowing that if I introduce an error that causes a site, or even the entire server, to fail, I can back that change out and return to a known-good-state.

NOTE: As of this writing, VSS 2005 has just been released. With the exception of UNICODE support and support for remote web client access, there are few significant differences between VSS 6 and VSS 2005. VSS 2005 Team System has also been released. VSS 2005 Team System provides many more features than VSS 2005 and is designed for complex projects and large teams. Any of these products can be used to implement a versioned backup of WSS configuration files.

CAUTION: The VSS database should be backed up regularly. The backup should be stored on a separate physical hard drive, preferably on a separate Windows server to ensure against the risk of WSS server disk failure. VSS 6 also provides an integrity check utility called Analyze.exe that should be run regularly to ensure that the VSS database has not become corrupted.

SUMMARY

In this chapter, you learned the key components of a WSS extranet that need to be backed up and specific strategies to do so. You also saw how to restore those backups. Taken together, these techniques can form the foundation for a comprehensive backup and recovery strategy. They can also be used to build backup or STAGE servers, or to move subsections of your WSS installation to other computers.

Armed with this knowledge you'll be able to respond quickly and with a minimal amount of stress (it wouldn't be any fun if there were none!) in the case of a systems failure or human error.

Page: 1

<< Previous Page

Rate this: