Was that user being indexed at the time by Smartermail?

Has anyone else run into this issue?

So I spent the better part of yesterday using a text editor and grabbed each email out of the GRP file. I placed each one in a separate text file and was able to open each email in my mail client after I renamed the extension to .EML. So my initial thought was a malformed email causing the issue, but that doesn't seem to be the case here. Here's the steps I took this morning to further narrow down the problem:

 

1. Stopped the SmarterMail service

2. Deleted the index files for this user along with the mailbox.cfg file from the Inbox

3. Started SmarterMail back up and logged into the interface

4. Issued a re-index of the users mailbox and bam the web interface starts to time out again.

5. Stopped SmarterMail and took the 308mb GRP file out again

6. Started SmarterMail again and reissued a re-index this time without the 308MB GRP file in place

7. No issues with the web interface while the re-index was happening for this user

 

So then I went a step further, I audited the entire mail server Domain folder for SmarterMail using AgentRansack. The query I fed it was giver me every GRP file in this folder no matter who's domain it is and show me any GRP files that are over 200MB. Looking at some of the other users Inbox files that are over 200MB don't have an issue. So I took a GRP file from the same user from a previous day that was having this issue and copied all the text from the file that was causing the problem and backfilled it into the other GRP file using EditPad. I only overwrote the text and not the header information. We will see what happens now. Thinking maybe corrupt GRP file? It's really odd. Is there an easier way to rebuild a GRP file than what I just did?

If you have been archiving the email this might have been simpler: Recover the email from the archive for the day in question, restore it to a different mailbox first; then check with the user, and delete all non-wanted email before restoring it to the Inbox.

 

You could even make a copy of the recovered email folder before transferring to the inbox. Then, if the problem recurs, you have a better starting point.

 

If you're not archiving the email, it's a good idea to start now.  Disk space is so cheap, and you can add a drive to the server if needed, specifying the location of a folder on that drive for just the archive data. It's saved my butt on many an occasion. As you know, email gets "lost" for all kinds of reasons.

 

Indeed, I recently "fixed" a disk space problem by adding a RAID1 pair of 1TB drives to an SM server, copying the archive files there, changing the archive location to that folder on the new RAID volume and then stopping/restarting the SM service (the Windows service, not from within the SM GUI - doing it through the SM GUI does not work!).

 

Just before restarting the service, I used FastCopy to update the archive's new location with any changes from the old location - this took seconds; it had been set up in advance. After verifying that the new location was receiving the archived files, I deleted the archive from the old location. Voila, about 450GB of new space (in my case of course) on the SM main volume.

 

Hope this is helpful going forward.

 

We backup the entire server every night. So I can just easily restore from a backup and be done with it. The GRP file at the time of the backup was even larger than the one in question. So my guess is the user moved some of the emails out to a separate folder. The big issue I am dealing with here is how to repair or rebuild the GRP file if it goes corrupt. Like in this instance. The other issue I just dealt with now is that SmarterMail has to chew on that large 308mb file to reindex so 0the user can see it in webmail. Well after an hour of attempting to reindex it, it never did. So I took the file out and I am going to put the previous night larger file in place and see what happens. This is frustrating to say the least.