This blog post describes best practices that you can use to help ensure that backup and recovery operations in Microsoft SharePoint Server 2010 are successful and that the environment is protected against data loss or continuity gaps. The article includes best practices for performance, quality assurance, security, and operational excellence
There are two different approaches for backup and restore
- Content/Config Database Backup using SQL Server
- Backup using SharePoint Server
Lets look at each approach in details
1) Content/Config Database Backup using SQL Server
Approach one is to use SQL Server backup to back content DBs and Configuration DBs with a complete script for deployment of Web application, Site Collection, Service Provisioning.
a. Create Deployment script of entire Farm. This will include below components of SharePoint
i. Web Application Creation
ii. Site Collection Creation
iii. Service Application Creation and Provisioning
iv. Association of Service Application with Web Application
v. Deployment of Custom Code (WSP)
b. Use SQL Server Backup for backing up all Content Database & Configuration Database
c. Backup the entire 12 hive (c:\program files\common files\microsoft shared\web server extensions\12). This is because, frequently you will deploy code to your SharePoint farm, and you will need to restore the supporting physical files for the site to work properly.
d. You need to keep monitoring the size of your content databases. If you start hitting the 50GB mark, think of splitting them up, so the backups are done overnight before users start hitting the database in the morning.
e. Backup the entire INETPUB directory.
In case of disaster we need to follow below steps to recover/restore content for approach 1
a. Create Web Application and Site collection using the deployment script
b. Attach/de-attach Content database for new created Site collection
Customizations to SharePoint sites can include the following:
a. Master pages, page layouts and cascading style sheets. These objects are stored in the content database for a Web application.
b. Web Parts, site or list definitions, custom columns, new content types, custom fields, custom actions, coded workflows, or workflow activities and conditions.
c. Third-party solutions and their associated binary files and registry keys, such as IFilters.
d. Changes to standard XML files.
e. Custom site definitions (Webtemp.xml).
f. Changes to the Web.config file.
How customizations are deployed, and how changes are made to the Web.config file, have a significant effect on which tools can be used to back up and recover customizations. To provide the greatest opportunity for recovery, we recommend that you deploy customizations by using solution packages and configure the Web.config file by using Central Administration or the SharePoint APIs and object model.
1) it is easy to maintain and backup/restore over many SharePoint farms.
2) It needs little administrative work when moving site collection from one farm to another or one web application to another web application
3) Takes less time to backup and restore.
4) Unattached Content Database Recovery allows you to browse through the content database using SharePoint, navigate to a list or document library and save the list or library into .cmp file which can easily be moved between sites
1) When restoring, web application or Site collection has be created using Central admin or PowerShell before restore
2) SQL Server does not provide SharePoint Farm backup
2) Backup using SharePoint Server:
Approach two is to use SharePoint Server backup to backup Farm, Web application, content DBs and Configuration DBs
a. Create backup script of entire Farm. This will include below components of SharePoint
i. Web Application backup
ii. Site Collection backup
iii. Service Application backup
In case of disaster we need to follow below steps to recover/restore content for approach 1
a. Restore entire farm or restore individual Web application or site collection separately
a. Web interface for backup and restore within Central Admin Site
b. SharePoint backup provides granular level backup for Site Collection and Web
c. SharePoint backup provides Entire Farm Level backup
a. High restore time
b. No back up directly to tape
c. no custom solution files backup
Backup and restore operations can consume server resources and limit server performance while the operations are running. By following these best practices, you can reduce resource usage and increase the performance of servers and the backup or restore operation
Minimize latency between SQL Server and the backup location
1. In general, it is best to use a local disk on the database server, not a network drive, for backups, and 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 will perform well.
2. To avoid I/O bottlenecks, perform the main backup to a separate disk from the disk running Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2.
3. 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 I/O request latency. This is typical and should not be considered a problem.
Avoid processing conflicts
1. Do not run backup jobs during times when users require access to the system. Consider staggering backups so that not all databases are backed up at the same time.
Keep databases small for faster recovery times
1. Keep databases small to speed both backup and recovery. You can do this by using multiple content databases for a Web application instead of one large content database.
Use incremental backups for large databases
1. Use incremental backups for large database such as those available with DPM 2010. Incremental backups can be restored faster and more efficiently than full backups for larger databases
Use compression during backup
1. In some circumstances, you can use compression to improve backup size (30% decrease) and times (25% decrease). Backup compression has been in introduced in SQL Server 2008 Enterprise
Follow SQL Server backup and restore optimization recommendations
1. If you are using 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 amount of transaction log required to recover the database
Configure SharePoint settings for better backup or restore performance
1. You can configure settings in both Central Administration and Windows PowerShell to increase backup or restore efficiency and performance
2. If you are using the Export-SPWeb Windows PowerShell cmdlet, you can use the NoFileCompression parameter. By default, SharePoint Server 2010 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, but the exported file will use approximately 25% less disk space. If you use the NoFileCompression parameter when exporting, you must also use it when you import the same content.
3. You can also use the NoLogFile parameter. By default, SharePoint Server 2010 always creates a log file when you export content. You can use this parameter to suppress log file creation to save resources. However, we recommend that you always create logs. This is because logs can be used in troubleshooting. Moreover, log creation does not use many resources
4. If you are using the Backup-SPFarm cmdlet, you can use the BackupThreads parameter to specify how many threads SharePoint Server 2010 will use during the backup process. The more threads you specify, the more resources that backup operation will take, but the faster that it will finish, if sufficient resources are available. However, each thread is reported individually in the log files, so using fewer threads makes interpreting the log files easier. By default, three threads are used. The maximum number of threads available is 10
Consider site collection size when determining the tools to use
1. If the business requires site collection backups in addition to farm-level or database-level backups, select the tools that you will use based on the site collection size
a. Less than 15 gigabytes (GB): Use the Windows PowerShell command Backup-SPSite.
b. 15-100 GB: Use a SharePoint Products and Technologies tool, a SQL Server tool, or other database backup tool to protect the content database that contains the site collection.
c. Larger than 100 GB: Use a differential backup solution, such as Microsoft SQL Server 2005 or DPM 2010, instead of the built-in backup and recovery tools
You can 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 adequate storage space
Be certain that the system has adequate disk space to accommodate the backup
Routinely test backup quality
Routinely test backups and validate their consistency. Run practice recovery operations to validate the contents of the backup and to ensure that you can restore the entire environment. For geographically dispersed environments, prepare for disaster recovery by setting up a remote farm. Then you can restore the environment by using the database attach command to upload a copy of the database to the remote farm and redirect users. Periodically perform a trial data recovery operation to verify that the files are correctly backed up. A trial restoration can expose hardware problems that do not show up with software verifications.
Back up ULS trace logs
The SharePoint Server 2010 tools do not back up the ULS trace logs. Data in ULS trace logs 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. For more information about backing up the ULS logs
Store a copy of backup files off-site
To safeguard against loss from a catastrophic event, such as a fire or earthquake, maintain duplicate copies of backups in a separate location from the servers. Doing so can help protect you against 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
You can use these procedural best practices to help plan and perform backup and restore operations with better documentation, more ease, and greater assurance.
Use FQDN server names
When referring to servers in a different domain, always use fully qualified domain names (FQDN).
Keep accurate records
When you deploy SharePoint Server 2010, record the accounts that you create, and the computer names, passwords, and setup options that you choose. Keep this information in a safe place.
Have a recovery environment ready
Prepare for restore testing and disaster recovery by setting up a remote farm. Then you can restore the environment by using the database attach command to upload a copy of the database to the remote farm and redirect users. Similarly, you can set up a standby environment running the same version of software as the production environment so that you can restore the databases and recover documents quickly.
Schedule backup operations
If you want to schedule backups, you can use the Windows Task Scheduler to run them by using a Windows PowerShell script file (*.ps1).
Use the SQL FILESTREAM provider with BLOB storage
If you are using BLOB storage using the SQL FILESTREAM provider and you back up the content database with that Remote BLOB Store (RBS) defined, both the RBS and the content database will be backed up and restored when you use SharePoint tools or SQL Server tools. We do not recommend that you use RBS with other restore methods.