Migrating Veritas Enterprise Vault to Modernized Storage Platforms

Organizations will need to target an S3 platform that also supports the EV Streamer interface.

Gary Lieberman is the Founder and CEO of Interlock Technology.

Veritas Enterprise Vault (EV) is one of the most long-lived and ubiquitous data archiving solutions. Thousands of organizations have deployed EV as their centralized repository for email, files and social media. In fact, a 2017 Osterman Research White Paper found that the median amount of storage for email in Enterprise Vault was 35 gigabytes per user and that a median of 50 terabytes of storage were maintained in the Enterprise Vault environment across all respondents.

Consequently, when an organization needs to move its EV data, the scope of the data migration can be huge. Organizations may have EV installed on premise, but decide to move it to a different platform, or they may decide to move their data to the cloud.

Updating EV to a newer, more flexible storage environment is challenging.  Organizations want the migration to be smooth, painless and cost effective. They also want full accountability for each step of the migration process and proof that all their valuable data has been moved successfully before they close down the old storage locus and flip over to the new. Finally, they need the freedom to move their data from ANY source storage running under EV to ANY target storage.

Targeting Object/S3 Storage

Today, the most likely target for an EV migration is Object/S3 storage, for which EV requires storage vendors to integrate with their proprietary “Streamer” interface. Whether the migration is from NAS, CAS (Dell EMC Content Addressable Storage, used by Centera and Atmos) or Streamer/S3 sources, the organization will need to target an S3 platform that also supports the EV Streamer interface.

One of the most popular targets for an EV migration is Dell Elastic Cloud Storage (ECS), which can either be an on-site or Cloud-based deployment. To help facilitate EV migrations, Dell supports both the EV Streamer interface as well as the CAS protocol. Customers therefore have two options when migrating to ECS: remain on the CAS interface, or move to the more modern, S3-based interface.

Migrating to the CAS interface on ECS enables a rapid switchover to the new platform for net new data – from the application perspective it’s still writing to a Centera. However, the data copied via the CAS interface is only accessible via the CAS interface, and the migration tool – ECS Sync – copies the data from the source Centera slowly in the background, maintaining the Centera in place in the data center until the migration completes.

On the other hand, migration from Centera CAS to the ECS Streamer/S3 interface is much, much faster than a migration undertaken using the free ECS Sync tool to the ECS CAS interface. In addition, migrating to ECS Streamer/S3, enables all of the value of a “true” object storage platform.  Finally, for customers with regulatory requirements, the migration to the ECS Streamer/S3 interface can be supplemented with object-level chain-of-custody reporting for full data accountability throughout the migration process.

In addition to CAS source storage, both NAS and Streamer/S3 sources can be migrated to new S3 target storage supporting the Streamer/S3 interface.

A Three-Step Migration Process

There is a before, during and after stage to every EV migration.  Initially, the EV application reads from and writes to the source storage when archiving email and other data. However, in anticipation of the migration process, two new EV partitions need to be created on the target storage (CAS, NAS or Streamer-compatible S3).

A new partition (P1) is added to the target storage and accepts all new email data for archiving. The existing (legacy) EV partition on the source storage (P2) will now become read-only (closed). Although no new data is written, it is still readable and in use throughout the migration process.

The second step is to conduct a data assessment that catalogs the existing archived data and establishes a process to keep a tally of real-time incoming data.

The third step in the EV migration process is the bulk data copy using strong hashing. The client will allocate a separate storage area on the target storage to hold the migrated legacy data; this new storage area will become a partition (P3) in the EV vault store later, during cutover. Email archives are copied from the legacy EV partition on the source storage (P2) to this new partition (P3) on the target storage. During this process, the email objects from the source storage are copied to the new target storage and, if migrating from CAS to NAS or S3, are transformed into an equivalent, EV-specific file format when stored in the new storage area (P3).

Once the migration is complete, EV will remain in backup mode for several hours for verification, testing, and cutover. Changes are made to the EV configuration to remove references to the legacy partition (P2) and replace the references with those from the migrated partition (P3). All EV indexes are preserved, and the audit trail report is delivered.

The beauty of a Streamer-driven EV migration is that it is quick and has minimum impact on an organization’s production activities.  Once the legacy EV archive has been moved to its new platform – and that new platform should be whatever is best for the customer – the organization will continue to operate with EV as a key component of its data center strategy.

Opinions expressed in the article above do not necessarily reflect the opinions of Data Center Knowledge and Informa.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish