Native Archive NAS (share) locations

Thanks Gary!

Here are some things that you need to keep in mind:

Q: If you create multiple Native Archive Folders, is all the content put in the same folder, or does it create subfolders based on the name you give the archive folder

A: When you have multiple archive folders, the data will reside in multiple folders based on the criteria used for archiving. These archive folders will then maintain monthly subfolders containing emx files.

Tips / Pros & Cons

- Having single archive folder will allow you to de-duplicate data across that folder. Less storage space is consumed.

- Multiple archive folders means, you now have a tendency to archive multiple copies of a single message across multiple archive folders. Hence, you are losing de-duplication feature between multiple archive folders. You still maintain de-duplication within a particular archive folder but not across multiple archive folder and more storage space is required.

- If you are looking to logically separate data, then having multiple mapped folders pointing to a single archive folder is the best option.This guarantees de-duplication as well as logical separation of data.

This is directly contrary to what we have been told since the beginning and what is being told overall to customers.

Single Instancing is maintained by the message ID's at the DB level and has nothing to do with the storage location.

Here is an excerpt directly from the SourceOne Architecture marketing information:

Ÿ Enterprise-wide single instancing

– Single database, new hashing algorithm for increased accuracy

The only Deduplication at the file level would be based on the storage platform using a target based deduplication technology.

I also should state, that ONE of our countries is looking to implement Kazeon and will want (and can only) search their user's data.  Another reason for me thinking separate Archive Folders to keep them away from other data.

As for the method to separate each country's data into separate archive folder, we will probably use a metadata field because each country has a unique and exact string in the country field. (assuming the EMC terminology for metadata is equal to Microsoft's Active Directory Attributes on an object).

Ibrahim,

What you state makes sense.  We would want to keep as much de-duplication as possible.

We are considering creating a 2 Native Archives for each country that we archive mail data from; we have 2 different retention periods per country.

We want and almost need to determine how much space each country is consuming in our archive system.  As far as I know, just like EmailXtender, there is no way of calculating the total storage consumed by one owner (unless you do a search for, and export that owner's data).  Thus if we separate the countries into separate Archive Folders, we can see at least the compressed size of the mail archive for each country.

We also consider the fact that the legal team in each country will at some point want to search on the data for their country.  We wouldn't want them to be able to search data from other countries.  With this in mind, giving them access to search only their country's data would be easier if kept separate from the beginning, yes?

We are on the fence as whether to create:

2 Archive Folders for our whole environment, 1 for each retention period

or

18 Archive Folders, 2 for each country that we are archiving content for.

Message was edited by: Wisers, because he just cannot spell correctly past 10pm these days.

Wiser, ... no worries on spelling mistakes.

Retention and Legal department requirements mentioned here, make sense for having two separate archive folders. And then having there separate mapped folder with permissions would work.

To add to this, if you have centera storage it would allow you to further de-duplicate the data on attachment level - known as Large Content separation.

Doesn't SourceOne maintain only one copy of each message independently of where it's stored?

Isn't it Single Instanced across the SourceOne platform?

Single instance storage is maintained cross an archive folder. Have multiple archive folders is like creating multiple sections where one section is not aware of others data.

Gary, single instance in my thread refers to message instance stored per archive folder and does no reference to DB or a MessageID. We need to keep in mind that thread relates to storage space consumption. DB and MessageIDs are not being discussed in this thread.

Kind of a moot point.

Once they are containerized there is no additional single instancing or de-duping unless there is some other magic I wasn't aware of.

A file is stored in a folder based on it's retention and the rules/mapped folder that sent it there no matter whether it's in a shared storage location or in separate storage locations. How does an additional Single Instancing take place?

Gary, your question / information does not apply to all possible containerization models in SourceOne. One size does not fit all.

You have to see de-duplication from two different perspectives:

- Mapped Folder.

- Archive Folder.

When talking about mapped folders, we have ability to do '1 to 1' or 'many to 1' relation with archive folder. When archiving is performed, activities point to a mapped folders and not to the archive folders directly.

Example: You want to archive a message that is sent to HR and IT Department. In SourceOne you have two mapped folders, HR and IT that make use of rule based archiving.

Scenario: Two mapped folder point to one archive folder 

- De-duplication will allow you to have one instance of a message and both of the mapped folders will reference to that one instance of a message.

Scenario: Two mapped folder and two archive folder - mapped folders have 1 to 1 relation with archive folders due to retention requirements

- Now, you are overriding de-duplication and as a result you will have two copies of a same message in archives, one in each archive folder. You ask why? because you want to have two different sets of retention on each message.

True, but the model you are taking about is not the typical installation.

In practice the likelihood is small and I think your response was confusing at best especially considering the audience is usually SourceOne beginners.

I understand now what you are talking about.

When you first made the statement I wasn't sure what you were talking about and I'm far from a beginner.

Our responses here need to be tailored to the audience at hand.

As always, your input is greatly appreciated.