Category : Best Practices

SharePoint 2013 Service Accounts Best Practices

Applies to: SharePoint Server 2013, SharePoint Foundation 2013

The document describes how important Service Accounts were in the installation of SharePoint 2013, if they are not set up correctly they can open big security holes in your organization and give you serious problems further down the road.

The document also suggested that you cannot have only one set of Service accounts for every scenario, since not all scenarios require the same security (ex: a development environment does not require same security a UAT and likewise the production one). So, I suggested three sets of service accounts for different deployment scenarios of SharePoint 2013.

This document explains all the three sets of service accounts, explaining the difference between the sets and also what every account does!

NOTE: These sets only cover the basic installation and configuration of SharePoint 2013 and SQL. Other Service accounts will be needed for some Service Applications (Ex: Excel, Visio, Performance Point, etc)

Low Security Option

Summary

The Low security option is of course the one with the least accounts possible to install SharePoint in a proper manner. It uses only 1 SQL account that will be the SQL administrator and also run the services, and 5 SharePoint accounts: The Farm Administrator, the Web Application pool account, the SharePoint Service Application Pool account the Crawl account and the User Profile Synchronization account. More details under each section

For the SQL Server

NameDescriptionLocal RightsDomain Rights
SQL_Adminwrite vThe SQL Server service account is used to run SQL Server. It is the service account for the following SQL Server services: MSSQLSERVER SQLSERVERAGENT. SQL Admin on the SQL ServeralueLocal Administrator on the SQL ServerDomain User

Explanation
As Stated previously, in the Low Security Option, we only use one Service Account for our SQL Server. This account needs to be a Local Administrator on the SQL server in order to be able to install SQL. We will also run the SQL AGENT and the Database Engine services with this account. This the account that will have the full power on your SQL server and you will use it to grant rights to your SP_Farm.

For the SharePoint Server

NameDescriptionLocal RightsDomain Rights
SP_FarmThe server farm account is used to perform the following tasks: -Setup -SharePoint Products Configuration Wizard -Configure and manage the server farm. -Act as the application pool identity for the SharePoint Central Administration Web site. -Run the Microsoft SharePoint Foundation Workflow Timer Service. Local Administrator on all the SharePoint Servers. SecurityAdmin and DB_Creator rights on the SQL InstanceDomain User
SP_PoolThe Pool account is used to run the Web Application PoolsNoneDomain User
SP_ServicesThe Services Account is used to run the Service Application PoolNoneDomain User
SP_CrawlThe Default Content Access Account for the Search Service ApplicationNoneDomain User
SP_UserProfilesThe User Profile Synchronization AccountNoneReplicate Directory Changes permission on the domain

Explanation
The Low Security Option uses the minimum amount of accounts while also keeping a level of security. Here is the account breakdown:

SP_Farm is your main SharePoint account in this configuration. It needs to have Local Administrator rights to be able to install SharePoint Server and also the Securityadmin and DBcreator roles on the SQL Server to create the configuration and other databases. This account will be your main Farm Administrator and also run the Timer Service and the web application for Central Administration use to access the SharePoint content database

SP_Pool is a domain account used for application pool identity.. ex: When you create a Web Application, and you create a pool for it, you select this account!

SP_Services is a domain account used for the Service Applications Pools. ex: When you create a Managed Metadata Service application and create a pool for it, you select this account!

SP_Crawl is used within the Search Service Application to crawl content. The Search Service Application will automatically grant this account read access on all Web Applications. It will also run the SharePoint Windows Search Service.

SP_UserProfiles is the account used for the User Profile Synchronization between your Service Application and your Active Directory. This account does not need any local rights, however you need to give it Replicate Directory Changes rights on the Active Directory in order to allow the synchronization

Medium Security Option (Sweet Spot)

Summary
The Medium Security option is the Sweet Spot of a SharePoint installation. It uses slightly more accounts than the Low Security Option however it provides a huge security improvement. By giving less rights to each account you limit the possible damage in case an account gets hacked and also follow Microsoft’s recommendation of installing SharePoint 2013 with least-privilege administration. More details on the changes under every section!

For the SQL Server

