[Dovecot] dsync error: "Mailboxes don't have unique GUIDs"
I'm getting an error backing up mailboxes. I'm using the mirrorcommand:
dsync -fvo mail_home=/home/users/bob mirror ssh vmail@10.1.4.1 dsync -o mail_home=/home/.incoming_mail_migrations/users/bob
dsync-remote(vmail): Error: Mailboxes don't have unique GUIDs: 1ef6ee37c694894d783100000581a675 is shared by INBOX and INBOX dsync-remote(vmail): Error: command BOX-LIST failed dsync-local(vmail): Error: Worker server's mailbox iteration failed
The mail user doesn't yet exist on the destination yet, thus the use ofthe mail_home parameter. I found a mailing list message where a person was having a similar problem but I couldn't find confirmation that the issue was resolved. In our case, the backup goes from maildir to mdbox format (we can't to convert to mdbox). Things seemed to be moving along, but there are quite a few examples of dsync failing. I think the issue happens more often with large mailboxes ( > 50GB ). We're running version 2.0.13. doveconf -n:
# 2.0.13: /etc/dovecot/dovecot.conf # OS: Linux 2.6.18-274.12.1.el5 x86_64 CentOS release 5.7 (Final) auth_mechanisms = plain login default_client_limit = 15000 default_process_limit = 10000 disable_plaintext_auth = no listen = * mail_gid = vmail mail_location = maildir:~/Maildir mail_plugins = zlib mail_uid = vmail mmap_disable = yes namespace { inbox = yes location = prefix = INBOX. separator = . } passdb { args = /etc/dovecot/conf.d/dovecot-sql.conf.ext driver = sql } plugin { zlib_save = gz } protocols = imap pop3 service auth { client_limit = 10000 unix_listener auth-userdb { mode = 0666 } } service imap-postlogin { executable = script-login /usr/bin/postlogin-imap.sh user = $default_internal_user } service imap { drop_priv_before_exec = yes executable = imap process_limit = 10000 } service pop3-postlogin { executable = script-login /usr/bin/postlogin-pop.sh user = $default_internal_user } } service pop3 { drop_priv_before_exec = yes executable = pop3 process_limit = 2500 } ssl_cert =
...Jeff
Hey, just a point of clarification.
In at least some of the cases (possibly all, I'll leave that up to Jeff to state) an initial dsync (as documented in Jeff's message) was completed successfully and the problem occurred when we ran a second (using exactly the same cmd) time to catch any changes since the original sync (since the initial sync took many hours).
Doug
On Jun 22, 2012, at 2:24 PM, Jeff Gustafson wrote:
I'm getting an error backing up mailboxes. I'm using the mirror command:
dsync -fvo mail_home=/home/users/bob mirror ssh vmail@10.1.4.1 dsync -o mail_home=/home/.incoming_mail_migrations/users/bob
dsync-remote(vmail): Error: Mailboxes don't have unique GUIDs: 1ef6ee37c694894d783100000581a675 is shared by INBOX and INBOX dsync-remote(vmail): Error: command BOX-LIST failed dsync-local(vmail): Error: Worker server's mailbox iteration failed
The mail user doesn't yet exist on the destination yet, thus the use of the mail_home parameter. I found a mailing list message where a person was having a similar problem but I couldn't find confirmation that the issue was resolved. In our case, the backup goes from maildir to mdbox format (we can't to convert to mdbox). Things seemed to be moving along, but there are quite a few examples of dsync failing. I think the issue happens more often with large mailboxes ( > 50GB ). We're running version 2.0.13. doveconf -n:
# 2.0.13: /etc/dovecot/dovecot.conf # OS: Linux 2.6.18-274.12.1.el5 x86_64 CentOS release 5.7 (Final) auth_mechanisms = plain login default_client_limit = 15000 default_process_limit = 10000 disable_plaintext_auth = no listen = * mail_gid = vmail mail_location = maildir:~/Maildir mail_plugins = zlib mail_uid = vmail mmap_disable = yes namespace { inbox = yes location = prefix = INBOX. separator = . } passdb { args = /etc/dovecot/conf.d/dovecot-sql.conf.ext driver = sql } plugin { zlib_save = gz } protocols = imap pop3 service auth { client_limit = 10000 unix_listener auth-userdb { mode = 0666 } } service imap-postlogin { executable = script-login /usr/bin/postlogin-imap.sh user = $default_internal_user } service imap { drop_priv_before_exec = yes executable = imap process_limit = 10000 } service pop3-postlogin { executable = script-login /usr/bin/postlogin-pop.sh user = $default_internal_user } } service pop3 { drop_priv_before_exec = yes executable = pop3 process_limit = 2500 } ssl_cert =
...Jeff
On 2012-06-22 5:24 PM, Jeff Gustafson ncjeffgus@zimage.com wrote:
I'm getting an error backing up mailboxes. I'm using the mirror command:
dsync -fvo mail_home=/home/users/bob mirror ssh vmail@10.1.4.1 dsync -o mail_home=/home/.incoming_mail_migrations/users/bob
<snip>
# 2.0.13: /etc/dovecot/dovecot.conf
As you are aware (since you participated in the thread discussion about this months ago), Timo is working on a total rewrite of dsync, and if memory serves, it is mainly for 2.1+, and it is not recommend to use it in earlier versions if you need reliability (ie, 2.0.x, as you are using)...
So, by all means, update and help timo make it better!
Timo? Care to elaborate on where you are with this, and how much of the rewrite is being applied to 2.1 (all of it?), or backported to earlier versions?
--
Best regards,
Charles
On Sat, 2012-06-23 at 06:29 -0400, Charles Marcus wrote:
<snip>
# 2.0.13: /etc/dovecot/dovecot.conf
As you are aware (since you participated in the thread discussion about this months ago), Timo is working on a total rewrite of dsync, and if memory serves, it is mainly for 2.1+, and it is not recommend to use it in earlier versions if you need reliability (ie, 2.0.x, as you are using)...
I did try the 2.1.x version of dsync back in March. I found the versionto be very unreliable. It would crash with many types of operations (e.g. maildir -> mdbox conversions).
...JeffOn 2012-06-25 12:45 PM, Jeff Gustafson ncjeffgus@zimage.com wrote:
On Sat, 2012-06-23 at 06:29 -0400, Charles Marcus wrote:
# 2.0.13: /etc/dovecot/dovecot.conf
As you are aware (since you participated in the thread discussion about this months ago), Timo is working on a total rewrite of dsync, and if memory serves, it is mainly for 2.1+, and it is not recommend to use it in earlier versions if you need reliability (ie, 2.0.x, as you are using)...
I did try the 2.1.x version of dsync back in March. I found the version to be very unreliable. It would crash with many types of operations (e.g. maildir -> mdbox conversions).
Well, the version in 2.0.x was problematic, which is why Timo was rewriting it from scratch.
Also, that was 3 *months* ago - more than likely a lot has changed since then.
I'd suggest you try again with 2.1.7...
--
Best regards,
Charles
On 25.6.2012, at 19.49, Charles Marcus wrote:
I did try the 2.1.x version of dsync back in March. I found the version to be very unreliable. It would crash with many types of operations (e.g. maildir -> mdbox conversions).
Well, the version in 2.0.x was problematic, which is why Timo was rewriting it from scratch.
Also, that was 3 *months* ago - more than likely a lot has changed since then.
I'd suggest you try again with 2.1.7...
The rewritten dsync is in v2.2 tree. v2.1's dsync is a fixed version of v2.0's dsync. I have no idea why v2.1's dsync would be less reliable than v2.0's. It only had bugfixes.
Anyway, the GUID error could very well be because of buggy mailbox listing code in v2.0, which was rewritten for v2.1.
On Mon, 2012-06-25 at 19:54 +0300, Timo Sirainen wrote:
On 25.6.2012, at 19.49, Charles Marcus wrote:
I'd suggest you try again with 2.1.7...
The rewritten dsync is in v2.2 tree. v2.1's dsync is a fixed version of v2.0's dsync. I have no idea why v2.1's dsync would be less reliable than v2.0's. It only had bugfixes.
Anyway, the GUID error could very well be because of buggy mailbox listing code in v2.0, which was rewritten for v2.1.
I will try the latest 2.1.x code and see what happens. dsync in 2.0.xseems to work just fine... most of the time.
...Jeff
participants (4)
-
Charles Marcus
-
Doug Henderson
-
Jeff Gustafson
-
Timo Sirainen