Scalix Forums

I think building level of SUR/ISS expertise within the Scalix user community is necessary step towards the goal of creating a new interface for SUR.

I'd like to start a SUR HOWTO off in the wiki. Unlike the Aamavisd-New HOWTO it will be utterly reliant on collaboration since my current level of expertise in this area could be described as slightly above clueless.

To get the ball rolling, would it be ok to paste in the 'Corruption/Recovery, ISDB, and SUR' technote & the 'cookbook' Florian posted a while back? I & I suspect more than a few others have questions relating to this documentation that will hopefully find answers in the wiki.

Cheers.

Hi Ben

I may be speaking out of turn here but this may be unneccessary, depending on your intentions.

mikevl wrote:Hi Ben

I may be speaking out of turn here but this may be unneccessary, depending on your intentions.

Not at all Mike.

My intentions were to able to do SURs easily without having to do omcpoutu based backups.

Plus, on a purely intellectual level, I just don't like not understanding things.

Be glad to hear your thoughts.

Hi Ben I suspect that in the fullnes of time the SUR/ISS thingy may receed into the background.

You may find other advances comming our way.

Many thanks

Mike v

Hi Mike,

curious where did you get that insight from?


Hi Ben,

thanks for your thoughts and I'd actually like to encourage you to do exactly that; certainly it is ok to copy/paste from other documents or stuff that we've published into this Wiki page. Just open it up anywhere on the Wiki and once it becomes of useful size and content, I'll also link it into the Wiki main/start page (which is protected at this point).

I do believe that the ISS and SUR infrastructure we have in place today has some value; next to being a backup/recovery method amongs others,the ISDB can be a helpful tool for diagnosing and repairing some message store corruption issues. Therefore, for an advanced scalix administrator who feels omcontain is his second home, this is indeed very useful.

I do agree that doing backup/single user restore based on this infrastructure is too complex for most installations, especially the smaller shops. We haven't done a great job documenting this - partially in all honesty because not everyone in Scalix has used this particular part of the system - it comes from the legacy OpenMail codebase the Scalix server is buiild on. We're reworking some of the admin docs for Scalix 11 and the overall subject of backup and recovery will get broader coverage. In addition, we plan to transition more of the Knowledgebase articles to the Wiki so that they can be more easily changed, edited and enhanced - by Scalix as well as the community.

In terms of long-term viability of this doc - the facilities will be there, relatively unchanged, in Scalix 11 - through this new release will contain a couple of other features that will make admin's backup and recovery life much easier - including one that should help to prevent the necessity for restores for certain cases altogether. Stay tuned for details. Anyway, everything that is being created in addtional docs for ISS, ISDB and SUR will be valid for 11 with minor change.

Long term roadmap - well, we have some plans to modify the architecture of our message store. this would then certainly have some kind of effect on the technologies mentioned; however, until this hits, we'll be well into 2007 I believe so that should give enough lifetime for all efforts spent today.

Hope this helps,
Florian.

including one that should help to prevent the necessity for restores for certain cases altogether.

Heard this before
The rest of what you have said Florian is great stuff. As always your post is very in depth. Thanks for expanding on this subject.

mikevl wrote:including one that should help to prevent the necessity for restores for certain cases altogether.

Heard this before

Well, we're talking to email admins all over the world constantly; one very common theme is that still the hottest reason to have to do single user restore is the fact that users accidentally delete objects from their mailbox. If the person in question is important enough in the organisation, this usually causes rushed and time-consuming actions on the side of the admin.

Now... this particular scenario is probably something we could address in a more meaningful way. In addition, for export/import-based backup, some higher degree of control over the export and import process would make it more useful as well!

Florian.

Just got back off holiday - cheers Florian & Mikevl, I'll get on this soonish.