NameDescriptionLocal RightsDomain Rights
SQL_AdminSQL Admin on the SQL Server. Used to Install the SQL Server.Local Administrator on the SQL ServerDomain User
SQL_ServicesIt is the service account for the following SQL Server services: MSSQLSERVER SQLSERVERAGENT.NoneDomain User

Explanation

The difference between the Low Security and the Medium Security option for the SQL is that we now use two different accounts :The SQL_Admin and the SQL_Services. The big security improvement is that the account running the Agent and Database Engine services is not a local administrator anymore. Here is the account breakdown:

SQL_Admin: This will be your main SQL Administrator!. It needs Local Administrator rights in order to install the SQL server.

SQL_Services: This account does not have any local rights, it is only used to run the SQL Agent and Database Engine windows services.

For the SharePoint Server

NameDescriptionLocal RightsDomain Rights
SP_FarmThe server farm account is used to perform the following tasks: -Configure and manage the server farm. -Act as the application pool identity for the SharePoint Central Administration Web site. -Run the Microsoft SharePoint Foundation Workflow Timer Service.SecurityAdmin and DB_Creator rights on the SQL InstanceDomain User
SP_AdminThe server farm account is used to perform the following tasks: -Setup -SharePoint Products Configuration WizardLocal Administrator on all the SharePoint Servers. SecurityAdmin and DB_Creator rights on the SQL InstanceDomain User
SP_PoolThe Pool account is used to run the Web Application PoolsNoneDomain User
SP_ServicesThe Services Account is used to run the Service Application PoolNoneDomain User
SP_CrawlThe Default Content Access Account for the Search Service ApplicationNoneDomain User
SP_SearchService Account to run the SharePoint Search “Windows Service”NoneDomain User
SP_UserProfilesThe User Profile Synchronization AccountNoneDomain User

Explanation

In the Medium Security option we increase the security by adding two new accounts: The SP_Admin and the SP_Search. Instead of giving all the Farm Administration power to the SP_Farm account, the SP_Admin will be the one that installs and configures SharePoint 2013 and have the local administrator rights, while the SP_Farm will only run the services and connect to the database. Furthermore, instead of letting the SP_Crawl account run both the Windows Service and have FULL-READ rights on all the web applications, the SP_Search will now run the Windows Service. Here is the breakdown of the accounts:

SP_Farm is a domain account that the SharePoint Timer service and the web application for Central Administration use to access the SharePoint content database. This account does not need to be a local administrator. The SharePoint configuration wizard grants the proper minimal privilege in the back-end SQL Server database.The minimum SQL Server privilege configuration is membership in the roles securityadmin and dbcreator.

SP_admin is a domain account you use to install and configure the farm. It is the account used to run the SharePoint Configuration Wizard for SharePoint 2013.The SPAdmin account is the only account that requires local Administrator rights. To configure the SPAdmin account in a minimum privilege scenario, it should be a member of the roles securityadmin and dbcreator on the SQL server.

SP_Pool is a domain account used for application pool identity.. ex: When you create a Web Application, and you create a pool for it, you select this account!

SP_Services is a domain account used for the Service Applications Pools. ex: When you create a Managed Metadata Service application and create a pool for it, you select this account!

SP_Crawl is used within the Search Service Application to crawl content. The Search Service Application will automatically grant this account read access on all Web Applications.

SP_Search Is used to run the SharePoint Windows Search Service.

SP_UserProfiles is the account used for the User Profile Synchronization between your Service Application and your Active Directory. This account does not need any local rights, however you need to give it Replicate Directory Changes rights on the Active Directory in order to allow the synchronization.

High Security Option

Summary

The High Security Option is the ones that provides the best security and of course the most Service Accounts. This only ads a small amount of extra security to the farm, however that extra security might be needed in some scenarios

For the SQL Server

NameDescriptionLocal RightsDomain Rights
SQL_AdminSQL Admin on the SQL Server. Used to Install the SQL Server.Local Administrator on the SQL ServerDomain User
SQL_AGENTIt is the service account for the following SQL Server services: SQL SERVER AGENTNoneDomain User
SQL_ENGINEIt is the service account for the following SQL Server services: Database Engine.NoneDomain User

Explanation

The difference between the Medium Security and High Security Option is that we now have a separate account for each of the two base services: SQL_Agent and Database Engine. Nothing changes for the SQL_Admin

SQL_Admin: This will be your main SQL Administrator!. It needs Local Administrator rights in order to install the SQL server.

SQL_Agent: This account does not have any local rights, it is only used to run the SQL Agent Windows Service

SQL_Engine: This account does not have any local rights, it is only used to run the Database Engine windows service.

For the SharePoint Server

NameDescriptionLocal RightsDomain Rights
SP_FarmThe server farm account is used to perform the following tasks: -Configure and manage the server farm. -Act as the application pool identity for the SharePoint Central Administration Web site. -Run the Microsoft SharePoint Foundation Workflow Timer Service. SecurityAdmin and DB_Creator rights on the SQL InstanceDomain User
SP_AdminThe server farm account is used to perform the following tasks: -Setup -SharePoint Products Configuration WizardLocal Administrator on all the SharePoint Servers. SecurityAdmin and DB_Creator rights on the SQL InstanceDomain User
SP_PoolThe Pool account is used to run the Web Application PoolsNoneDomain User
SP_ServicesThe Services Account is used to run the Service Application PoolNoneDomain User
SP_CrawlThe Default Content Access Account for the Search Service ApplicationNoneDomain User
SP_SearchService Account to run the SharePoint Search “Windows Service”NoneDomain User
Sp_MySitePoolUsed for the My Sites Web ApplicationNoneDomain User
SP_UserProfilesThe User Profile Synchronization AccountNoneReplicate Directory Changes permission on the domain.

Explanation

The only difference between the Medium security and the High Security option is that we now have a separate account for the Web Application Pool hosting the ‘My Sites’ since it has a different security policy than the other Web Applications . I will only give the details for the new account in the breakdown:

SP_MySitePool is a domain account used for the My Sites Web Application Pool Identity. It’s very similar to the SP_Pool, however it is only used for the My Sites Web Application.

Read More

Hardware and Software Requirements for SharePoint 2013

Applies to: SharePoint Server 2013, SharePoint Foundation 2013

Summary: Lists the minimum hardware and software requirements to install and run SharePoint 2013 with Service Pack 1.

In this article:

 

Important

The information in this article applies to SharePoint Foundation 2013 and SharePoint Server 2013. For information about the features that each version supports, see the SharePoint 2013 Product Page.
Some of the hardware requirement values in this article are based on test results from SharePoint 2010 Products and still apply to SharePoint 2013. This article will be updated with appropriate values and republished when new data becomes available. Hardware requirement values obtained from SharePoint 2010 Products that are listed in this article do not apply to search in SharePoint 2013.
This article links to SharePoint 2010 Products guidance where that guidance is still valid. The SharePoint 2010 Products guidance is not applicable for search in SharePoint 2013 because the search architecture has changed significantly.
The hardware and software requirements in this article refer to physical and virtual servers in a SharePoint farm.

SharePoint 2013 provides for several installation scenarios. Currently, these installations include single server with built-in database installations, single-server farm installations, and multiple-server farm installations. This article describes the hardware and software requirements for SharePoint 2013 in each of these scenarios.

Hardware and software requirements for other SharePoint 2013 capabilities

If you plan to use capabilities that are offered through SharePoint 2013 or through other integration channels, such as SQL Server or Exchange Server, you also need to meet the hardware and software requirements that are specific to that capability. The following list provides links to hardware and software requirements for some SharePoint 2013 capabilities:

Hardware requirements – location of physical servers

Some enterprises have data centers that are located in close proximity to one another and are connected by high-bandwidth fiber optic links. In this environment it is possible to configure the two data centers as a single farm. This distributed farm topology is called a stretched farm. Stretched farms for SharePoint 2013 are supported as of April 2013.

For a stretched farm architecture to work as a supported high-availability solution, the following prerequisites must be met:

  • There is a highly consistent intra-farm latency of <1ms one way, 99.9% of the time over a period of ten minutes. (Intra-farm latency is commonly defined as the latency between the front-end web servers and the database servers.)
  • The bandwidth speed must be at least 1 gigabit per second.

To provide fault tolerance in a stretched farm, use the standard best practice guidance to configure redundant service applications and databases. For more information, see Create a high availability architecture and strategy for SharePoint 2013.

 

Hardware requirements—web servers, application servers, and single server installations

The values in the following table are minimum values for installations on a single server with a built-in database and for web and application servers that are running SharePoint 2013 Service Pack 1 in a single / multiple server farm installation under a Windows Server 2012 environment.

Please note: you must have sufficient hard disk space for the base installation and sufficient space for diagnostics such as logging, debugging, creating memory dumps, and so on. For production use, you must also have additional free disk space for day-to-day operations.

In addition, maintain five times as much free space as you have RAM for development, UAT & production environments.

Installation Scenario Deployment type and scale RAM Processor Hard disk space
Web server in a three-tier farmPilot, user acceptance test deployment of SharePoint Server 2013 or SharePoint Foundation 2013.16 GB64-bit, 4 cores250 GB for system drive
Application server in a three-tier farmProduction, user acceptance test, or production deployment of SharePoint Server 2013 or SharePoint Foundation 2013.32 GB64-bit, 4 cores250 GB for system drive

Hardware requirements – database servers

The requirements in the following table apply to database servers in environments that have multiple servers in the farm.

Note: The requirements listed in this section apply to SQL Server 2014.

Component Minimum requirement
Processor64-bit, 8 cores for small deployments (fewer than 1,000 users)
RAM• 64 GB for small deployments (fewer than 1,000 users) These values are larger than those recommended as the minimum values for SQL Server because of the distribution of data that is required for a SharePoint 2013 environment..
Hard disk500 GB for system drive

Software requirements

The requirements in the following section apply to the following installations:

  • Single server with built-in database
  • Server farm with a single server in the farm
  • Server farm with multiple servers in the farm
Important:
SharePoint 2013 does not support single label domain names. For more information, see Information about configuring Windows for domains with single-label DNS names.

The Microsoft SharePoint Products Preparation Tool can assist you in the installation of the software prerequisites for SharePoint 2013. Ensure that you have an Internet connection, because some prerequisites are installed from the Internet. For more information about how to use the Microsoft SharePoint Products Preparation Tool, see Install SharePoint 2013 on a single server with SQL Server and Install SharePoint 2013 across multiple servers for a three-tier farm.

Note:
SQL Server 2014 requires the May 2014 Cumulative Update to be installed. To install the May 2014 Cumulative Update see Updates to SharePoint 2013.
Note:
Windows Server 2012 R2 is only supported on a SharePoint Server 2013 Service Pack 1 environment. For additional information about Windows Server 2012 R2 support, see SharePoint 2013 SP1 support in Windows Server 2012 R2.

Minimum software requirements

This section provides minimum software requirements for each server in the farm.

Minimum requirements for a database server in a farm:

  • One of the following:
    • The 64-bit edition of Microsoft SQL Server 2012.
    • The 64-bit edition of SQL Server 2008 R2 Service Pack 1
  • The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 Standard or Datacenter
  • The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)
  • FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes (KB 2708075)
  • Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM:
    • Windows Server 2008 R2 SP1 (KB 2759112)
    • Windows Server 2012 (KB 2765317)
  • Microsoft .NET Framework version 4.5

Minimum requirements for a single server with built-in database:

  • The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 Standard or Datacenter
  • The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)
  • FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes (KB 2708075)
  • Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM:
    • Windows Server 2008 R2 SP1 (KB 2759112)
    • Windows Server 2012 (KB 2765317)
  • The Setup program installs the following prerequisite for a single server with built-in database:
    • Microsoft SQL Server 2008 R2 SP1 – Express Edition
  • The Microsoft SharePoint Products Preparation Tool installs the following prerequisites for a single server with built-in database:
    • Web Server (IIS) role
    • Application Server role
    • Microsoft .NET Framework version 4.5
    • SQL Server 2008 R2 SP1 Native Client
    • Microsoft WCF Data Services 5.0
    • Microsoft Information Protection and Control Client (MSIPC)
    • Microsoft Sync Framework Runtime v1.0 SP1 (x64)
    • Windows Management Framework 3.0 which includes Windows PowerShell 3.0
    • Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions (previously named WIF 1.1)
    • Windows Server AppFabric
    • Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)

Minimum requirements for front-end web servers and application servers in a farm:

  • The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 Standard or Datacenter.
  • The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)
  • FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes (KB 2708075)
  • Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM:
    • Windows Server 2008 R2 SP1 (KB 2759112)
    • Windows Server 2012 (KB 2765317)
  • The Microsoft SharePoint Products Preparation Tool installs the following prerequisites for front-end web servers and application servers in a farm:
    • Web Server (IIS) role
    • Application Server role
    • Microsoft .NET Framework version 4.5
    • SQL Server 2008 R2 SP1 Native Client
    • Microsoft WCF Data Services 5.0
    • Microsoft Information Protection and Control Client (MSIPC)
    • Microsoft Sync Framework Runtime v1.0 SP1 (x64)
    • Windows Management Framework 3.0 which includes Windows PowerShell 3.0
    • Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions (previously named WIF 1.1)
    • Windows Server AppFabric
    • Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)

Minimum requirements for client computers

Minimum recommended services for development environments

The following are the minimum SharePoint 2013 services and service applications that are recommended for development environments:

  • App Management service application
  • Central Administration web site
  • Claims to Windows Token service (C2WTS)
  • Distributed cache service
  • Microsoft SharePoint Foundation 2013 Site and Subscription Settings service
  • Secure Store Service
  • User Profile service application (SharePoint Server 2013 only)

Optional software

The optional software in this section is supported but is not required to install or use SharePoint 2013. This software might be required by capabilities such as business intelligence. For more information about system requirements for other capabilities, see Hardware and software requirements for other SharePoint 2013 capabilities.

Environment Optional software
Single server with built-in database, front-end web servers, and application servers in a farm• .NET Framework Data Provider for SQL Server (part of Microsoft .NET Framework) • .NET Framework Data Provider for OLE DB (part of Microsoft .NET Framework) • Workflow Manager You can install Workflow Manager on a dedicated computer. • Microsoft SQL Server 2008 R2 Reporting Services Add-in for Microsoft SharePoint Technologies This add-in is used by Access Services for SharePoint 2013. • Microsoft SQL Server 2012 Data-Tier Application (DAC) Framework 64-bit edition • Microsoft SQL Server 2012 Transact-SQL ScriptDom 64-bit edition • Microsoft System CLR Types for Microsoft SQL Server 2012 64-bit edition • Microsoft SQL Server 2012 with Service Pack 1 (SP1) LocalDB 64-bit edition • Microsoft Data Services for the .NET Framework 4 and Silverlight 4 (formerly ADO.NET Data Services) • Exchange Web Services Managed API, version 1.2 • Microsoft SQL Server 2008 R2 Remote Blob Store which is part of the Microsoft SQL Server 2008 R2 Feature Pack • SQL Server 2008 R2 Analysis Services ADOMD.NET • KB 2472264 If you are running a geo-distributed deployment and your servers are running Windows Server 2008 R2, then installing KB 2472264 can optimize network latency in a dedicated datacenter network. For more information, and to download the software, see You cannot customize some TCP configurations by using the netsh command in Windows Server 2008 R2
Client computer• Windows 7 For information about how to use Windows 7 with SharePoint 2013 in a development environment, see Start: Set up the development environment for SharePoint 2013. • Silverlight 3 • Office 2013 • Microsoft Office 2010 with Service Pack 2 With KB 2553248 • Microsoft Office 2007 with Service Pack 2 With KB 2583910 • Microsoft Office for Mac 2011 with Service Pack 1 • Microsoft Office 2008 for Mac version 12.2.9 Support ends April 9, 2013.

Links to applicable software

To install Windows Server 2008 R2 SP1, Windows Server 2012, SQL Server, or SharePoint 2013, you can go to the web sites that are listed in this section. You can install most software prerequisites through the SharePoint 2013 Start page. The software prerequisites are also available from web sites that are listed in this section. You can enable the Web Server (IIS) role and the Application Server role in Server Manager.

In scenarios where installing prerequisites directly from the Internet is not possible you can download the prerequisites and then install them from a network share. For more information, see Install prerequisites for SharePoint 2013 from a network share.

