Microsoft's collaboration tool SharePoint is architecturally complex. It has a difficult logical recovery process, where later editions of checked out documents need to be synchronized with the recovered server environment.
Although SharePoint is usually included in the OS disaster recovery scheme, its special business and technical considerations are often neglected. For example, an IT shop may not fully document SharePoint's environmental needs in its business continuity plan. And, it may overlook SharePoint post-recovery work during its disaster recovery planning process. Including these considerations can greatly expedite SharePoint recovery efforts.
Here are some other key areas Windows managers need to address when planning for SharePoint disaster recovery:
- High-availability conflicts – SharePoint may need to be a highly available business tool because large global firms that use this tool operate with no downtime. This could affect the scheduling window for SharePoint backup because the most reliable level of backups are usually achieved when all servers and users are offline.
- Huge objects affect performance – SharePoint documents can be large because complex Microsoft Office documents are often several megabytes in size. This may impose time limitations for the backup window or lengthen recovery efforts when compared to standard applications.
- Post-recovery adjustments – The logical recovery process is often neglected in a disaster recovery plan and lengthens recovery efforts. After physical recovery of SharePoint, adjustments are often needed to check in/out settings, re-index servers and update security permissions. It is also important to include the primary domain servers carrying security permissions during the nightly backup.
Planning for SharePoint disaster recovery
With a little care and attention, SharePoint backup and recovery can be successful.
But protecting the SharePoint environment doesn't stop there. Disaster recovery protection also requires good planning, active adjustments for business or technology changes, and regular testing of the process.
Many companies that use SharePoint to support their most important business requirements must make special accommodations for its recovery in their business continuity plan. To make sure that SharePoint is protected in an emergency, Windows managers should do the following:
1. Create a business risk assessment – The team must not only evaluate how SharePoint is being used but also its associated business impact. When determining how this tool is used, the team should ask the following questions:
- What business functions does it support?
- Are there multiple environments?
- How large are the databases?
- How often do documents and user permissions change?
- Do any external business partners use it?
- How long can the system be offline in the event of an outage?
When creating a business risk assessment, the DR team should also determine recovery rank among competing critical applications and document business-related workarounds.
2. Document SharePoint needs – The SharePoint infrastructure with all its special needs must be documented and kept up-to-date as major changes occur. DR teams should also include company and vendor contacts in this documentation to help facilitate future recovery efforts. Creating an intranet-based website for all disaster recovery needs is an excellent way to ensure the most current version of documentation is available.
3. Perform manual reconciliation – Windows managers may find that documents on the recovered server may be outdated by versions on the user's desktop. During an actual recovery, users will need to manually check all the documents they have recently worked with. The administrator may need to override controls so that the latest workstation editions are published to the servers. This activity should be included in the plan to ensure a more complete recovery process.
4. Train SharePoint administration – Appointing and training SharePoint systems administrators will help ensure that all the special needs for recovery will be met. A backup administrator is also needed. Managers may have to put these designated roles on a part-time basis for current systems administrators in smaller companies. Systems administrators who lack detailed knowledge can physically recover the servers, but trained professionals will do a better job of handling post-recovery needs.
5. Perform offline backups – For global companies operating on a 24/7 basis, planned downtime or clustering may be needed so that all users are offline. The backups must include SharePoint Server's primary server, SQL Server repository and domain servers containing security permissions. This will allow for a unified point-in-time recovery, rather than trying to piece together the environment.
6. Test the disaster recovery plan – Many companies test their most critical applications, but because SharePoint appears to be straightforward, it is often left out of the testing process. If SharePoint is a critical business resource for the company, it must be included in the quarterly or annual disaster recovery tests.
7. Use special recovery tools – Even with the best planning, sometimes a DR team needs tools like staadm.exe to help recover deleted or inaccessible documents in SharePoint. Before using these tools, Windows administrators should practice in a lab environment.
When SharePoint Server is a critical business tool, its disaster recovery special needs must be addressed ahead of time. It should not be bundled in the standard Windows recovery effort.
When companies properly research and plan all SharePoint business and technology requirements, it will reduce recovery risks, save time and -- most important -- save valuable information from being lost when disaster strikes.
Harry L. Waldron has more than 35 years of experience in the IT profession. A Microsoft MVP, he works as a senior developer for Parsippany, N.J.-based Fairfax Information Technology Services where he provides technical, business and leadership support on key development projects. He writes about security and best practices for several technical forums, including myITforum.com.
This was first published in July 2008