Follow

Disaster Recovery

Created by: Justin Johns
Created date:
Last Updated date:

Disaster Recovery

NOTE: The intent of this document is to assist in the design and implementation of a disaster recovery plan for an AccessData eDiscovery or Summation Pro environment.

AccessData strongly recommends that, due in part to the potential complexity involved with the recovery of an AccessData eDiscovery or Summation Pro environment, AccessData Support Engineers be engaged in the planning and execution of any disaster recovery scenario. Please contact AccessData support via email at support@accessdata.com or visit the support portal at http://support.accessdata.com for more information or assistance.

This document provides some best practice guidelines on how to approach data backup with respect to the AccessData eDiscovery and Summation Pro environments. AccessData is not responsible for the design, implementation, or monitoring of any client disaster recovery process.

 

The Importance of a Disaster Recovery Plan

The importance of a disaster recovery plan cannot be overstated. Regardless of industry, when an unforeseen event takes place and brings day-to-day operations to a halt, an organization needs to recover as quickly as possible and continue to provide services to its clients.

The value of a disaster recovery plan comes not only from an ability to cope with catastrophes like data security breaches and natural disasters, but also from an ability to recover from accidental file deletions or coding mistakes. Not having a disaster recovery plan in place can put the organization at risk of unanticipated financial costs, reputation loss, and potentially even greater risks for its clients and customers.

 

What should a Disaster Recovery Plan include?

The global standard for I.T. disaster recovery, ISO/IEC 27031, states, “Strategies should define the approaches to implement the required resilience so that the principles of incident prevention, detection, response, recovery, and restoration are put in place.” Your strategies define the approach when responding to an incident, while your plan describes how you will do it.

The following sections touch upon the questions that an organization must answer for itself when building a disaster recovery plan.

 

What might go wrong?

The first step in the design of a disaster recovery plan is to identify potential points of failure in your environment. To get you started, here are two of the most common incidents addressed in most disaster recovery plans:

  • Hardware will fail. Modern hardware has become increasingly resistant to most failures, but eventually a hard disk drive or RAM stick is going to fail. Including a strategy for dealing with such issues in your disaster recovery plan will help to reduce downtime and protect against the potential for data loss.
  • People make mistakes. Nearly everyone has accidentally saved over the top of a document or had their computer crash before they could save an important file. Identifying a strategy that accounts for these types of mistakes is critical as they are common and can be among the most difficult to prevent and correct.

 

Who needs to be involved?

Once you have identified the goals of your disaster recovery plan, you should begin identifying all of the individuals and organizations that will be required to participate in its planning, implementation, and execution. 

AccessData recommends documenting the individuals and organizations involved in all stages of your disaster recovery plan, including the following information:

  • The name of the individual or group,
  • The contact information of the individual or group,
  • The availability of the individual or group, and
  • The tasks to be performed by the individual or group.

AccessData recommends that any disaster recovery plan include the duplication of critical skills so that, in the event that an individual is unavailable during a disaster recovery scenario, the execution of the plan is not impacted.

 

How do we respond and recover?

By this point, you should have begun to outline the scenarios that the disaster recovery plan will address and identify the individuals necessary to implement a response. The next step is to define the policies necessary be capable of responding to each of your identified scenarios.

Draw upon the knowledge and experience of experienced managers within the organization to help craft a plan that will fit the unique scenarios and goals specific to your organization. Organizations that do not have this type of expertise in house can leverage outside options, such as trained consultants, to assist with the development of your plan.

Among the most common shortcuts used by organizations are disaster recovery plan templates. While templates might not cover every need specific to your organization, they are a great place from which to start one's preparation. Templates help simplify the preparation process, provide guidance, and can even reveal aspects of disaster recovery that might otherwise have been forgotten.

 

Will the plan work?

The primary goal of any disaster recovery plan is to help an organization maintain its business continuity, minimize damage, and prevent losses. Thus the most important question to ask when evaluating your disaster recovery plan is, "Will the plan work?" The best way to ensure the reliability of a plan is to practice. AccessData strongly recommends having the appropriate people actually practice what they would do to help recover business function should a disaster occur.

AccessData also recommends scheduling regular reviews and updates of existing recovery plans. Some organizations find it helpful to do this on a monthly basis so that the plan stays current and reflects the needs an organization has today, and not just the data, software, etc., it had six months ago.

 

Understanding the Configuration of your AccessData System

Understanding the configuration of your current AccessData eDiscovery or Summation Pro environment is critical to the successful recovery of any environment. It is important to have a solid understanding of what hardware resources are involved in your environment and where the various AccessData software components exist on that hardware.

The list below outlines the various components that may exist in your AccessData eDiscovery or Summation Pro environment. Please note that this list is comprehensive and that not all of these components may exist in your environment.

  • AccessData MAP – The AccessData MAP Web Suite provides the interface through which users access the AccessData eDiscovery and Summation Pro solutions.
  • Application Services
    • AccessData WCF Services – The Windows Communication Foundation Services (“WCF”) manage the flow of data between the various AccessData eDiscovery and Summation Pro components.
    • AccessData Processing Services – The Processing Services are responsible for the execution of certain user actions such as bulk coding, searching, and load file import ingestion.
    • AccessData Work Manager – The Work Manager governs the flow of work to the Processing Engines. In eDiscovery environments, the Work Manager component is also responsible for communication with Site Servers, as well as for the performance of collections from structured data sources such as Microsoft Exchange and Microsoft SharePoint.
  • AccessData Distributed Processing Manager – The Distributed Processing Manager controls the flow of processing activities performed by the Evidence Processing Engines in an environment.
  • AccessData Evidence Processing Engine – The Processing Engine performs data processing tasks such as the expansion of archives (e.g., .PST,.NSF, and .ZIP files), indexing, de-duplication analysis, file identification, secondary culling and filtering, and the creation of production and export sets.
  • AccessData Site Server – The Site Server component is specific to the AccessData eDiscovery solution and is generally responsible for managing communication with the Work Manger relating to collection from computer endpoints and network shares.
    • Root Site Server – The Root Site Server controls the overall flow of collection requests out from a Work Manager to Private, Protected, Public Site Servers, and collection endpoints as well as the flow of collected data back from Private, Protected, Public Site Servers, and collection endpoints to the Work Manager.
    • Private/Private-Protected Site Server – A Private Site Server manages collection activity initiated through the Work Manager and targeting specified endpoints within the local network.
    • Public Site Server – A Public Site Server manages collection activity initiated through the Work Manager and targeting specified endpoints outside the local network.
    • AccessData PostgreSQL – PostgreSQL is an open-source object-relational database management system. Each Site Server utilizes a PostgreSQL database to store information about active collections temporarily.
  • Microsoft SQL Database – The AccessData eDiscovery and Summation Pro solutions utilize a Microsoft SQL Server instance to maintain databases containing file metadata, user data, and workflow information.
  • Project Data/Evidence/Collection Storage – The AccessData eDiscovery and Summation Pro solutions can leverage many types of local or external storage, including network attached storage (NAS), storage area network (SAN), and direct-attached storage (DAS), to host evidence and other case-related data.

 

Developing a Backup Strategy

The least expensive and most sensible option when developing a disaster recovery plan for your AccessData eDiscovery or Summation Pro environment is to have your data backed up regularly. The specific details of each backup plan will vary, but all backup plans should consider the following variables:

  1. What are we backing up?
  2. Why are we backing it up?
  3. What method will be employed (e.g., disk, tape, cloud, etc.)?
  4. What connectivity and bandwidth is required to insure timely backup and restore capabilities?
  5. How long should you keep your backups?

 

SQL Data

The routine backup of SQL databases are a simple and effective way to protect against data loss or corruption. 

The selection of a database recovery model1 is the first decision that must be made when developing a SQL backup routine. The recovery models provided by Microsoft SQL Server are meant to address varying levels of resource availability and acceptable data loss.

AccessData recommends the use of the Full Recovery model with user databases, but supports the use of either the Full Recovery model or the Simple Recovery model.

The next decisions following the selection of a database recovery model involve the method and scheduling of the database backups. Microsoft SQL Server supports three primary database backup methods: Full, Differential, and Log:

  • A Full backup creates a complete record of a database. A Full backup record provides the ability to restore a database to a single point-in-time. Full backups can be large, as they contain a comprehensive record of a database.
  • A Differential backup creates a record of any modifications that have occurred within a database since the execution of the last full or differential backup. A Differential backup record, in combination with its associated full backup record, provides the ability to restore a database to a single point-in-time. Differential backups are generally smaller than Full backups and, when used in combination with Full backups, help to reduce the volume of data consumed by an organization’s backup process.
  • A Log backup creates a record of all transactions made in a database since the last Log backup. A Log backup record, in combination with its associated Full and Differential backup records, provides the ability to restore to any point following the time of the Full backup record to, contingent on the success of a tail log backup, the most recent transaction in the database. The number of transactions that have occurred since the most recent backup dictates the size of any distinct log backup.

The Full and Differential backup methods are available to both the Simple and Full recovery models. The Log backup method is unavailable under the Simple recovery model. The output of any backup method should be directed to a location that is not being used to store active SQL database files (e.g., MDF, NDF, or LDF files).

NOTE: LOG BACKUPS MUST BE TAKEN FOR ANY DATABASE USING THE FULL RECOVERY MODEL; THE FILE CONTAINING THE DATABASE’S TRANSACTION LOG WILL OTHERWISE CONTINUE TO GROW INDEFINITELY.

AccessData strongly recommends that, at minimum, full backups of both system and user databases are made regularly. Additional complexity and scheduling will be dictated by criteria such as acceptable work-loss exposure, the speed and volume of storage available for both the data files themselves and the backup records, and the maintenance’s impact on the overall performance of the application. The section below contains a pair of hypothetical SQL maintenance plans.

NOTE: THE MAINTENANCE TASKS OUTLINED BELOW ARE FOR DEMONSTRATIVE PURPOSES ONLY AND SHOULD NOT BE SOLELY RELIED UPON AS THEY MAY NOT BE APPROPRIATE FOR YOUR ENVIRONMENT.

 

Simple Recovery Model Maintenance Plan (SAMPLE)

Job #1: Full Backup (System Databases)
Description: Performs an integrity check and full backup on all system databases.
Schedule: Occurs every day at 12:00:00 AM.
Step 1. Check the integrity of the system databases.
Step 2. Perform a Full backup of the system databases.

Job #2: Full Backup (User Databases)
Description: Performs an index optimization, integrity check, and full backup on all user databases.
Schedule: Occurs every day at 12:00:00 AM.
Step 1. Defragment the indexes and update the statistics of the user databases.
Step 2. Check the integrity of the user databases.
Step 3. Perform a Full backup of the user databases.

Job #3: Differential Backup (User Databases)
Description: Performs a differential backup on all user databases.
Schedule: Occurs every day every 6 hours between 6:00:00 AM and 11:59:59 PM.
Step 1. Perform a Differential backup of the user databases.

Job #4: Cleanup
Description: Deletes all backup and job history records that are older than 30 days.
Schedule: Occurs every week on Sunday at 12:00:00 AM.
Step 1. Execute sp_delete_backuphistory.
Step 2. Execute sp_purge_jobhistory.

 

Full Recovery Model Maintenance Plan (SAMPLE)

Job #1: Full Backup (System Databases)
Description: Performs an integrity check and full backup on all system databases.
Schedule: Occurs every day at 1:00:00 AM.
Step 1. Check the integrity of the system databases.
Step 2. Perform a Full backup of the system databases.

Job #2: Full Backup (User Databases)
Description: Performs an index optimization, integrity check, and full backup on all user databases.
Schedule: Occurs every week on Saturday at 1:00:00 AM.
Step 1. Defragment the indexes and update the statistics of the user databases.
Step 2. Check the integrity of the user databases.
Step 3. Perform a Full backup of the user databases.

Job #3: Differential Backup (User Databases)
Description: Performs a differential backup on all user databases.
Schedule: Occurs weekly on Monday, Tuesday, Wednesday, Thursday, Friday, and Sunday at 1:00:00 AM.
Step 1. Perform a Differential backup of the user databases.

Job #4: Transaction Log Backup (User Databases)
Description: Performs a transaction log backup on all user databases.
Schedule: Occurs every day every 4 hours between 12:00:00 AM and 11:59:59 PM.
Step 1. Perform a Log backup of the user databases.

Job #5: Cleanup
Description: Deletes all backup and job history records that are older than 30 days.
Schedule: Occurs every week on Sunday at 12:00:00 AM.
Step 3. Execute sp_delete_backuphistory.
Step 4. Execute sp_purge_jobhistory.

 

Project-Specific Data

A frequently overlooked, yet critical aspect of any recovery plan focused on the AccessData eDiscovery or Summation Pro solutions is the backup of the evidence and generated case data associated with the platform. Such data locations include the following:

  • Evidence Data – Evidence paths are generally visible in a project’s Evidence tab. AccessData eDiscovery and Summation Pro point back at any evidence that they ingest. Therefore, it is important that you know the location of all of your evidence. Each case can have evidence loaded from a different path; do not assume that all evidence data is located in the same directory.
  • Project Folder – Project folder paths are visible on each project’s Information tab (unless disabled by an Administrator). These folders contain files generated by the AccessData eDiscovery or Summation Pro platforms.
  • Job Data – Job data folder paths are visible on each project’s Information tab (unless disabled by an Administrator). These folders contain files collected by the AccessData eDiscovery platform.
  • Responsive File Path – Responsive file paths are visible in a project’s Jobs tab. The responsive data path contains processed evidence from collections, the collected items will be stored in a Responsive File Path. Be aware that, depending on your specific configuration, this path may be different from the evidence data path or project folder data path.
  • LawDrop – The LawDrop root path can be identified by looking at the Project Defaults section of the System Configuration tab in the Management section of the software. LawDrop may contain evidence or exported data.
  • Exported Data – Data exported from the AccessData eDiscovery or Summation Pro solution is not strictly necessary for the proper operation or recovery of an environment, but the locations of any such data may be identified and backed up, if desired.

 

Site Servers

AccessData eDiscovery environments will include one or more Site Servers. It is important to both back up the certificates used by the Site Servers and to document the configuration of each individual Site Server. The certificates and configuration information will be necessary to recover each Site Server effectively. 

Please follow these steps to document each Site Server:

  1. Open the Site Server Configuration program.
  2. Under “Secure Communications”, take note of the path for the public and private certificates.
  3. Open Windows Explorer and browse to the location of each certificate.
  4. Copy each certificate to a safe location outside of the eDiscovery environment.
  5. Document the contents of the following fields:
    1. Friendly Name
    2. Parent Instance
    3. Child Instance(s)
    4. Managed Subnet Address(es)

 

Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk