SharePoint Backup and Recovery Tools and Best Practices
Backup and restore operations can consume server resources and limit server performance while these operations are running. There is a need to select the right tools and follow best practices for performing these operations.
Choosing Right Tools
Normally an SLA and uptime is set for meeting the continuity requirements with the clients. While selecting the tools for the backup and recovery purpose, you must determine whether you can meet these requirements. The following are the key factors to consider when you select the tools:
· Speed of backup: The tool should be able to perform within the maintenance window for the databases. You should test any backup system to ensure that it meets your needs on your hardware.
· Completeness of recovery: The tool should be able to completely perform recovery operation. If it is not able to support certain recovery then that should be well documented.
· Granularity of recovery: The level of granularity of SharePoint objects like site, web, lists, document, records and so on that can be recovered by the tool.
· Backup type supported: full, differential or incremental.
· Complexity of managing the tool: How complex it is to manage the tool itself.
The following table compares the kind of backup and the size of the farm that can be backed up in a six-hour window for backup and recovery tools available from Microsoft. (This table is from MSDN.)
|
Tool |
Backup type |
Size of backup completed in six hours |
|
SharePoint farm backup and recovery |
Full, differential |
600 GB |
|
SQL Server |
Full, differential |
600 GB |
|
System Center Data Protection Manager |
Incremental |
Terabytes |
There are 3rd party products that perform backup and restore in SharePoint very well, products from Metalogix, AvePoint and so on. In fact, many SharePoint customers use these third-party products because the backup and restore tools were inefficient in MOSS 2007 or SharePoint 2010.
Following Best Practices
Best practices needs to be followed so that you get the best performance at the lowest resource utilization. By using the following best practices, resource usage is reduced and the performance of servers and the backup or restore operation is increased.
· Minimize latency between the backup location and SQL Server
For backups it is best to use a local disk on the database server instead of a network drive. Data can then be copied later to a shared folder on the network. In case you need to use network drives, the database server will perform well on network drives with 1 millisecond or less latency between them. By design, most backup jobs consume all available I/O resources to complete the job. To avoid I/O bottlenecks, perform the main backup to a separate disk from the disk running SQL Server.
· Avoid processing conflicts: Consider staggered backups so that not all databases are backed up at the same time. Also backup jobs should not be run during times when users require access to the system.
· Smaller content databases for faster recovery: Smaller databases can be recovered faster and hence if possible multiple content databases should be used for a Web application instead of one large content database.
· Use incremental backups for large databases: Incremental backups can be restored faster and more efficiently than full backups for larger databases.
Consider site collection size when determining the tools to use. Generally for:
o Less than 15 GB: PowerShell command Backup-SPSite can be used
o 15-100 GB: use SharePoint's backup and restore or database backup tool to protect the content database that contains the site collection
o Larger than 100 GB: use a database differential backup solution instead of the built-in backup and recovery tools like Microsoft's DPM Tool
· Recovery environment should be ready: A recovery environment should always be ready for testing the restoration of the backup. As a process, monthly or bimonthly restoration should be practiced so that when a real disaster happens, the team is ready with the steps.