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
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.
Speaking of onsite and offsite, in Records we learn the seven classes of a disaster:
- Class One: national or international
- Class Two: local or regional
- Classes Three and Four: building destroyed
- Class Five: one or two functions with the organization
- Class Six: sub-function affected
- Class Seven: lost/stolen/misplaced information
SharePoint 2010 countermands the impending threat of lost documentation with a few tricks:
- Versioning. This catalogs user changes.
- Two-Stage Recycle Bin. By default, both stages retain data for thirty days. It is possible to recover documents, list items, lists, document libraries from the bin, but here’s the cincher: Items don’t expire to the second stage -- they expunge. Furthermore, the second stage limit is based on a ratio of the site collections storage quota rather than a set period of time; by default, the second stage of the Recycle Bin is limited to 50% of the site quota (I would love to know the thought motivation behind this design).
- Central Administration. With this version of SharePoint, administrators have more control over content from farm to library level.
- Windows PowerShell and STSADM. Backup can be scripted to run at specific times.
Conclude the tabletop exercise with a hotwash to identify deltas. Draft three to five necessary steps to bridge them. Because the Information Technology and Records departments have service level agreements to uphold, after four or five hours of concentrated planning, return to regularly scheduled activities. But congratulations are in order: This is a vital piece of the SharePoint 2010 Records Governance plan. If done well, it will demonstrate to the Chiefs that the Records and Information Technology partnership is healthy.
Editor's Note: You may also be interested in reading: