Disasters happen. Networks fail. Databases can be corrupted. Content gets deleted. And then IT steps in. Before you know it, everything is up and running once more.
Except that’s not the reality for most.
During a recent industry event, we asked a small group of SharePoint administrators about their disaster recovery plans and the tests they perform to ensure they are prepared for the worst.
The reality was shocking. Just one in four companies test their SharePoint recovery plans. Of those, 75 percent report their recovery tests failed. While few companies would ever publicly admit that level of failure, extrapolate the data. If 75 percent of tests failed for 25 percent of all users, imagine the impact of a real-life disaster.
So Much to Lose
SharePoint outages can result in days or weeks of lost user productivity, increased potential for data loss, security breaches and, even worse, an end to the SharePoint administrator’s once stable employment.
SharePoint’s use is growing, as evidenced by recent reports that SharePoint adoption is maturing into an “always-on” (tier 1) requirement. SharePoint is generally considered a powerful tool that enables better collaboration. For many, it has become mission-critical. Yet SharePoint disaster management still isn’t taken seriously. Remember:
Testing Isn’t a One-Off Process
Once is not enough when it comes to testing SharePoint disaster recovery plans. Incremental tests should be conducted periodically to test processes, documentation, permissions and backups. SharePoint is a very active environment and change is a constant, which only increases the likelihood that tests will fail. Studies show 66 percent of successful recovery tests involve a change to the plan. Therefore, organizations that recognize, document, and create action plans for those changes greatly decrease their potential for losing data.
Of course, not every disaster is catastrophic. Most disasters are small. Applications go down and data goes missing, but organizations that build true enterprise-grade disaster recovery plans can quickly pivot and solve the issue.
Set a Recovery Point Objective
As SharePoint content grows, the potential for disaster increases exponentially. To help mitigate the impact, teams need to establish a Recovery Point Objective (RPO) — the amount of data loss that would be acceptable in any event. The larger the content database is, the longer a backup takes. The more important the system or data, the shorter the RPO.
Implementing a Recovery Plan
Recovering from a SharePoint database outage requires more than just reloading a database file. The recovery process involves reconstructing the application and supporting environment, including all configurations, permissions, and workflows.
So how do you win? Here are three things every company should consider when planning for SharePoint disaster recovery:
- Test your ability to recover: Take action before a crisis occurs. Weekends are a great time to do this. Then test again – once a quarter, if possible (or once a year, at a minimum). Provide yourself an honest evaluation of recovery points and times, especially as your environment grows. What worked last year may not work this year.
- Decrease your SharePoint environment’s footprint: Use a Remote BLOB Storage (RBS) solution to move content outside of SharePoint, where it can be backed up and ready to go anytime with less strain on your database. This action will shrink the SharePoint database by up to 98 percent, turning database backup times into minutes instead of hours or days.
- Perform incremental backups. Use a tool that allows incremental backups so that backup and recovery times are dramatically reduced.
Disasters are inevitable with any network environment. But being prepared will do more than just save time and protect your SharePoint environment. It could save your job.
Title image by A_Lesik (Shutterstock).