cancel
Showing results for 
Search instead for 
Did you mean: 

Vault store design and cab files

paulo7
Level 4

Dear Experts!

Our customer is planning to introduce EV 12 with FSA archiving.
He has 5 file servers and has approx 20 billion files.
We can implement one EV server with an SQL database which is reside on the same 
host.Everything is virtual in that envionment.Veeam is the backup
sw and we use the trigger file.Customer preference: file retrieval should be
fast, backup of the EV server is the second thing.

We are planning the Storage layout for the EV server.
Our initial plan is:
1. One Vault store group
2. 5 Vault store, which is sharing level: share within a vault store

For example:
- Server01 Store1
- Server02 Store2 ... etc
3. Collections are not used on the VS
4. All data on the Ev server ntfs disk which has a big partition. (E: )
5. The ntfs dedup or compression not using

Questions:
1. What do you think, it is a good plan? What do you suggest? Please share your ideas.

2. Collection (CAB files) should we use or not?

3. How can we improve the overall perfomance?

BR:
Pal Szabo

2 ACCEPTED SOLUTIONS

Accepted Solutions

GertjanA
Level 6
Partner    VIP    Accredited Certified

Hello Pal,

I am not an FSA expert, but here are my thoughts on your ideas.

First, I strongly recommend to install SQL on a seperate server. It is best practice to do this. You can have EV and SQL on 1 box, but this is only when running a test-environment, or a really small environment.

Second, I recommend to not use a disk-letters, but use mountpoints, or a SAN location which can grow. (I assume you know mountpoints, in short, it is an empty folder in which you mount a disk. this allows easy extention of storage needed) You'll be surprised how quick the disk will fill, and keep in mind the growth. A Veritas partner should be able to get you a calculation of what is needed.

Third, if the data from those file servers can be shared, I suggest to use 'share within group', to get the best possible sharing EV can do.

Fourth, using CAB files has its pro and con. Pro is that backup will be faster, (large files backup faster then many small ones), con is that retrieval requires the cabfile to be extracted first. You might need to test this out for a small subset of files being archived. I personally would not use cabfiles, but that depends on the backup window/performance needed.

Fifth, work with a partner who has an understanding of FSA. It is more specific than mailbox/journal archiving, and a good partner might have long running experience with FSA, and can advise best.

On the Veritas site you should be able to locate a partner in your region, or ask your Veritas SE to assist.

Regards. Gertjan

View solution in original post

GertjanA
Level 6
Partner    VIP    Accredited Certified

Hello Paulo,

1. Why do we need a separate SQL server? It makes the backup and disaster process more complicated. We have enough CPU and Mem in the virt environment.

True, but not only will EV indexes and Vault Stores grow, also your SQL database will grow. Although you have sufficient CPU/RAM as you say, I NEVER put EV and SQL on the same box. (meaning on same Windows server. Having multiple servers on 1 VM host is fine) Think only applying an SP to your SQL, or upgrading EV. Having them on seperate servers will ease that. It is up to you to define your HA situation, but having an SQL cluster with shared storage is (in an environment which needs to be HA) the best option. EV 12.4 can even use the SQL Always-On, so that makes life a lot easier imho. But, it is up to you. Do check with support if they confirm the same. If you do SQL and EV on one box, make sure to define how much SQL can use, otherwise it takes as much as it can.

2. Mount points: It is great idea. What do you suggest   which area need a separate mount point?

