Microsoft SharePoint Products and Technologies Administrators Pocket Consultant

Always use a content recovery method before using a disaster recovery method because it lessens the impact on other users. For example, using a site collection restore method for a single user's deleted file would overwrite everyone else's content as well, because you must overwrite the entire site collection when restoring. Start with the simplest method and progress as required to restore content. Depending on the severity of the file loss, corruption, or deletion, there are three native tools available to restore content to a usable state: document versioning, using the Recycle Bin, and using the migration tool.

Document Versioning

An often overlooked method of restoring content is the native document versioning. When a user calls you or your Helpdesk about a corrupted file, always check the document library and try to restore the last version if possible. For this reason, always store at least a few Major Versions of a document. To enable Major Versioning for a document library, do the following:

1. From the Document Library Settings menu, select Document Library Settings.

2. Under the General Settings column, select Versioning Settings.

3. At a minimum, select Create Major Versions, as shown in Figure 14-1. If disk space is of concern, limit the number of Major Versions to be retained. Selecting at least two Major Versions will give you some comfort room should a file corruption occur.

4. Click OK.

Figure 14-1: You should select at least two Major Versions for every document library if you want to use versioning as a content recovery method.

Configuring the Recycle Bin

One of the most useful and anticipated features of both Windows SharePoint Services and SharePoint Server is the Recycle Bin. Although most small to medium organizations can function quite nicely with the out-of-the-box settings, larger organizations will want to finely tune the Recycle Bin to prevent problems. Before configuring your Recycle Bin settings, it is important to understand that the Recycle Bin retention policies are set in Central Administration on a per-Web application basis. The actual management of deleted content, however, is performed on a per-site collection basis. This feature allows site collection administrators to manage deleted content, but does not give them the ability to modify retention settings.

In its default state, the Recycle Bin has two stages: First Stage (user deleted) and Second Stage (administrator/system deleted). The settings for these are not as straightforward as they appear and can have a wide-ranging system impact if not thought out and configured carefully.

Configuring the Recycle Bin Global Settings

Configure the Recycle Bin from Central Administration > Application Management > Web Application General Settings. Figure 14-2 shows an example of the Recycle Bin settings in Central Administration.

Figure 14-2: Verify that you are in the correct Web application before changing Recycle Bin settings.

Modifying the Global Recycle Bin Settings for a Web Application

1. From Web Application General Settings, select the Web application you want to modify.

2. At the bottom of the Web Application General Settings interface, verify that the Recycle Bin Status is set to On.

3. Select the number of days that items should remain in the Recycle Bin before they are deleted.

4. Optionally, turn off time-based deletion. If this is selected, then items are only moved from the first stage when a user manually empties his or her Recycle Bin, and items are only automatically emptied from the second stage if a Site Quota is used and % Of Quota is defined. Changing the Recycle Bin expiration policy to Never does not turn off the first stage of the Recycle Bin. In fact, the first stage is not configurable.

It is important to note that contents deleted to the first stage of the Recycle Bin count against the site quota and individual quota. If you do not set a site quota, there is no maximum size limitation on the first-stage Recycle Bin. It is only constrained by the number of days you set.

Configuring the Second Stage of the Recycle Bin

When a user deletes an item, that item is moved into the second stage of the Recycle Bin. The second stage does not count against the site quota or individual quota. However, its size is limited to a percentage of site quota size or is unlimited if you do not use a site quota. The second stage uses the "first in, first out" methodology for deleting files. That is, once the maximum size for the second stage of the Recycle Bin is reached, the oldest file in the stage is deleted to make room for newly deleted content.

Configuring the Second Stage of the Recycle Bin

1. Open Central Administration > Application Management > Web Application General Settings.

2. Select and verify the Web application you want to modify.

3. At the bottom of the interface are shown the Recycle Bin settings.

4. Change the percentage of the live site quota for second-stage items. The default is 50%, but a better starting point for most organizations is about 20% of live site quota. Depending on the amount of activity in your site collections, you may need to adjust this number to meet your needs. Figure 14-3 shows an example of both the global and second-stage settings of the Recycle Bin.

Figure 14-3: Consider 20% of live site quota for a second-stage starting point.

Optionally, you may turn off the second stage of the Recycle Bin. If you select this option, items removed in the first stage (user stage) of the Recycle Bin are deleted permanently. This option removes the ability for a site collection administrator to restore content that users have deleted from their Recycle Bin.

Managing the Recycle Bin in a Site Collection