Prerequisite installer operations and command-line options

The SharePoint 2013 prerequisite installer (prerequisiteinstaller.exe) installs the following software, if it has not already been installed on the target server, in this order:

  1. Microsoft .NET Framework version 4.5
  2. Windows Management Framework 3.0
  3. Application Server Role, Web Server (IIS) Role
  4. Microsoft SQL Server 2008 R2 SP1 Native Client
  5. Windows Identity Foundation (KB974405)
  6. Microsoft Sync Framework Runtime v1.0 SP1 (x64)
  7. Windows Identity Extensions
  8. Microsoft Information Protection and Control Client
  9. Microsoft WCF Data Services 5.0
  10. Windows Server AppFabric
  11. Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)

You can run prerequisiteinstaller.exe at a command prompt with the following options. When you run prerequisiteinstaller.exe at a command prompt, you may be asked to restart the server one or more times during the installation process. After rebooting, you should continue the prerequisite installation by running prerequisiteinstaller.exe with the /continue option.

  • /? Display command-line options
  • /continue This is used to tell the installer that it is continuing from a restart
  • /unattended No user interaction

The installer installs from the file that you specify in the command-line options described in the following list. In this list, <file> signifies the file from which you want to install. If you do not specify the <file> option, the installer downloads the file from the Internet and installs it. If the option does not apply to the current operating system, it is ignored.

  • /SQLNCli:<file> Install Microsoft SQL Server 2008 SP1 Native Client from <file>
  • /PowerShell:<file> Install Windows Management Framework 3.0 from <file>
  • /NETFX:<file> Install Microsoft .NET Framework version 4.5 from <file>
  • /IDFX:<file> Install Windows Identity Foundation (KB974405) from <file>
  • /IDFX11:<file> Install Windows Identity Foundation v1.1 from <file>
  • /Sync:<file> Install Microsoft Sync Framework Runtime SP1 v1.0 (x64) from <file>
  • /AppFabric:<file> Install Windows Server AppFabric from <file> (AppFabric must be installed with the options /i CacheClient,CachingService,CacheAdmin /gac)
  • /KB2671763:<file> Install Microsoft AppFabric 1.1 for Windows Server (AppFabric 1.1) from <file>
  • /MSIPCClient:<file> Install Microsoft Information Protection and Control Client from <file>
  • /WCFDataServices:<file> Install Microsoft WCF Data Services from <file>

Installation options

Certain prerequisites are installed by the prerequisite installer with specific options. Those prerequisites with specific installation options are listed below with the options that are used by the prerequisite installer.

  • Windows AppFabric

/i CacheClient,CachingService,CacheAdmin /gac

  • Microsoft WCF Data Services

/quiet

The prerequisite installer creates log files at %TEMP%prerequisiteinstaller.<date>.<time>.log. You can check these log files for specific details about all changes the installer makes to the target computer.

 

Read More

Backup and restore best practices in SharePoint 2013

by Michael Pomfret on 14th June 2016

 

Applies to: SharePoint Server 2013 Standard, SharePoint Server 2013 Enterprise, SharePoint Foundation 2013

 

Summary: Learn how to implement best practices before you back up and restore a SharePoint 2013 farm.

 

Best practices for backup and restore help make sure that backup and restore operations in SharePoint 2013 are successful and that the environment is protected against data loss or continuity gaps.

 

In this article:

 

Performance best practices for SharePoint backup and restore operations

Backup and restore operations consume server resources and limit server performance while the operations are running. Follow these best practices to reduce resource usage and increase the performance of servers and the backup or restore task.

 

Minimize latency between SQL Server and the backup location

In general, it is efficient to back up to a local disk on the database server instead of a network drive. You can then copy the data later to a shared folder on the network. Network drives with 1 millisecond or less latency between them and the database server perform well.

 

Note:
If you cannot back up to local drives, use network drives with similar latency. Because network backups are subject to network errors, verify the backup action after it finishes. For more information, see “Backing Up to a File on a Network Share” in Backup Devices (SQL Server).

 

To avoid I/O bottlenecks, perform the main backup to a separate disk from the disk running SQL Server 2008 R2 with Service Pack 1 (SP1) and SQL Server 2012. For more information, seeDefine a Logical Backup Device for a Disk File (SQL Server).

