Migrating Data from Centera

Shortly after its introduction, EMC Centera became one of the most successful data archival devices ever, as it provided WORM functionality (Write-Once-Read-Many) at far superior performance levels than other technologies such as tape and optical, and regulatory agencies began accepting it as a valid storage medium for data retention.

However, many organizations that began using Centera to archive data never fully understood its complicated architecture, how data is written to and retrieved from the device, and most importantly, how to migrate data out of Centera once their device reaches End-of-Life or the end of its “reasonable service period”.

Challenges with Migrating off Centera

Writing data to Centera has long been considered a “black box” approach, because Centera stores data as objects with associated Content Descriptor Files (CDF), rather than storing data in a native file format using standard naming conventions such as DOC, XLS, PDF, etc.

As a result of this black box approach, files and directory structures are not directly viewable to a client workstation, and methods such as Windows copy-and-paste procedures, DOS xcopy commands, and file management utilities cannot be used to migrate data from Centera.

Centera Migration Software

Our purpose-built EMC Centera migration software was designed to accurately and efficiently copy data from a Centera system to a new target device, while preserving any retention rules that were applied to objects in a Centera storage pool.

For data that has met its retention period, our software provides a powerful set of inclusion and exclusion filters that will migrate only the subset of data that is selected, which in turn minimizes project duration and reduces storage capacity on the new storage device.

To maintain regulatory compliance for laws such as SEC 17a-4 and Sarbanes-Oxley, every step of the migration process is captured and logged, beginning with selecting the source data, and ending with post-migration verification of content on the target system, thereby documenting the chain-of-custody for each file.

Our Centera Migration process

The procedures and goals of every EMC Centera migration project vary depending on the volume of data, size of data objects, type of data (E-mail, scanned images, PACS images), applications that wrote to the Centera, and filtering and legal retention requirements, as well as other site-specific requirements.  Following is a summary of our process:

• Obtain specific hardware, application, data type, and compliance-related information as listed in our Centera Migration Survey

• Obtain and review Centera Health Reports to ensure there are no drives or nodes reported as off-line, and there are no other hardware errors or warnings present that may adversely affect the migration process

• Select primary point-of-contact (PPOC), technical point-of-contact (TPOC), and project manager (PM) from each organization and provide contact information to all parties

• Obtain user ID and logon credentials for remote access to the Centera via VPN connection

• Install Centera Migration Software on a designated “migration server”

• Perform a Centera inventory, a process that reads all C-Clip and object information and populates a database with the “inventory” of the data on the device

• Copy all of the C-Clips and objects from Centera to a temporary disk storage array, normally configured as local storage to the migration server

• Execute a series of scripts that utilize the metadata contained within the Content Descriptor Files (CDF), rename the associated objects back to their original file names, and write them to their original directory path as was defined in the CDF

• Perform a mass copy of the converted data to the new storage target, normally completed in small batches to better control the process

• Execute an MD-5 hash check to verify the contents of the data file on the new target device exactly matches that of the original object on Centera

• Update application databases and configuration files to instruct the applications of the new path to where the data is now located

• Generate a migration report detailing the number of objects migrated, number of objects NOT migrated due to filtering rules or file corruption, and other pertinent information required for maintaining chain-of-custody for legal and auditing purposes