
Microsoft SharePoint has become a mission-critical platform for organizations seeking effective information sharing and efficient team-based collaboration. As a result, robust protection of SharePoint data and rapid recoverability from disasters are now requirements, not options. Diverse business functions and a complex, distributed architecture require a comprehensive approach to SharePoint platform and content recovery. Using only native SharePoint tools and SQL backups, organizations will experience continued exposure to risk of business-critical information loss.
Protecting Your Data
What type of backup and restore capabilities does SharePoint data demand? It’s a question that those new to Microsoft SharePoint often have difficulty answering. It is helpful to start by identifying what successful organizations must expect with regard to the availability of SharePoint data:
Accidentally deleted or corrupted data must be restored in a reasonable period of time, without excessively burdening IT staff and resources
All data must be totally preserved and restored, including all of its metadata
Data must be backed up at a level commensurate with its business-importance
The system empoloyed to protect data must be cost-effective
These basic criteria – reasonable from a business perspective – simply can not be achieved when leveraging Microsoft SharePoint’s native tools alone. Reliance upon command-line and SQL Server backups fail to meet our criteria for a number of reasons:
SQL backups do not discern between data, and are very resource intensive to perform. As a result, they cannot be executed at a frequency adequate to optimally protect highly-critical data.
Most recovery jobs involve the restoration of only a single, or a handful of,items. Restoring the entire SQL database simply to recover only a few items is wasteful of precious staff and system resources.
STSADM and SQL Server backups can maintain metadata, but only if the entire database is restored. So administrators are left with a choice: Lose all content changes that have occurred since the last backup, or restore the database to a staging environment, extract the desired item, and lose all of its metadata. Neither option is acceptable.
Full database backups require high levels of storage space. Frequently backing up SharePoint data leveraging only native tools demands unreasonable amounts of costly storage space.
Protecting Your Platform
Today, consistent and reliable access to the Microsoft SharePoint platform is a business-necessity. Determining exactly how your organization should ensure adequate platform availability requires the formation of a service level agreement (SLA) that answers these critical questions:
Following platform failure, how fast must the production environment be back online?
What type of staff and system resources can we afford to dedicate to the restoration process?
For SharePoint Administrators, leveraging only SharePoint’s Central Administration and/or SQL Server backups to maintain platform availability is difficult for two key reasons:
SharePoint demands a distributed server farm architecture, including Front End web servers, application servers, index and search servers, and back-end SQL servers. Native tools only protect the SQL database, requiring all other databases be reconstituted manually
Each one of these individual SharePoint server components will have configurations stored in various locations, including databases, file systems, and/or SharePoint Solutions/Features repositories. The task of identifying and protecting the files and configurations necessary to recover these Microsoft SharePoint environments is time consuming, tedious, and prone to human-error/oversight.
For truly business-class data protection, Microsoft SharePoint’s native tools are simply not adequate . To learn how to deliver cost-effective, item through platform-level protection – all while optimizing system resources – keep reading.