By design, most backup jobs consume all available I/O resources to complete the job. Therefore, you might see disk queuing, which can result in greater than usual latency for I/O requests. This is typical and should not be considered a problem. For more information, see Monitor Disk Usage.

 

Avoid processing conflicts

Do not run backup jobs during times when users need access to the system. Typically, systems run 24 hours a day, seven days a week. A best practice is to always run incremental backups to safeguard against server failure. Consider staggering backups so that all databases are not backed up at the same time.

 

Keep databases small for faster recovery times

Keep databases small to speed both backup and restore. For example, use multiple content databases for a web application instead of one large content database. For more information, seeDatabase types and descriptions (SharePoint 2013).

 

Use incremental backups for large databases

Use incremental backups for large databases because you can make them quickly and maintain performance of the environment. Although you can restore full backups faster than incremental backups, continuous incremental backups minimize data loss. For more information about types of backups, see the following resources:

 

Use compression during backup

In some circumstances, you can use compression to decrease the size of backups and the time to complete each backup. Backup compression was introduced in SQL Server 2008 Enterprise. Backup compression increases CPU usage and this can affect SQL Server concurrent operations.

 

Important:
SharePoint Server 2013 supports SQL Server backup compression. SQL Server data compression is not supported for SharePoint Server 2013 databases.

 

For more information about how backup compression affects performance in SQL Server, see the following resources:

 

Follow SQL Server backup and restore optimization recommendations

SQL Server backups use a combination of full, differential, and transaction log backups (for the full or bulk-logged recovery model) to minimize recovery time. Differential database backups are usually faster to create than full database backups and reduce the number of transaction logs required to recover the database.

 

If you are using the full recovery model, we recommend that you periodically truncate the transaction log files to avoid maintenance issues.

For detailed recommendations about how to optimize SQL Server backup and restore performance, see Optimizing Backup and Restore Performance in SQL Server.

 

Use RAID 10 if you use RAID

Carefully consider whether to use redundant array of independent disks (RAID) on the device to which you back up data. For example, RAID 5 has slow write performance, approximately the same speed as for a single disk. This is because RAID 5 has to maintain parity information. RAID 10 can provide faster backups because it doesn’t need to manage parity. Therefore, it reads and writes data faster. For more information about how to use RAID with backups, see Configure RAID for maximum SQL Server I/O throughput and RAID Levels and SQL Server.

 

Configure SharePoint settings to improve backup or restore performance

You can only configure file compression and log file settings in Windows PowerShell. You can configure backup and restore threads in both the SharePoint Central Administration website and Windows PowerShell to increase backup or restore efficiency and performance.

If you use the Export-SPWeb Windows PowerShell cmdlet, you can use the NoFileCompression parameter. By default, SharePoint 2013 uses file compression while exporting web applications, site collection, lists, or document libraries. You can use this parameter to suppress file compression while exporting and importing. File compression can use up to 30% more resources. However, the exported file uses approximately 25% less disk space. If you use the NoFileCompression parameter when you export, you have to also use it when you import the same content.

 

You can also use the NoLogFile parameter. By default, SharePoint 2013 always creates a log file when you export content. Although you can use this parameter to suppress log file creation to save resources, we recommend that you always create logs. Logs are important for troubleshooting and log creation does not use many resources such as CPU or memory.

When you use the Backup-SPFarm cmdlet, you can also use the BackupThreads parameter to specify how many threads SharePoint 2013 will use during the backup process. A higher number of threads will consume more resources during backup. But the overall time to make the backup is decreased. Because each thread is recorded in the log files, the number of threads does affect log file interpretation. By default, three threads are used. The maximum number of available threads is 10.

 

Note:
The backup threads setting is also available through Central Administration on the Default Backup and Restore Settings page in the Backup and Restore section.

 

Consider site collection size when you determine the tools to use

