Bridge the SharePoint File-Restore Gap

The code in Listing 1 shows a simple VBScript routine that creates a time-stamped folder for the backup by using the FileSystemObject and Date functions. After creating the folder, the script uses the WshShell object's Exec method to call the Spsbackup utility. To use the backup script, you need to modify the strDestinationFolder pathname in callout A for your own environment, so that it's either a Universal Naming Convention (UNC) pathname or a local drive pathname. Spsbackup requires a local drive as a backup target for a single-server implementation of Portal Server and a UNC pathname for a backup target in a farm implementation of Portal Server. Note that if you decide to use external storage for your backups, the pathname will impact how you connect your external-storage device. Simply mapping a drive letter to a UNC pathname for a single-server implementation of Portal Server won't work. In the case of a single-server implementation, you can extend the script by calling FileSystemObject's MoveFolder method so that after the backup procedure occurs locally, you can move it to a target that's accessible via a UNC pathname.

Unfortunately, Microsoft didn't bother to create a SharePoint scripting API, so you must either call command-line tools, as the script does, or write your own Microsoft COM objects that leverage the SharePoint object model by using the Microsoft .NET Framework. You can register and instantiate the custom COM components and call methods of these custom objects from a script. You can also use the new Windows PowerShell to run Spsbackup, but, as far as I know, no Microsoft .NET cmdlets are available for the current release of Portal Server. Cmdlets encapsulate tasks by calling .NET methods available in various object models. Developers (Microsoft or otherwise) can write cmdlets to automate SharePoint administrative tasks by leveraging either the Portal Server or SharePoint Services .NET object models. (For more information about cmdlets in Windows Power-Shell, see "Introducing Windows PowerShell," August 2006, InstantDoc ID 50565.)

After you've customized your script, you can add it as a scheduled task to your SharePoint server, where you'll execute the script by using the AT command-line utility or the Scheduled Task Wizard, which you can launch from the Scheduled Tasks icon below the System Tools program group. The wizard will walk you through the scheduling process. Alternatively, you can type

AT /? 

at the command line for help in using the AT command scheduler.

After you create the backups, you can do a full restore of a Portal Server backup by using the Spsbackup utility either from the utility's graphical interface or at the command line. You can see the graphical interface for Spsbackup if you open Spsbackup from the Portal Server program group or if you run Spsbackup from the command line without specifying any switches.

Restore Strategies
Now that you have a backup procedure, you might want to look at three choices for building your restore strategy: the snapshot, ad hoc, and hybrid methods. In the snapshot method, you create a restore environment that's an earlier image of the production portal. You run periodic backup and restore operations to get a snapshot of the portal at an earlier time. An obvious down side to this method is that you can't restore files prior to the date of the restored environment. This deficiency is solved in the ad hoc method, where you can regularly create and archive backups and conduct restore operations as the need arises. If you require a file that dates back three months, all you need is the backup file from that time period to prepare an ad hoc restore and retrieve the file. However, depending upon the frequency of restore requests, the ad hoc method might be a poor solution because restores can take a long time to finish.

In the hybrid method, you combine the first two methods by maintaining a snapshot with the option of restoring an ad hoc environment upon request. You can overwrite the mirrored environment with the ad hoc restore or maintain a third server just for on-demand restores. The size of your organization, administration team, and infrastructure and the number of restore requests can influence whether any of these approaches will work for you.