July 02, 2013

Integrating e-discovery process with traditional backup

Here in the United States, we have something of an alphabet soup of federal regulations that impact IT pros in various industries. These regulations include HIPAA, FISMA and SOX, and the list goes on and on. Although each of these sets of regulations is unique, most of them impose some sort of data retention and e-discovery requirement.

E-discovery, or the task of searching for specific data for legal purposes, is one of those tasks that sounds simple enough but, in practice, has proven to be quite complicated. One of the things that make e-discovery so tough is that data exists in a variety of forms. For example, an organization might have data stored on a file server, on an Exchange Server, in a SQL Server database and in a SharePoint document library. Of course, that's just the organization's current data. There is also data stored in the organization's backups and archives.

In the past, there was really no good way of searching across multiple data repositories. A backup vendor, for example, might provide a utility that allows administrators to search the backups, but the interface probably will not be able to search for data that has not yet been backed up. Likewise, search results might lack granularity. For instance, a search for the term Contoso might return file names including the word Contoso or documents created by a user named Contoso, but the results might not examine document contents or might not look at individual e-mail messages. Simply put, backup indexes are good for locating data that needs to be restored but, by and large, they are not intended as an e-discovery solution.

Both native and third-party, application-specific e-discovery products have existed for quite some time. Microsoft's Exchange Server 2013, for example, includes a native e-discovery tool that is capable of locating Exchange Server data and SharePoint data, but it does not provide the ability to search other data sources, including data that has been backed up. More recently, however, some vendors have begun integrating e-discovery and backup software products.

One particularly good example of such a product is Quest's Recovery Manager for Exchange. Recovery Manager for Exchange is specifically designed to provide Exchange Server related e-discovery capabilities (although it also supports Lotus Notes). It is not designed to examine non-messaging data. The thing that makes the product so interesting, however, is the fact that a search query can be simultaneously run against live data (an Exchange Server database), archive data (an archive database, an offline database, or a PST file) and data that has been backed up.

The software has built-in support for Windows Backup, Backup Exec, Veritas NetBackup and EMC Legato Networker. It can natively access and query backups made using these applications. Although this list of backup products is somewhat limited, the software can easily be configured to work with dozens of other backup applications. In these cases, Recovery Manager for Exchange works with the backup software to perform e-discovery, rather than bypassing the backup software and natively querying the backups.

Quest is not the only vendor whose products are designed to interact with backup applications. For example, Symantec offers an e-discovery product called Enterprise Vault Collector, which works with its archive platform. EMC offers an e-discovery product called Kazeon, and CommVault offers consulting focused on designing an e-discovery-friendly backup/storage architecture using Simpana. However, what makes Recovery Manager for Exchange unique is the number of backup types and backup applications that the product is designed to work with.

No comments:

Post a Comment