Build a solution with a script, a secondary environment, and a file-restore strategy
Microsoft SharePoint technologies support information sharing among groups of people within or across companies. (In this article, we refer to Microsoft SharePoint Portal Server 2003 as Portal Server and Windows SharePoint Services 2.0 as SharePoint Services. When referring to both, we use SharePoint.) Share-Point provides document-management support through two types of file repositories: document libraries and lists. Files are stored in a SharePoint content database, not in the Windows file system.
One glaring omission in SharePoint's document-management capabilities is that you can't easily restore files accidentally deleted. In addition, although versioning is available, Portal Server and SharePoint Services remove all version history after you delete an item. Besides these file-restore problems, SharePoint has a relatively weak backup engine, which doesn't give you the option of performing single-file restores from a backup.
Despite SharePoint's backup and restore gaps, workable solutions do exist. We'll show you how to automate the SharePoint backup process by using a script we've provided, then we'll discuss some approaches for supporting file restores.
Restore from a Backup Environment
Instead of struggling with SharePoint's inadequate file-restore capability,
you can provide single-file restores and undeletes from backed-up versions of
a Portal Server portal instance (single-server or farm), a SharePoint Services
instance, or Share-Point site collections or sites. However, managed backup
and restore procedures require dedicating IT employees to oversee the process,
a mechanism to request the restoration of files, and possibly additional hardware
for the secondary environment. One way to minimize the cost of a secondary environment
is to virtualize your portal instance by using server-virtualization products
such as VMware Workstation or Microsoft Virtual PC.
Regardless of whether your secondary Share-Point environment is physical or virtual, backups might also require a significant amount of media capacity. To meet storage requirements for your backups, you could use SAN technology, which is already available in many larger organizations, or terabyte-sized drives. Many vendors provide NAS terabyte drives where you can inexpensively store SharePoint backups. It's also prudent to store your backups in offsite storage and implement fault tolerance by using a RAID solution.
Tool Options
If maintaining a second SharePoint environment containing a previous version
of the production environment is viable for your organization, you can perform
full backup and restore operations. For a Portal Server implementation, you
can use the SharePoint Portal Server Data Backup and Restore utility (spsbackup.exe).
For a pure SharePoint Services implementation that doesn't contain Portal Server,
you can use the SharePoint administration utility (stsadm.exe) or Microsoft
SQL Server tools such as OSQL (osql.exe) to perform backup and restore. For
more information about backing up and restoring SharePoint Services, see the
Microsoft article "How to back up and restore installations of Windows SharePoint
Services that use Microsoft SQL Server 2000 Desktop Engine (Windows)" (http://support.microsoft.com/?kbid=833797.)
Although you can use Stsadm to back up and restore Portal Server, using the tool in this way has limitations. For information about those limitations, see the Microsoft article "Supported scenarios for using the Stsadm.exe command-line tool to back up and to restore Windows SharePoint Services Web sites and personal sites in SharePoint Portal Server 2003" (http://support.microsoft.com/?kbid=889236).
Portal Server Backup Procedures
You can start Spsbackup from the SharePoint Portal Server program group or at
the command line by navigating to the SharePoint bin folder and typing
spsbackup.exe
You might also want to add the bin folder to your PATH environment variable on the server where you plan to run the backup procedure.
You can do backups periodically, so that you can find restorable data according to the backup date. To automate the backup procedure, you can create a batch job that calls the Spsbackup utility, or you can create a script to complete this operation. Then you can use the built-in AT Command Scheduler (winat.exe) or Task Scheduler to schedule a regular backup.
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.
Additional Approaches
Other approaches you can take within a second portal environment don't require
doing a complete restore of the portal databases to find deleted data. If you
can narrow critical document libraries and lists to those found within a few
site collections, sites, or subsites, you can back up and restore smaller sections
of the portal more frequently, on a periodic or an ad hoc basis. In this partial?file-restore
approach, you isolate backups and restores at the SharePoint Services level
by using the smigrate.exe command-line migration tool or the stsadm.exe command-line
administrative tool to mirror smaller site structures. Running stsadm.exe with
the -o backup and -o restore options lets you back up and restore site collections
from one environment to another; smigrate.exe provides similar functionality
for individual sites. You can find more information about these tools in the
Microsoft Office SharePoint Portal Server 2003 Administrator's Guide (http://www.microsoft.com/technet/prodtechnol/office/sps2003/downloads/admdwnld.mspx)
and the Windows SharePoint Services Administrator's Guide (http://www.microsoft.com/technet/prodtechnol/sppt/wss/wssagabs.mspx).
This strategy of backing up and restoring smaller sections lets you perform more frequent and rapid backups and file restores than a full backup-and-restore operation. However, it requires that you correctly identify and maintain a list of critical site collections or sites to back up.
Another approach provides file-restore solutions through the SharePoint content databases within SQL Server. (For more information, see the Web-exclusive sidebar "Restoring Files by Using SharePoint Content Databases" at http://www.windowsitpro.com, InstantDoc ID 93240.)
Third-party vendors such as AvePoint and Nintex also offer products that provide file-restore and undelete capabilities.
No matter how you deal with the Share-Point backup and restore gap, you need to take storage needs into account and, depending on which approach you take, consider securing the duplicated data so that most users can't access it. Otherwise, you might overlook duplicate data when securing SharePoint.
Not Perfect, But an Improvement
Microsoft has improved restore functionality in Microsoft Office SharePoint
Server 2007. In the current beta version, you'll see a two-stage undelete process.
After deletion, a file remains in a recycle bin for a configurable amount of
time, during which a user could restore it. An administrator can also restore
user files and set file-retention policies based on configurable storage quotas.
In addition, the beta's backup utilities provide differential, incremental,
and full backup options.
As any IT professional can tell you, no perfect software product exists. We hope the solutions we've offered will help you bridge the gap in backup and file restore in Share-Point.
| Solutions
Snapshot
|