Someone added an interesting comment to the announcement of my “Backup and recovery planning 101” session at SharePoint Conference Ukraine. The guy said they had a problem recently when a SharePoint restore did not work. So the comment was “backups don’t save you from trouble“, and I think it’s worth looking into in more detail. Here’s the situation as it was described:

  1. Several designers are working on a custom application in production SharePoint
  2. One of them leaves the desk with a bunch of unsaved changes on screen
  3. At the same time, another member of the team makes edits and removes “unnecessary” roles (permission levels)
  4. The first designer comes back and saves objects that are dependent on no longer existing permission levels

Well… of course backups don’t save you from trouble when you did everything to get into that trouble! Here’re my 5 tips that could have helped to avoid the failure – and most of this is not about backups:

  • Never develop or test an application in your live production system. If you think you do not have a test environment, you are wrong – you do have a test SharePoint farm. It’s just by mistake you call it your production.
  • Define roles and responsibilities. These two designers making simultaneous changes to the same app could have probably better split their work to mitigate risks and dependencies.
  • Implement change control processes. With a proper change control in place, all team members would have reviewed and signed off on all of the suggested changes before anyone started editing anything.
  • Assess different SharePoint failure scenarios and their business impact, ranging from entire farm disaster recovery down to a single item recovery. How critical is the failure on each of these levels for the business processes? What happens if all SharePoint services become unavailable? How much data your business can afford to lose?
  • Develop and implement backup and recovery plan based on these findings. Establish a practice for testing backups and performing fire drill recoveries to ensure the plan continues to work as the SharePoint environment evolves.

What we have here is an example of extremely poor SharePoint governance. As much as the term itself may be confusing, the lack of governance is usually obvious. See this great post by Susan Hanley for a broader discussion of governance and guidance.

A proper backup and recovery plan is designed to minimize the business impact in case of data loss or service unavailability, based on the estimated scale of this impact. However, backups are only a part of the organization’s efforts to ensure business continuity. Having a backup in place cannot be an excuse for ignoring the need to properly govern your SharePoint customization and deployment.

Technorati Tags:
%d bloggers like this: