What is disaster recovery planning? The National Association of State Chief Information Officers (NASCIO) describes it as follows.
Disaster
recovery and business continuity planning provides a framework of
interim measures to recover IT services following an emergency or system
disruption. Interim measures may include the relocation of IT systems
and operations to an alternate site, the recovery of IT functions using
alternate equipment, or execution of agreements with an outsourced
entity.
This is an
all-encompassing definition that succinctly outlines the steps necessary
to resume Information Technology (IT) operations quickly after a
catastrophic event.
Threats to the integrity of
your data can be classified in three primary categories: natural,
human-induced, and technological malfunctions. An example of a natural
disaster is one caused by a fire, flood, earthquake, or tornado. A
human-induced disaster is one caused by human error or intervention,
which can be intentional or unintentional. Examples of human-induced
disasters include viruses, accidental or malicious deletion or
modification of information, or any other event that is directly related
to human intervention and that causes an interruption of your
technology infrastructure. A technological malfunction includes any
software or hardware failure that is not a direct result of human error.
You can probably guess that most disasters fall into either the
human-induced or technological malfunction categories, and these are the
main reasons you need a disaster recovery and business continuity plan.
|
It is common for an
enterprise-level IT department to spend as much 25 percent of its budget
on disaster recovery. Less than 50 percent of companies have a disaster
recovery plan, however, and more than half of the ones that do have a
plan don’t conduct regular tests of its effectiveness. Honestly, a
company may as well not have a disaster recovery plan if it isn’t tested
regularly. If a disaster occurs, you must be familiar with the steps
necessary to perform an accurate and efficient recovery of each
SharePoint component. Performing periodic tests of your disaster
recovery plan will help you stay knowledgeable about what steps are
necessary to recover from the different disaster types that can occur.
|
Every good SharePoint
disaster recovery plan should include information about backup and
restore procedures as well as redundancy, both of which will help
achieve three primary disaster recovery goals: to minimize data loss,
maintain data integrity, and minimize SharePoint downtime. Your backup
strategy drives your restore strategy, which is what you will use to
help recover your SharePoint content as efficiently as possible.
1. The Importance of Redundancy
A single word that summarizes the most effective solution for a SharePoint disaster recovery plan is redundancy.
This means that you have multiple installations of all software and
hardware that is utilized by SharePoint and the supporting components.
Examples of multiple installations of software include
SharePoint Web front-end (WFE) servers
SharePoint application servers
SharePoint Services
SQL Server Instances
SQL Server Database Mirroring
Internet Information Services (IIS)
Domain Name System (DNS)
Examples of multiple installations of hardware include
Servers (Clustering)
Hard drives (RAID implementations)
Network routers and switches
Network interface cards
Extra power supply sources
Extra cables
Note:
Although redundancy
is used in almost all disaster recovery plans, there are some rare
instances when it may not be part of the disaster recovery plan. For
instance, nuclear power plants have a federal mandate to have a disaster
recovery plan for operating entirely without computers.
2. The Role of Backups
Backups are copies of your
SharePoint information that are used to replace lost or damaged
information in the event of a disaster. This information includes
SharePoint information stored in SQL Server databases as well as any
other software that integrates with SharePoint containing information
required for a successful recovery of SharePoint, such as IIS
information, DNS information, Web application information, and search
indexes stored on hard drives.
Note:
BEST PRACTICES
When considering the addition of third-party software, select software
that doesn’t require you to restore the basic functionality before
you can restore any customizations to the software in the event of a
disaster. The last thing you need during a disaster recovery effort is
to discover that the third-party software you purchased was so deeply
nested and integrated into the SharePoint platform that you couldn’t
restore basic functionality without restoring the third-party software.
Be sure that you completely understand the backup and restore processes
for all the third-party software in your environment.
The strength of your backup
plan determines the steps you need to take to restore your SharePoint
information during a disaster recovery, how quickly you can recover your
farm, and whether there will be any loss of data.
2.1. Storing Backups
Often organizations keep a copy
of backups locally to allow a speedy recovery of information after a
disaster. However, the saying “location, location, location” is
essential here! Remember that your three primary goals are to minimize
data loss and downtime, as well as maintain data integrity. Keeping the
backups in the same location as the “live” information you are using
won’t help in the event of a natural disaster. Therefore, you should
keep another copy of the backups in a remote location. Depending on the
type of natural disasters to which your area is prone, the remote
location could be another area in the same building or a physical
location far away from your main datacenter.
The type of media to which
the information is backed up and the type of backups you use can have an
impact on the amount of time it takes to recover your SharePoint
information. For instance, backing up to a local network share will
normally expedite both the backup and restore operations, compared to
backing up or restoring from tape. However, you still may want to back
up to tape (here is a good example of redundancy) so that you can ship
the backup tapes to a remote location.
2.2. Types of SharePoint Backups
The types
of backups you use also will affect the amount of time required to back
up and restore SharePoint Information. SharePoint 2010 allows two types
of backups: full and differential,
both of which can be performed from within Central Administration,
using Windows PowerShell, or using STSADM.
You can perform a full or differential backup on the following components of SharePoint 2010.
A full backup contains all information within the specified SharePoint component, regardless of
whether it has changed or not since the last full backup. It is a
snapshot of the information within that SharePoint component. You always
have to perform a full backup of the SharePoint component before
performing a differential backup.
A differential backup
only contains the information that has changed since the last full
backup. This backup type can only be used after a full backup has been
performed. A differential backup usually takes less time than a full
backup, because you are only backing up the changes and not the data
that hasn’t changed. This reduces the amount of time that it takes to
complete the backup. A differential backup can also be called a
cumulative backup, because as time passes after the last full backup,
more and more changes occur within SharePoint, which creates more
information that needs to be backed up, which increases the backup time
required.
Note:
BEST PRACTICES
No matter what type of backup you perform, the backups should be
performed after hours or during nonpeak hours to minimize contention
between the information being accessed by the users and your backup
jobs.
SharePoint 2010 introduces the ability to perform granular
backups, which gives you the opportunity to create copies of site
collections, sites, libraries, and lists contained in SharePoint.
Granular backups do not provide the option of specifying a full or
differential backup type, however; they will contain all the content,
whether or not it has changed.
The method you use for
your backups will determine if the backup process can be scheduled or if
backups will have to be performed interactively. You may find this to
be a determining factor when you are deciding which backup method to
use.
3. Restores
The backups you
perform regularly are created for use during the restore process. The
restore process involves taking copies of the data that you have backed
up and copying them to the original location to recover lost data. If
there is existing data on the location, it will be overwritten during
the restore process. If you lost the hard drive that contained the
original information, you will copy the information from the backup to
its original location on the new hard drive.
Restores also can be used to
copy data to different locations if you want to share or create
duplicate access points to your information. This can be helpful when
sharing data between farms, or if you choose to move data from a test
environment to a production environment.
SharePoint 2010 introduces the ability to perform granular
restores at the site collection, site, library, and list levels.
However, you cannot import data using Central Administration; this can
only be done using the STSADM or Windows PowerShell command-line
utilities. You can perform a second-stage Recycle Bin recovery from
within Central Administration, and this provides an easy way for a site
collection administrator to recover a deleted document quickly.
The restore process can be
scheduled to occur at specified times, or it can be manually performed
in real time, just like backups. Unlike backups, restores most often
occur interactively—and they most often occur during a crisis, so it is
imperative that you are completely familiar with the tools available to
you for the restore process.
Your nongranular restores
must occur in a specific order: the full database backup must be
restored first; then you should restore your differential backups.
Note:
Analyze, define, and document
your restore process. This will expedite the recovery of your
SharePoint information and assist in achieving minimal data loss and
maximum availability.
To
summarize, designing a disaster recovery plan for your SharePoint
information involves the use of redundancy of all SharePoint components
including your data stored in your backups. The restore process is
critical in disaster recovery because you are restoring the backups that
contain a copy of your data, which again emphasizes the importance of
redundancy in your disaster recovery plan.
