Feature

Migrate data without mistakes

Ezine

This article can also be found in the Premium Editorial Download "Storage magazine: The top email archiving strategies for storage managers."

Download it now to read this article plus other related content.

Moving data from one array to another, or from one tier of storage to another, is a tedious process that's slowly becoming more automated.


With storage capacity growing at 50% annually, an unending cycle of technology refreshes, server and storage consolidation, and data classification is driving the need to move data from one tier of storage to another or from one array to another. Data migration has become a way of life for storage administrators.

In a perfect world, you would use automated tools to migrate data. Yet data migration is too often done manually: an administrator takes the system offline, backs it up to tape, installs the new array and recovers the data to its new location. A complicated data migration may include 50 or more steps, and take a night or even a weekend to perform. For businesses operating 24 hours a day, 365 days a year, this is simply too long to have a system down.

"Downtime is costly; it costs me $30,000 an hour. That's not really that large an amount, but not having to take the NetApp filer out of service and plan downtime in off hours is beneficial," says Stephen R. O'Neill, VP of technology at Oversee Domain Services, a division of Oversee.net, in Los Angeles. "My engineers don't have to be up in the middle of the night and do all the things you do to mitigate the impact of maintenance."

You would think that migrating

    Requires Free Membership to View

    Login

data, which is such a routine and tedious operation, would be easier.

According to a survey conducted by the New York City-based research firm TheInfoPro Inc., problems arising from migration include users suffering from extended or unexpected downtime, technical compatibility issues, data corruption, application performance issues, and missed data or data loss.

A migration checklist
Many migration projects suffer from poor planning, which results in excessive or unexpected downtime. Outlining the steps in any migration will assist in successful migrations.

PLAN
  • Identify the personnel involved in the migration--storage administrator, database administrator, application manager and security officer--and solicit their expectations and goals regarding the migration
  • Identify the applications, functions, host servers and storage impacted by the data migration
  • Discover the data that will be migrated
  • Determine when the migration will occur, how long it will take and how long the systems will be down (if necessary)
  • Back up the data on the device that the data will be migrated from
  • Record the configuration of both the source and target arrays involved in the migration
  • If you're using scripts to perform the migration, review them for reliability and accuracy
  • Record OS-level permissions, directory structure and share permissions
  • Verify LUNs and volumes on source and target devices
PRACTICE
  • Perform a fire drill of the migration
  • Review all changes to the system configuration
  • Review LUN and volume information for both the source and target
  • Test the rollback or fallback process
PROOF
  • Verify the results; check for data integrity and any possible corruption
  • Validate the results; test network access, file permissions, directory structure and applications
  • Review the project for issues to correct or improve for the next migration

This was first published in June 2008

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top