If the business requires site collection backups in addition to farm-level or database-level backups, choose a backup tool that is based on the size of the site collection.

  • Less than 15 gigabytes (GB): Use the Backup-SPSite Windows PowerShell cmdlet. For more information, see Back up site collections in SharePoint 2013.
  • 15-100 GB: Use a SharePoint 2013 tool, a SQL Server tool, or other database backup tool to protect the content database that contains the site collection. For more information, seeBack up site collections in SharePoint 2013.
  • Larger than 100 GB: Use a differential backup solution, such as SQL Server 2008 R2 with SP1 or System Center 2012 – Data Protection Manager (DPM), instead of the built-in backup and recovery tools.

 

Quality assurance best practices to back up a SharePoint farm

Follow these best practices to help ensure the quality of the backups of the farm environment and reduce the chances of data loss.

 

Ensure you have enough storage space

Be certain that the system has enough disk space to accommodate the backup. Configure a backup job in Central Administration to verify the required disk space.

 

Routinely test backup quality

Routinely test backups and validate their consistency. Run practice recovery operations to validate the contents of the backup and to make sure that you can restore the complete environment. To prepare for disaster recovery of geographically dispersed environments, set up a remote farm. Then you can restore the environment by using the database-attach method to upload a copy of the database to the remote farm and redirect users. Periodically perform a trial data recovery action to verify that the process correctly backs up files. A trial restoration can expose hardware problems that do not come up with software verifications and can also to make sure that the recovery time objectives (RTO) are met.

 

Back up ULS trace logs

The SharePoint 2013 backup process doesn’t back up the Unified Logging Service (ULS) trace logs. Data in ULS trace logs can be useful for performance analysis, troubleshooting, and monitoring compliance with service level agreements. Therefore, protect this data as part of the routine maintenance.

By default, SharePoint log files are at C:Program filesCommon FilesMicrosoft SharedWeb Server Extensions15Logs. The files are named with the server name followed by the date and time stamp. The SharePoint trace logs are created at set intervals and when you use the IISRESET command.

 

Store a copy of backup files off-site

To safeguard against loss from a natural disaster that destroys the primary data center, maintain duplicate copies of backups in separate locations from the servers. Duplicate copies can help prevent the loss of critical data. As a best practice, keep three copies of the backup media, and keep at least one copy offsite in a controlled environment. This should include all backup and recovery materials, documents, database and transaction log backups, and usage and trace log backups.

 

Procedural best practices to back up and restore SharePoint 2013

Use the following procedural best practices to plan and perform backup and restore operations.

 

Use FQDN server names

When you refer to servers in a different domain, always use fully qualified domain names (FQDN).

 

Keep accurate records

When you deploy SharePoint 2013, record the accounts that you create, the computer names, passwords, and setup options. Keep this information in a safe and secure location. Possibly, keep multiple records to make sure this information is always available.

 

Have a recovery environment ready

Use a farm in a secondary location to validate the success of restore operations as part of your disaster recovery strategy. For more information, see Choose a disaster recovery strategy for SharePoint 2013. In a disaster recovery situation, you can then restore the environment by using the database-attach method to upload a copy of the database to the remote farm and redirect users. For more information, review and follow the steps in Restore farms in SharePoint 2013. Also for a high availability solution, you can set up a standby environment that runs the same version of software as the production environment so that you can restore the databases and recover documents quickly. For more information, see Describing high availability.

 

Schedule backup operations

Use Windows PowerShell backup and recovery cmdlets to create a script file (*.ps1) and then schedule it to run with Windows Task Scheduler. This makes sure that all backup operations are run at the best time when the system is least busy and users are not accessing it. For more information, see the following:

 

Use the SQL FILESTREAM provider with BLOB storage

Remote BLOB Storage (RBS) is supported in a SharePoint 2013 farm. There are both pros and cons associated with using RBS in SharePoint 2013. One related limitation of RBS with a SharePoint farm is that System Center 2012 – Data Protection Manager (DPM) cannot use the FILESTREAM provider to back up or restore RBS. SharePoint 2013 supports the FILESTREAM provider for backup and restore operations. A benefit of RBS with a SharePoint farm is that you can use either SharePoint tools or SQL Server tools to back up and restore the content database with the Remote BLOB Store (RBS) defined. This backs up and restores both the RBS and the content database. We do not recommend that you use RBS with other restore methods. For more information about the benefits and limitations of using RBS, see Deciding to use RBS in SharePoint 2013.

 

Read More