On 13.12.2013, at 17.49, Michael Smith (DF) <msm...@datafoundry.com> wrote:
> We're using Dovecot 2.2.4 and mdbox storage with compression. > > I noticed yesterday that at least one of the accounts has unusual files in > it's mail/storage directory. This account has approximately 17.5G of > compressed mail, across about 750 storage files (m.###) using 8G of storage. > > Starting on Dec 11, storage files m.409 through m.731 have not only their > m.### file, but also a m.###.broken file. At the same time .temp.<unix > time>.<unique id>.<hostname> files also started showing up... > ... > -rw--w---- 1 user123 mail 3225 Dec 12 04:38 m.708 > -rw--w---- 1 user123 mail 167106 Dec 12 03:35 m.708.broken > -rw--w---- 1 user123 mail 46155 Dec 12 04:38 m.709 > -rw--w---- 1 user123 mail 177267 Dec 12 03:40 m.709.broken .. > What caused this problem? Something caused mdbox rebuilding, which triggered this bug: http://hg.dovecot.org/dovecot-2.2/rev/f965670a7b69 > How concerned should I be about possible lost email? This is a production > environment. It's very likely there is some lost emails in the *.broken files. Fix would be to 1) upgrade to v2.2.6 or newer 2) take a backup of the mdbox 3) move *.broken to their original names. 4) doveadm force-resync -u user@domain INBOX The main problem here is that after Dovecot fixed e.g. m.1234 file and copied the original to m.1234.broken, it could still have added some new mails to m.1234 file and by replacing it those mails would get lost. This one is a bit tricky to check and to fix.. One possibility would be to use "doveadm dump" for the m.1234 and m.1234.broken files and verify that the .broken file has all the GUIDs that m.1234 has (and more). Except it's possible that user would have intentionally deleted some of those mails, so if you bring some mails back user might have to re-delete some of them.
