On Sat, Dec 8, 2012, at 10:34 AM, anant@xxxxxxxxxxx wrote: > ----- Message from brong@xxxxxxxxxxx --------- > Date: Sat, 08 Dec 2012 10:18:29 +0100 > From: Bron Gondwana <brong@xxxxxxxxxxx> > Subject: Re: Need your urgent advice > To: anant@xxxxxxxxxxx, Dan White <dwhite@xxxxxxx> > Cc: Info Cyrus <info-cyrus@xxxxxxxxxxxxxxxxxxxx> > > > > On Sat, Dec 8, 2012, at 09:11 AM, anant@xxxxxxxxxxx wrote: > >> Thanks for your inputs. As per the thread link you mentioned, it > >> looks like corruption in mailboxes.db. I plan to start the process > >> given in next 4 hours time with a downtime > >> (README.HOWTO-recover-mailboxes.db). This is going to take a huge > >> amount of time. I have done it before some few years back, when I had > >> to move mailboxes to another storage. But, this time, I did not do, > >> since, I thought 2.3.7 and 2.3.16 are same level versions and hence > >> may not be required. > >> > >> If I can get any other alternative option from you within next 4 > >> hours, then I can think of that solution. Otherwise, I am going ahead > >> with downtime and run the procedure documented in > >> README.HOWTO-recover-mailboxes.db. Any other advise from experts is > >> welcome. > > > > The problem is that the mailboxes.db contents format is unchanged, but > > if you have mailboxes.db itself as a Berkeley DB file, and your Cyrus is > > compiled against a different version of Berkeley, then that could cause > > problems. > > > > I think following the HOWTO as you plan is the best solution in your > > circumstance. > > > > Regards, > > > > Bron. > > -- > > Bron Gondwana > > brong@xxxxxxxxxxx > > Thanks. Apart from this, should I also do > 1. ctl_cyrusdb -r This should be part of your START block in cyrus.conf. You don't need to (and shouldn't!) run it during operations. > 2. tls_prune > 3. ctl_cyrusdb -c > 4. cyr_expire -E 3 These should all run from your EVENTS block in cyrus.conf (or from cron if you're so inclined) on a scheduled basis. I can't see that any of them would make any difference to crashing. > Or reconstruct -r -f will take care of all these steps? That will get you all the mailboxes.db records correct, I hope! I really don't like working with berkeley DB. Another option, if you have access to the old copy still, is to dump the mailboxes.db from there as a plaintext file with ctl_mboxlist and then import it into the new server. In 2.3.16 I would recommend skiplist for mailboxes.db. If you're using licenced Redhat, you may also want to check with Redhat support for advice, since they have presumably done this before. Regards, Bron. -- Bron Gondwana brong@xxxxxxxxxxx ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus