Your SharePoint Records Governance Plan & ISO 15489: Disaster Preparation & Recovery

By Mimi Dionne (@cawprhyd) Jul 20, 2011

ISO 15489 barely mentions disaster preparation and recovery outright. In fact, the most extensive statement on this topic in ISO 15489 appears in the Technical Report (Part Two): "Risk management also involves development of a disaster recovery plan that defines an organized and prioritized response to the disaster, planning for the continuance of regular business operations during the disaster and making appropriate plans for recovery after the disaster.”

If you blink, you’ll miss it. Perhaps we Records folk aren’t as comfortable with the topic as we should be. So, let’s take a step back to refresh ourselves.

Disaster preparation and recovery begins with a simple, no-fault tabletop exercise among Records, Information Technology and end users to identify critical infrastructure and key resources. The traditional four phases of this exercise are:

Prepare and protect
Respond
Recover
Mitigate

Here’s the catch: When crafting a SharePoint 2010 Records Governance plan, be aware that, although we Records colleagues learn seven classes of disasters, SharePoint 2010 doesn’t answer all seven. More on that in a moment.

Records and IT must prove to senior management that one or more critical functions will resume following an interruption. In SharePoint 2010, disaster preparation and recovery is best expressed in terms of diverse geographic locations of servers and vital records identification through metadata.

So how does the Records department protect itself, Information Technology and the business by avoiding data corruption and third-party software failure? An awareness campaign around what SharePoint 2010 does well and what it does not do well. Let’s face it: We want to select software that doesn’t require us to restore basic functionality before we can restore any customizations to the software in the event of a disaster, right? In fact, the goal should be to reduce data loss and downtime as well as to preserve data integrity.

Old Microsoft has a Farm, But the Chorus isn’t E-I-E-I-O

In the SharePoint 2010 Administrator’s Companion, Microsoft champions redundancy for the usual suspects (front-end servers, application servers, SQL Server instances, Internet Information Services [IIS] and the Domain Name System [DNS]) as part of the disaster preparation and recovery plan. Examples of multiple installations of hardware include:

Servers (clustering)
Hard drives (RAID installations)
Network routers and switches
Network interface cards
Extra power supply sources
Extra cables

The Companion assures Dear Reader that SharePoint 2010 performs full and differential backups on the entire farm, farm configuration information, service applications, web applications and content databases. What’s more, SharePoint 2010 performs granular backups. For the Records and Information Manager, this means site collections, sites, libraries and lists can be copied. Through the Backup and Restore interface, the administrator role can start a site collection backup, export a site or list, recover data from an unattached content database or check the status of a currently running granular backup.

Also, SharePoint 2010 introduces a backup file containing antivirus settings, information rights management (IRM), outbound email settings, diagnostic loggings and workflow. The Companion advises, though, that there are limitations: Backups/restores are not scheduled, more than one Web application or service application cannot be backed up simultaneously without performing an entire farm backup and SharePoint 2010 doesn’t allow you to make backups directly to tape.

Location, Location, Location

Just as I recommend two documents to support your SharePoint 2010 Records Governance plan — the plan itself and the environmental design — the Administrator’s Companion recommends two types of documentation: SharePoint dependent and SharePoint component. SharePoint dependent translates to a descriptive account of all dependent software, hardware and network components (for example, the operating system, SQL Server and IIS). SharePoint component refers to Central Administration settings, index settings, WFE and service application settings. Also, all service packs, hot fixes, antivirus programs and other software additions should be described, and multiple copies should be stored on- and offsite.