ONTAP Discussions

How to migrate 32bit volume with qtree and non qtree data to 64 bit volume

JLundfelt
9,405 Views

Hi

 

I have a 11TB CIFS based NTFS volume with 4 qtree's on 7.3.7 controller, that I need to migrate to another controller, the problem I am having is that

 

if I use QSM-

 

Invoke-NaSnapmirrorInitialize -Source 172.16.1.1:/vol/Groups/- -Destination irv-gdc-san1a:/vol/Groups/qtree

 

I only get the base contents of the volume, and not the other qtree's that are co-mingled with folders in the base of the cifs share local path (/vol/Groups)

 

if I use VSM-

 

The volume would be replicated with all data / qtree's. but would remain 32bit.

 

Part of the issue I have is that this is over 10TB / 10 million files. I already have the QSM relationship for the base contents of the volume. If I setup additional QSM's, they would be adjacent to the base contents, and a single cifs share could not access. As part of the cutover plan, I am going to be aliasing the IP address since we have both Windows and Unix clients accessing this data from god knows where. Anyone have any suggestions? I am trying to make this a single cutover event, where the outage is less than an hour, and from previous expireance, if I move the contents from the base QSM  (irv-gdc-san1a:/vol/Groups/qtree --> irv-gdc-san1a:/vol/Groups) it could take hours, and I wouldn't be able to maintain permissions unless I used robocopy with the /MIR and /SEC switches.

 

Any suggestions? TIA!

-jon

1 ACCEPTED SOLUTION

dirk_ecker
8,831 Views

The VSM destination vol won't change until you break the snapmirror relationship.

 

For testing purposes you can do the following:

 

- create a new vol on the source 7.3.7 controller

- set up a VSM relationship to the FAS3140

- running "vol status" should show 32-bit now

- break the relationship

- wait a few minutes, then run "vol status" once again

 

 

View solution in original post

23 REPLIES 23
Public