Export (0) Print
Expand All

Back up or archive logs (SharePoint Foundation 2010)

 

Applies to: SharePoint Foundation 2010

Topic Last Modified: 2013-01-08

A system-wide strategy for data protection should include backing up or archiving the logs in which data related to Microsoft SharePoint Foundation 2010 is recorded. This data can be useful for performance analysis, troubleshooting, monitoring compliance with service level agreements, and legal, regulatory, or business reasons. Therefore, protect this data as part of the routine maintenance by backing up or archiving the logs.

The following sections are labeled in the following manner to indicate how important it is to back up or archive this kind of log:

  • [Essential] means that the log contains data that is essential to the environment. The data would be lost if a disk failure or other problem occurred.

  • [Recommended] means that the log contains data that is useful in most environments for troubleshooting, operational, legal, or other needs.

In this article:

Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 transaction logs record all changes that were made to a database since the last checkpoint or full backup. These logs contain required data for restoring the farm.

We recommend that you back up these logs every 5–10 minutes. When you back up these logs, they are automatically truncated. You can use the Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 tools to back up the transaction log. For more information, see Creating Transaction Log Backups (http://go.microsoft.com/fwlink/p/?LinkId=124881) in the Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 documentation.

Transaction logs are not automatically backed up when you back up the farm, Web application, or databases by using either the SharePoint Central Administration Web site or the Windows PowerShell. Therefore, you must manually backup and truncate the log. For more information, see Creating Transaction Log Backups (http://go.microsoft.com/fwlink/p/?LinkId=124881) in the Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 documentation.

When you back up SharePoint Foundation 2010, the size of the transaction log can affect how long the backup operation takes. Because the transaction log records all changes to a database since the last checkpoint or full backup, the log can grow very large over time. If the transaction log has grown very large, backups might take a very long time. For more information, see How to stop the transaction log of a SQL Server database from growing unexpectedly (http://go.microsoft.com/fwlink/?LinkID=111458).

The recommended way to truncate the transaction log if you are using a full recovery model is to back up the log. Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 automatically truncates the inactive parts of the transaction log when you back up the log. We also recommend that you pre-grow the transaction log to avoid auto-growing the log. For more information, see Managing the Size of the Transaction Log File (http://go.microsoft.com/fwlink/p/?LinkId=124882). For more information about using a full recovery model, see Backup Under the Full Recovery Model (http://go.microsoft.com/fwlink/p/?LinkId=127985). For more information about using a simple recovery model, see Backup Under the Simple Recovery Model (http://go.microsoft.com/fwlink/p/?LinkId=127987).

We do not recommend that you manually shrink the transaction log size or manually truncate the log by using the Truncate method.

Usage analysis enables you to track how Web sites are being used. Log files are created daily to track usage. You can configure the setting for the collection of usage data. One of the most important settings is the location of the log files. By default, the log folder is configured to be on the same drive partition where SharePoint Foundation 2010 is installed. To make sure that the log files to not fill up that drive, you should change the log folder to be on a separate drive.

The location of the log directory is a farm-level setting, and the directory that is specified in this setting must exist on all servers in the farm. These logs are automatically backed up when you back up the farm.

For most environments, the default settings are adequate. For more information about configuring usage data collection settings, see Configure usage and health data collection (SharePoint Foundation 2010)

Diagnostic logs provide detailed information about the operation of the farm. You can configure the level of detail that is logged. We recommend that you archive these logs when you archive the farm. You can archive the logs for the whole farm or a specific server. You can archive these files by manually copying them to a shared folder, or by using the Windows PowerShell Merge-SPlogFile cmdlet. You can use the Merge-SPLogFIle cmdlet to archive the log files on all of the farm servers at once. You can use the Windows PowerShell Copy-Item cmdlet to archive log files from a single server. The Copy-Item cmdlet does not provide filtering and you must copy the entire log file.

For more information about how to configure diagnostic logging, see Configure diagnostic logging (SharePoint Foundation 2010).

To archive diagnostic logs from all farm servers by using Windows PowerShell
  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. At the Windows PowerShell command prompt, type the following command:

    Merge-SPLogFile -Path "<path to merged log file>.log" -Overwrite

    For example, Merge-SPLogFile -Path "C:\Logs\MergedFiles\AllFarm_merged_12.20.2009.log" -Overwrite

    importantImportant
    Merging all log entries for all farm servers can take a long time and use resources. We recommend filtering the entries to match a specific set of criteria before merging.

    To merge log entries that match a specific set of criteria, type the following command:

    Merge-SPLogFile -Path "<path to merged log file>.log" -Area "<Area>" -Category "<Category>"

    You can filter by one or more of the following:

    • Area (one or more, wildcard)

    • Category (one or more, wildcard)

    • Level

    • Correlation (one or more)

    • EventID (one or more, wildcard)

    • Message (wildcard)

    • StartTime

    • EndTime

    • Process (one or more, wildcard)

    • ThreadID (one or more)

    tipTip
    You can name the merged log file however you want. We recommend that you use a naming convention that makes it easy to determine what the log file contains, such as "<date merged>_<farm name>_<filtering criteria>. For example, to signify all the farm server log entries forSharePoint Foundation 2010 that involve the database category and are marked as "High" use, "Dec_2009_ContosoInternet_Foundation_Database_High.log".

For more information, see Merge-SPLogFile.

To archive diagnostic logs for a specific server by using Windows PowerShell
  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. At the Windows PowerShell command prompt, type the following command:

    Copy-Item <Log folder path> -Destination <Archive folder path> -Recurse

For more information, type Get-Help Copy-Item -Full.

noteNote
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft