migrate existing file server - strategy

[SUSAN8888]

Hi,

I've a file server with multiple shares around 20 of them. Can i just create 1 large CIFS shares in Netapp, and then using robocopy to copy all shares with permission to it?

[txskibum2000]

We created one large volume and created multiple shares off that volume.  Best way to benefit from deduplication.  Our challenge is to implement some sort of data retention and deletion policy via NetApp or 3rd party application...

[thomas_glodde]

@susan: Yes, you can, like txs said try to go for a big volume to have the most profit from dedupe.

@txs: NetApp has no native ILM implementation in ontap itself, you can plug 3rd party tools into it tho, eg if i recall correctly commvault solutions or symantec enterprise vault.

[SUSAN8888]

thanks guys.

so i would just create a large qtree, attached it to a single shares (integrated with my AD) then connect it via windows explorer and create more shares (or robocopy with permission). does it work this way?

[paulstringfellow]

Hi Susan,

You just need to bear in mind that robocopy does not bring across share data…so the shares will have to be manually created and share permissions will need manually creating also.

Robocopy will bring across NTFS permissions for both files and folders and is a great way to do it…I tend to do a bulk copy and then spend a couple of nights just doing incrementals until I’m ready to swap it over.

In terms of volume creation…one volume holding multiple shares (doesn’t have to be qtree based) you can create multiple shares on a single volume using system manager (NetApp) or windows server manager and manager the filer as though it was a server. This will give best dedupe results, just bear in mind some of the volume size limits for dedupe and you should be good to go!

[SUSAN8888]

thanks paul,

i have the following more questions:

1) i only know how to create a qtree attached to a CIFS shares. how do make a volume attached to a share?

2) if i were to pre create the shares from windows explorer, then robocopy with the permission should be ok right?

3) also it would be snapmirror to another filer in DR, i would assume the shares and the NTFS permission will get replicated right?

sorry for the lame questions but i'm really new to all this.

[paulstringfellow]

As they say no question is a lame question…

Done a bit of share migration in my time and Robocopy is pretty good…and tends to be my tool of choice…only becomes a problem if you have 1000’s of shares to move…recreating them isn’t an option…

So as for your questions…here goes;

1. Create the volume and then create shares within the volume, if you are using filer view, that won’t work…so you need something else to allow you to do it…is you have NetApp system manager (the Windows admin tool for FAS 2000 and 3000 range boxes) this will allow you to create a CIFS share on a volume either sharing out an existing one or create a new folder and share that, this will allow you to create folders ready to robocopy data into

2. See no reason that won’t work…in the end that’s “windows stuff” and not really NetApp related, the filer won’t break it!

3. No I don’t think that is right unfortunately…the snapmirror is a volume level replication (although not sure if you use qtree as to whether that may let it work) the thing with vol snapmirror is that you are mirroring data from filer 1 to filer 2…in the event of needing to share data on filer 2 they are no longer the same shares… you have moved from
filer1\sharename<file:///
filer1\sharename> to
filer2\sharename<file:///
filer2\sharename> also the mirror copies are read only, so you would have to make them live and reshare them…really to have that kind of share resilience you need to use DFS, which you can do…and have the filers as DFS end points (they can’t be a DFS root) however it can’t use DFS-R to do replication, it must use SnapMirror but you can use DFS to present a name space that will auto move shares around in the way you may want

Hope that helps

[SUSAN8888]

Hi Paul,

thanks for the answer,

1) great, i've found the CLI, cifs shares –add Share1 /vol/vol1. also i will look into system manager.

3) my co wanted to do away with windows server hence DFS is not possible. My user does not require such resiliency during disaster, they do not mind pointing to diff share location i guess it should not be problem. and that when i do a snapmirror break it should make the DR copy writable. all i need to do is just create a snapmirror from the cifs vol. that's all right?

please correct me i'm wrong.

[paulstringfellow]

Hi Susan

You’re pretty much there…

System manager will certainly make your life easier…

And yep, if the customer is happy with that…what you can do of course, is precreate the shares on the DR box, as they will be as we said…
DR\sharename<file:///
DR\sharename> so will not be the same share…as they are SnapMirror volumes then they will be read only, so users would not be able to alter data in them… in terms of DR, I’d also take a look at protection manager (part of DFM/OnCommmand) this will allow you to set a policy for those shares, that in the event of a production failure, can automate the move to writable volumes at the DR end…well worth a look….

Sounds like you have it pretty nailed now though….good luck,

[artur_kusiak]

A good tool for cifs migration is SecureCopy. It works well with NetApp and it will migrate all the shares for you into the filer on a volume of your choice. It has beeter reporting tools than robocopy if you want to monitor the progress of your data migration.

Thanks

Artur