cancel
Showing results for 
Search instead for 
Did you mean: 

Migrate vault stores from LUNs to CIFS

RhoSysAdmin
Level 5

Our EV 9.0.4 server is running on a Windows 2003 server.  This year we migrated to NetApp.  I have three multi-partition vault store groups that reside on LUNs.  They've each rolled over to new partitions due to size restrictions on the LUNs being used.  Here's what I know based on similar discussions on this site:

1. I can/should migrate my vault stores to CIFS.

2. I should use the native dedupe and compression built in to EV instead of NetApp dedupe feature. 

3. I'm going to have to use robocopy, or a similar tool, to move the files from LUN to CIFS share.

4. I need to leave the indexes on LUNs.

So my questions are:

a. I found a very helpful video on moving vault stores, but the example showed a vault store with 1 partition.  Is the process the same for a vault store with multiple partitions?

b. Is there any reason to be concerned w/ the size of the CIFS share?  Is there a theoretical size a vault store shouldn't go above?

c. If I'm using EV for dedupe and compression, and not the NetApp, there's no reason not to migrate all vault store partitions to the same CIFS share, correct?  (unless I want to do different NetApp replication schedules based on FSA or MBX)

d. Is there a KB article that will tell me how to move/leave the indexes on LUNs while moving the vault stores to CIFS?

 

I realize this is a bunch of slightly disparate questions, but I'm hoping the first three are simple yes/no answers.

 

Any help is greatly appreciated!!.

1 ACCEPTED SOLUTION

Accepted Solutions

Rob_Wilcox1
Level 6
Partner

My Answer for a/

Yes it's pretty much the same procedure. You're updating the PartitionEntry table in EV, nice and steadily as you 'migrate' the data.

Working for cloudficient.com

View solution in original post

3 REPLIES 3

Rob_Wilcox1
Level 6
Partner

My Answer for a/

Yes it's pretty much the same procedure. You're updating the PartitionEntry table in EV, nice and steadily as you 'migrate' the data.

Working for cloudficient.com

Nate_D1
Level 6

B) I think is a logistics issue mostly. A friend that works in operations for a very large company and they roll their partitions at 500GB for ease of backup and portability of the archives. They tested increments 2TB and smaller and they found this worked best for them. Just a .02c

Rob_Wilcox1
Level 6
Partner
Is anything else needed on this thread? If not then perhaps mark one or more of the threads that were most helpful as the solution.
Working for cloudficient.com