Disaster Recovery

NOTE: The intent of this document is to assist in the design and implementation of a disaster recovery plan for an FTK Central. 


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


This document provides some best practice guidelines on how to approach data backup with respect to the Exterro FTK Central environment. Exterro 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. 

Exterro 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.

Exterro 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. Exterro strongly recommends having the appropriate people actually practice what they would do to help recover business function should a disaster occur.

Exterro 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 Exterro System

Understanding the configuration of your current Exterro FTK Central 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 Exterro software components exist on that hardware.


The list below outlines the various components that may exist in your Exterro FTK Central environment. Please note that this list is comprehensive and that not all of these components may exist in your environment.

  • Exterro Distributed Processing Manager – The Distributed Processing Manager controls the flow of processing activities performed by the Evidence Processing Engines in an environment.
  • Exterro 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.
  • Exterro Site Server – The Site Server component is generally responsible for managing communication with the Processing 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.
    • 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 Exterro solutions utilize a Microsoft SQL Server instance to maintain databases containing file metadata, user data, and workflow information.
  • Project Data/Evidence/Collection Storage – The Exterro 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 Exterro FTK Central 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.

Exterro 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.

Exterro 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 Exterro 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. Exterro FTK Central points 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 Exterro FTK Central platform.
  • 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 Exterro FTK Central 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.
  • Exported Data – Data exported from the Exterro FTK Central 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

Exterro FTK Central environments could 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)