SourceOne and Celerra/VNX using dedup and FLR

Hi everybody, some months ago I submit a similar thread, under

ECN > Support Forums > SourceOne and EmailXtender > Discussioni

about SourceOne with Celerra, but I didn't get any reply.

I tried again now, under EMC SourceOne User Community, because again I face a similar environment for a new installation and I have to use VNX storage.

I would like to use dedup and FLR for Volumes shares.

I wasn't able to find any best practice for setting Celerra/VNX with ES1

I've some questions and doubts about archive folder creation and retention consequences.

Since 6.6 ES1 now support directly more storage types and functionality.

Customer would like to enable a file system share on Celerra for ES1 Volumes with both deduplication and FLR on.

Configuring archive folder :

Storage Option tab

I choose Celerra as Storage type in order to use all Celerra functions.

Max Volume size : default 100Mb . Any best practise about it for Celerra ?

Montsh to retain. If I use FLR on Celerra Volume share how it's used by ES1 and what are the consequences ?

For ex. I archive today an old email of 3 years ago into an archive folder with 10 years retention,

It'll protect on Celerra for next 7 years (10-3) similar as expected with Centera?

If I change Month to retain it will be set only for next new volumes or it will modifiy retention of old volumes on Celerra ?

What happens if I decrise retention ?

What happens if I increse retention ?

If customer change mind about retention and wanted to delete old data on Celerra still in retention how they can do it ?

If I set 0 Month that generally should mean "no retention" what's the real behavior/consequence on Cellera/VNX with FLR enabled ?

Large content tab

In order to use dedup optimization I should set to store large content outside of containers.

What's the best compromise for Celerra ? Should I leave default value 1000 KB as threshold?

What about compression ? Should I left enabled or not ?

Celerra/VNX uses a dedup at file level, not at block level, so I suppose it's better to compress at beginning to limit lan traffic and Celerra cpu

Any best practice ?

I hope in future a detailed white paper will be issue about ES1 with all storage type enalbe in ES1.

Till now I found one only for DataDomain with ES1.

Thank you

Best

Andrea