Whitepaper: EMC SAN Copy

Source: eGroup EMC Data Migration to VNX

EMC Data Migration to VNX –

// //

EMC Data Migration to VNX

As a result of the huge success of EMC’s VNX platform, the need for data migrations has grown, especially recently, to get customer’s data safely and easily moved over from their previous storage platform to their shiny new VNX.  Here are some ideas on migration strategies that hopefully help you in the planning or execution of data migrations! Keep in mind that almost every one of our customers are heavily virtualized, the vast majority of which run VMware vSphere– so it is in that context that the following “strategies” are presented.

The “strategies” listed below are NOT exclusive of one another– in fact, we commonly use a combination of all 3 to provide a “total solution”. And there are some other strategies and techniques used to aid in the migration of data that aren’t covered that work just fine.

“Strategy” 1

First and foremost, the BEST and EASIEST data migration of all can be done without any downtime, and with zero risk. This is accomplished by using Storage vMotion (svMotion), and means you are migrating over some of your virtual environment to the VNX. It requires that your data exists in a VMDK (meaning it’s a virtual machine and that drive is NOT an RDM), and that you’ve created and presented storage from the VNX to the vSphere environment. This method works like a charm!

“Strategy” 2

For environments that have a lot of physical servers (which hurts my feelings by the way– virtualize ‘em already!), or use lots of RDMs, there are some alternative options, most common of which uses EMC’s SAN Copy software. SAN Copy is included on the VNX platform for FREE, and for customers migrating from an EMC CLARiiON, EMC will provide this to you at no charge (again, read FREE) for your CLARiiON, (to be used for migrating to the VNX).

SAN Copy is installed as a “software enabler” on the desired arrays and allows the copying of data between arrays, in either a “push” or “pull” method. The method, push or pull, is determined by the array initiating the copy job (if it’s the “old” array, it’s a push–).

This can also take place between an EMC array and a “qualified non-EMC storage array”, but only in a “pull” fashion.

Using a “push” method (where you’re configuring and starting the SAN Copy job from the array you’re migrating FROM)  allows you to do Incremental SAN Copy jobs. This let’s you do a single full copy, and from then on only copy over the changed/delta data.

It’s important to note that this is “host independent”– meaning the host servers are not involved. This DOES require downtime to cutover, unlike strategy 1 described above.

Note: This doesn’t get configured the same way it did on the CLARiiON platform when going “CX to CX”. I’ll work on getting a video together showing the difference, but for now just know that when you create the SAN Copy session, the “remote LUN” isn’t something you select (today)– you must enter the unique ID of the LUN instead (see screenshot). Kind of a pain, but not unbearable.

“Strategy” 3

When migrating over your file server(s) or file server(s) data, consider skipping the “copy to a LUN” or svMotion methods, and move straight to using the CIFS server capabilities of the VNX. This is a larger conversation, but in brief, the VNX can operate as a Windows file server, where you give it some disk space to use, a name and IP address, and join it to the domain. It will appear as a regular computer in Active Directory (you can create multiples if you’d like as well– for security or isolation between departments, companies, domains etc.), and you can even include it in your DFS environment.

The BENEFITS of this are numerous, and include:

  • FILE DE-DUPLICATION! This is one of the BEST reasons to move your file server data to the VNX. Huge storage savings, which ultimately means “YOU SAVE MONEY”! (see screenshot below– 43% of all files were deduplicated!)
  • Highly available, highly resilient file server. Since the platform itself maintains 5 9’s of availability, your file server doesn’t have a single point of failure, which it would if it was a stand-alone Windows server (think about what happens if the OS blue screens for example).
  • High performance hardware designed to serve files!
  • Thin Provisioning– only commit what’s actually being used, again, saving space/money.


Data Migration: Tools and Methodologies//

// // // // <![CDATA[
function bb2_addLoadEvent(func) {
var oldonload = window.onload;
if (typeof window.onload != 'function') {
window.onload = func;
} else {
window.onload = function() {

bb2_addLoadEvent(function() {
for ( i=0; i // // //

By Prashant Shah, , ,

A blog post about data migration in 2014?!? Isn’t everything virtualized and Storage vMotion the way to go? And these days, if the topic doesn’t have the word “cloud” in it, is it even worth talking about?


It is true that VMware Storage vMotion has greatly changed the data migration landscape. We simply stand up the new array and present the LUNs to the ESX cluster and the VMware dudes take over from there. What used to require a lot of planning and create a lot of anxiety has been reduced to a few clicks and no downtime! Data migration projects I’ve been involved in have declined significantly over the years, and I’m not complaining—because doing data migrations is not how I like to spend my nights and weekends.

However, there are still plenty of clients with physical hosts, and they need to figure out how to get the data from an older array to the new one (VNX/VMAX). Many of these clients are implementing Unified VNX models and we also need to have a data migration strategy for NAS (moving from another NAS platform or a physical file server to a VNX/Isilon). At any given time I’m involved with a couple of migration projects. It’s definitely not as crazy as it used to be, but plenty of migration work is still done regularly. Many of our clients have legacy systems and applications that cannot be virtualized. And even if they can be, they are critical enough that the whole “if it ain’t broke, don’t fix it” thing comes into play. If it weren’t for tech refreshes and the need for better performance, it’s doubtful they’d even consider doing a data migration, let alone pursue virtualization.

What methods can we use to migrate? Host based? Array based? Combination of both? We have quite a few proven and solid tools to choose from. Obviously, the tools discussed here are not the only ones, but these are the most commonly used. Let’s look at them in more detail:

Host Based

Open Migrator

This is a free program that works with variety of operating systems. It has been out for quite some time, meaning it is a proven tool with much good documentation, but is also a little outdated. The source can be a non-EMC array, but target must be EMC. You can migrate to a target volume that is larger. Byte copy means it takes less time than block copy tools. A major drawback to this tool is it requires two to three reboots during the whole process.

PowerPath Migration Enabler (PPME)

The go-to tool for migrations these days is PPME. If you own a licensed version of PowerPath, you can get a PPME host copy license at no charge. It supports a variety of operating systems and is completely online. No downtime required in almost all use cases. With the recent release of 5.7 version, it makes MSCS cluster migrations easier as well (no need to shut down the second node).

UNIX logical volume manager

Until recently, most UNIX flavors were best migrated with an array-based tool. However, I have, thankfully, not been involved with the UNIX side of things in my last few migrations. Client UNIX admins have been using host-based volume manager mirroring tools to simply copy over the existing array volume groups to the new array volume groups. In theory, very similar to the PPME approach.

Array Based

SAN Copy

SAN Copy is one of the most familiar tools to migrate from any source to EMC target. It is also supported for migrations within EMC platforms. Since there is no host involved, set up is simple and copy process over FC is very fast. The only drawback is that it has to be kept in-sync by doing incremental sync manually.


When migrating from a CLARiiON to a VNX or between VNXs, MV/s is the tool of choice for array-based migrations. Simply zone the two arrays together, establish the source-target pairs, and let it go. Once it finishes the initial sync, it will continue to replicate synchronously. The actual downtime when cutting over is brief. It’s a block-by-block copy, so the target is absolutely identical to the source and it works across all OSs very well.


Although RecoverPoint is primarily a replication product, many clients have successfully used it to migrate LUNs between data centers. Recently we had a client that was physically moving servers from one data center to another. Since the RecoverPoint environment was already there, we leveraged it to copy all the LUNs to the array at the new data center location and then moved the servers to the new data center. Similarly, it can be used during array refreshes to migrate from old to new.


Like RecoverPoint, VPLEX is also a multi-purpose solution. It can be used to migrate during tech refreshes and we have successfully utilized it for numerous projects. VPLEX encapsulates the new array and then mirrors data from the old array LUNs to the new array LUNs. Once the copy is done, you simply dis-associate LUNs on the old array and you’re finished!

NAS Migrations

VNX IP Replicator

When moving from a Celerra or VNX File to a new VNX File, this is the way to go. It’s easy to set up and fully supported by EMC. There is no need to run manual incremental sync process as it continually replicates changes to the target file systems. Also, since it’s file-system based and not tied to a protocol, CIFS and NFS both are migrated with this same tool. The actual downtime is relatively brief when cutting over. As long as you prepare the source properly (and there are some special considerations), there is no need to recreate the CIFS servers/shares/quotas/etc. once you migrate. Everything stays intact.


Both of these are free tools and work well for CIFS migrations. Robocopy is a Microsoft utility and EMCopy is EMC developed. We almost always use EMCopy. Since it’s an EMC-supported tool, if you run into issues you can open a ticket and get professional help. It is also very reliable and fast, with multi-threaded operation. You can adjust the number of threads to take full advantage of available resources. Both of them are highly customizable, with many switches to preserve share permissions, time stamps, propagate deletions, etc.


For NFS exports, we use Rsync to copy files from the current NAS to the new file system. Like the CIFS tools mentioned above, there are many switches to customize the options to suit your specific environment.


When architecting a data migration project, we do plenty of planning and analyzing to make sure the right tool is chosen and that the source and target environments are at supported levels. There is always some remediation required on the hosts or switches or even the arrays to match the latest support matrix. Even then there is risk involved—and a rollback plan, in case we can’t get the work completed in the given downtime period.

At AHEAD we have experts across all the tools mentioned here and more. Please contact us at info@thinkahead.com for further information.


A blog dedicated to Citrix technology

There's More to the Story: a blog about LIFE, chronic illness, and Mental Health

I’m the loud and relentless "patient" voice and advocate they warned you about. I happen to have type 1 diabetes, ADHD, anxiety, OCD, PCOS, endometriosis, thyroid issues, asthma, allergies, lactose intolerance (and more), but there’s more to story.


Learn Troubleshoot and Manage Windows

Dirk & Brad's Windows Blog

Microsoft Platform How To's, Best Practices, and other Shenanigans from Highly-qualified Windows Dorks.

Ingmar Verheij

About Citrix, Remote Desktop, Performance, Workspace, Monitoring and more...

Virtual to the Core

Virtualization blog, the Italian way.

CloudPundit: Massive-Scale Computing

the business of Internet infrastructure, cloud computing, and data centers


Every Cloud Has a Tin Lining.


See no physical, hear no physical, speak no physical - speakvirtual.com

Ask the Architect

My workspace journey


The weblog of an IT pro specializing in virtualization, storage, and servers


a place under control of his big head

this is... The Neighborhood

the Story within the Story

Yellow Bricks

by Duncan Epping


Enterprise Storage Engineer

My Virtual Vision

My thoughts on application delivery