Application Integration
Showing results for 
Search instead for 
Did you mean: 

How to Migrate SMB data from a non-Microsoft SMB Server


How to Migrate SMB data from a non-Microsoft SMB Server

As you may know, Nimble Storage are SAN based storage only, and we never offered a SMB based protocol directly on our devices. This is partly because there are no 3rd party SMB implementations that have 100% compatibility with the Microsoft SMB feature set. It was far better (IMHO) to offer our storage behind a well designed and constructed SMB Cluster like that offered via a HPE StorEasy Cluster (Based on Windows Storage Server 2016 or 2019).

In this way, we never have to have the difficult conversation with a customer of why our SMB implementation differs from the SMB standard.

Microsoft not only has a number of valuable built-in features for SMB clusters, but also has a number of best-in-breed additional tools that can be used to manage and monitor these SMB shares such as Storage Migrator, or File Service Resource Manager (FSRM) to control auditing, automation, classification, screening and quotas.

The process below assumes that the Source SMB share in on a 3rd Party Implementation, while the Target SMB Share exists on a Windows SMB Share hosted either on a Standalone Windows Server or a Windows Failover Cluster. It is also assumed that the storage behind the Windows Server is Nimble.

Step 1

Identify the File Share on the Source Device, and identify both Size, Share Name, and Share Permissions. You will need to gather which groups and users are allowed access to this share.

You are going to want to replicate a Nimble Volume of the same size, and expose it the Windows SMB Server, and expose it via the same share name. Ensure that the same groups and users are allowed access to the share.

Step 2

You are going to want to take a Snapshot of the Share on the Source Device and expose that as a new share to the network. Make this share hidden since you don’t want it advertised to the rest of your infrastructure and have people get confused and connect. This new share will be “SnapShareName1$”.

You should now be able to connect to the source via \\Source\SnapSharename1$.

You should now be able to connect to the destination via \\Destination\Sharename1.

Step 3

Use the following RoboCopy command to create the initial copy;

Note that the Source array is still being used, and this can be done before the cutover window

RoboCopy \\Source\SnapSharename1$\ \\Destination\Sharename1 /S /E /MT:128 /MIR /FFT /copy:DTSO /R:9 /W:30 /log: C:\temp\CopyLog.Log

The options here are;

/S = Copy all Subdirectories

/E = Include empty directories

/MT:128 = use max number (128) threads for the copy.

/MIR = Update with new and changed files, remove any files from destination that don’t exist on source.

/FFT = Uses more relaxed timestamping compare since Linux and Windows timestamps may differ slightly.

/copy:DTSO = Copy the Data, Time, Security, and Owner metadata along with each file.

/log:C:\temp\CopyLog.Log = The Log file that will alert you to problems accessing files, or files that were skipped.

Wait a LONG time. This initial copy process may take hours or even days if the size or number of files is very large.

Step 4

This initial copy may complete a day after it was started. You can now remove the \\Source\SnapShareName1 share from the source device, and then remove that no longer needed snapshot.

From this point go back to Step 2, and repeat steps 2 and 3. Each iteration of Steps 2 and 3 will decrease the time required to complete the copy. I.e. The first time step 2 and 3 may take 12 hours, and the second time step 2 and 3 may only take 2 hours. If you repeat step 2 and 3 again you may find that the copy process only takes 30 minutes.

Once the timeframe has decreased to an acceptable outage timeframe for the cutover to occur. You are ready to start step 5

Step 5

Disable user access to \\Source\ShareName1 to ensure no additional changes to the file system can occur. Once this is done, you can take a final Snapshot of \\Source\Sharename1 and name it “SnapShareName1”. This step is the only step in the required outage window to complete the cutover.

Expose \\Souce\SnapShareName1 to the host running the final RoboCopy operation and use the following command.

RoboCopy \\Source\SnapSharename1$\ \\Destination\Sharename1 /S /E /MT:128 /MIR /FFT /copy:DTSO /R:9 /W:30 /log: C:\temp\CopyLog.Log

Step 6

Once this copy process completes, expose \\Destination\ShareName1 to end users.


This process is the simplest process to accomplish these goals; I will follow this process up with an additional part 2 which covers the more advanced option when you want to move not just the file system, but also all of the snapshots to that file system in addition to that file system.

I will also follow this up with 3rd part that covers how to migrate a Windows Based File Server from either Windows Server 2003, 2008, 2008r2, 2012, or 2012r2. This part 3 will rely heavily on The Windows Admin Center as well as the Windows Storage Migrator feature.

Chris Lionetti