I suggest to have mountpoints for EV Indexes and for EV Vault Store Partitions. I use 1TB disks for Index locations, and we use a SAN (Isilon) for Storage. You should (in general) be able to add new disks easily, or extend them easily. Having multiple VSP disks (and thus multiple VSP's) will also allow easier backup. If a VSP gets full (leave at least 10% free space), and new VSP disk, define new VSP, and open it. The old one gets closed. If you do not expire data, that means you need to backup the closed one less frequent :-). For indexes, make sure the storage is fast (1500 to 3000 IOPS, see Performance Guides), especially if you do Discovery searches.

If you insist on having SQL on the same box, seperate disk for databases only, seperate disk for database logfiles, and seperate disks for tempdb's (your DBA should know).

And obviously, seperate disk for Pagefile.

Additional:

Make sure your antivirus exclusions are correct! And make sue you sue DNS Aliasses for the EVSiteName, the EVserver, the SQL server, and (if you are going to use SAN storage, for the SAN box). That will make DR a LOT easier.

I think: index, sql data, vault store 

See above.

Regards. Gertjan

View solution in original post

3 REPLIES 3

GertjanA
Level 6
Partner    VIP    Accredited Certified

Hello Pal,

I am not an FSA expert, but here are my thoughts on your ideas.

First, I strongly recommend to install SQL on a seperate server. It is best practice to do this. You can have EV and SQL on 1 box, but this is only when running a test-environment, or a really small environment.

Second, I recommend to not use a disk-letters, but use mountpoints, or a SAN location which can grow. (I assume you know mountpoints, in short, it is an empty folder in which you mount a disk. this allows easy extention of storage needed) You'll be surprised how quick the disk will fill, and keep in mind the growth. A Veritas partner should be able to get you a calculation of what is needed.

Third, if the data from those file servers can be shared, I suggest to use 'share within group', to get the best possible sharing EV can do.

Fourth, using CAB files has its pro and con. Pro is that backup will be faster, (large files backup faster then many small ones), con is that retrieval requires the cabfile to be extracted first. You might need to test this out for a small subset of files being archived. I personally would not use cabfiles, but that depends on the backup window/performance needed.

Fifth, work with a partner who has an understanding of FSA. It is more specific than mailbox/journal archiving, and a good partner might have long running experience with FSA, and can advise best.

On the Veritas site you should be able to locate a partner in your region, or ask your Veritas SE to assist.

Regards. Gertjan

View solution in original post

Hi Gertjan! 

Thanks  for the suggestions.

1. Why do we need a separate SQL server? It makes the backup and disaster process more complicated. We have enough CPU and Mem in the virt environment.

2. Mount points: It is great idea. What do you suggest   which area need a separate mount point?

I think: index, sql data, vault store 

Currently we have: Os disk (C:) , app_bin (D:), (E: SQL, index) (G: Vault store) 

 

GertjanA
Level 6
Partner    VIP    Accredited Certified

Hello Paulo,

1. Why do we need a separate SQL server? It makes the backup and disaster process more complicated. We have enough CPU and Mem in the virt environment.

True, but not only will EV indexes and Vault Stores grow, also your SQL database will grow. Although you have sufficient CPU/RAM as you say, I NEVER put EV and SQL on the same box. (meaning on same Windows server. Having multiple servers on 1 VM host is fine) Think only applying an SP to your SQL, or upgrading EV. Having them on seperate servers will ease that. It is up to you to define your HA situation, but having an SQL cluster with shared storage is (in an environment which needs to be HA) the best option. EV 12.4 can even use the SQL Always-On, so that makes life a lot easier imho. But, it is up to you. Do check with support if they confirm the same. If you do SQL and EV on one box, make sure to define how much SQL can use, otherwise it takes as much as it can.

2. Mount points: It is great idea. What do you suggest   which area need a separate mount point?

I suggest to have mountpoints for EV Indexes and for EV Vault Store Partitions. I use 1TB disks for Index locations, and we use a SAN (Isilon) for Storage. You should (in general) be able to add new disks easily, or extend them easily. Having multiple VSP disks (and thus multiple VSP's) will also allow easier backup. If a VSP gets full (leave at least 10% free space), and new VSP disk, define new VSP, and open it. The old one gets closed. If you do not expire data, that means you need to backup the closed one less frequent :-). For indexes, make sure the storage is fast (1500 to 3000 IOPS, see Performance Guides), especially if you do Discovery searches.

If you insist on having SQL on the same box, seperate disk for databases only, seperate disk for database logfiles, and seperate disks for tempdb's (your DBA should know).

And obviously, seperate disk for Pagefile.

Additional:

Make sure your antivirus exclusions are correct! And make sue you sue DNS Aliasses for the EVSiteName, the EVserver, the SQL server, and (if you are going to use SAN storage, for the SAN box). That will make DR a LOT easier.

I think: index, sql data, vault store 

See above.

Regards. Gertjan

View solution in original post