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.
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
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
interface (GUI) or
GUI is easy to use.
Command line is required
SQL Server 2005 and
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.
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.
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
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.
In the directory%SystemD rive%\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.
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:
\ue000-url <URL to be exported>
\ue000-filename <path and filename to export> (can append with -overwrite)
\ue000-includeusersecurity (using this flag will include the permissions associated with object)
\ue000(export only) -versions (1 = last major, 2 = current, 3 = last major and minor, 4 = all versions)
\ue000(import only) -updateversions (1 = add new version to current, 2 = overwrite, 3 = ignore, 4 = terminate
You can also use stsadm.exe to back up and restore individual site collections when using the -backup
option. Using this option creates full sitebackups 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-fidelitybac kup created with
stsadm.exe -obac kup. 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:
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:
\ue000-url <full URL> (for example,http://portal.contoso.msft/sites/H R)
\ue000-filename (Include the path; this can be a drive letter or Universal Naming Convention name)
\ue000-overwrite (using the overwrite flag will completely overwrite the destination)
The stsadm.exebac kup 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.
If you lose content that must be restored from farm-levelbackups, you have two choices: restore the
content databases from the lastbac kup 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 databasebac kup and restore it to the production server farm:
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.
This action might not be possible to undo. Are you sure you want to continue?