Site collection administrators manage content in both stages of the Recycle Bin from Site Actions > Site Settings > Site Collection Administration > Recycle Bin. In the Quick Launch, you can select which stage to manage. Checking an item in either stage and restoring that item will restore a full fidelity copy to its original location. This copy will include all versions and will be restored with the last user modified date, not the deleted or restored date. Figure 14-4 shows an example of both stages of the Recycle Bin management in a site collection.

Figure 14-4: Click on a stage to manage deleted content for users.

Using the Migration Tool

The tool Smigrate.exe found in Windows SharePoint Services 2.0 and SharePoint Portal Server 2003 has been replaced and enhanced with the stsadm.exe -o [import | export] command-line options. The Stsadm.exe command is located in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin directory and is available in both Windows SharePoint Services and SharePoint Server. Both products support the creation of Content Migration Packages, which are XML files that allow sites and site collections to be imported and exported along with their dependencies, such as security features, user roles, workflows, and metadata. One major enhancement is the ability to migrate content including user permissions. This feature allows you to back up and restore single lists or items from a site collection or subsite and to include the associated user permissions. The following are examples of exporting and importing a site collection using Stsadm.exe:

stsadm.exe -o export -url http://portal.contoso.msft/sites/team1 -filename c:\backups\team1.bak -includeusersecurity -versions 3 stsadm.exe -o import -url http://portal.contoso.msft/sites/team1 -filename c:\backups\team1.bak -includeusersecurity -updateversions 1

In this example, the imported versions of objects were added to the existing objects, instead of overwriting them. In addition, all file permissions were retained. The SharePoint Products team does not recommend using command-line migration for bulk backup and restore because doing so is CPU intensive. Instead, use command-line migration to move content between farms, as when recovering content using an alternate server farm. Alternatively, some organizations script this command to back up high-profile sites and site collections.

When using stsadm.exe -o export, you can define the following parameters:

• -url The -url parameter specifies the site collection to be exported; for instance, http://portal.contoso.msft.

• -filename The export file is created with the name Filename.cmp, or you can specify a filename extension, such as .bak.

• -overwrite This optional overwrite parameter causes previous export attempts to be overwritten. If the overwrite parameter is not used, both the .export.log file and the .cmp file from previous attempts must be deleted or the process will fail.

• -includeusersecurity The optional -includeusersecurity parameter causes groups and group membership information to be included, as well as preserving timestamps, security information, and users.

• -haltonwarning The optional -haltonwarning parameter stops execution when a warning is encountered.

• -haltonfatalerror The optional parameter -haltonfatalerror stops execution when a fatal error occurs.

• -nologfile The optional -nologfile parameter prevents the creation of a log file.

• -versions The optional -versions parameter defines which versions of files and list items will be exported. There are four versioning options.

  1-Option 1 exports only the last major version for files and list items. This is the default setting.

  2-Option 2 exports the most current version, either major or minor.

  3-Option 3 exports both the last major and last minor versions.

  4-Option 4 exports all versions for file and list items.

• -cabsize The -cabsize parameter specifies the maximum file size, in megabytes, for the Content Migration Package (.cmp) file. The default file size is 25 MB, and the maximum size is 1024 MB.

  Tip

  To export content larger than the default 1024 MB limit, use Stsadm.exe to increase the default template size in bytes: stsadm -o setproperty -pn max-template-document-size -pv 30000000

• -nofilecompression In addition to not compressing the file, the optional -nofilecompression parameter causes a directory with the appropriate XML files to be created instead of a .cmp file.

  Important

  You cannot import from an NTFS directory created with the nofilecompression option.

• -quiet The optional -quiet parameter suppresses output to the console, except for a notification on completion.

When using stsadm.exe -o import, you can define the following parameters:

• -url The URL parameter specifies where to import the Content Migration Package (.cmp) file to; for example, http://portal.contoso.msft.

• -filename The filename parameter specifies the name of the file to import from.

• -includeusersecurity The optional -includeusersecurity parameter causes groups, timestamps, security information, and user information to be imported.

• -haltonwarning The optional -haltonwarning parameter stops execution when a warning is encountered.

• -haltonfatalerror The optional -haltonfatalerror stops execution when a fatal error occurs.

• -nologfile The optional -nologfile parameter suppresses the creation of a log file.

• -updateversions The -updateversion parameter specifies how versions will be merged on import and has three options:

  • 1-Option 1, the default, adds new versions to those that already exist in the .cmp file.

  • 2-Option 2 overwrites the file and all its versions, keeping only those already in the destination.

  • 3-Option 3 causes files that already exist in the destination to be ignored.

• -quiet The optional -quiet parameter suppresses output to the console except for a notification on completion.