[Dovecot] Same filenames on different servers?

[Steffen Kaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 11 Jan 2010, Alexander Chekalin wrote:

> Yes, I'm trying to make some backup solution.
>
> The idea was to have two identical (well, nearly identical) servers with the 
> same software and data on them, and while the first do its job as SMTP and 
> POP3/IMAP4 server, the second server just get copy of first's current state 
> (that is, copy user db and mail spool). In case of something wrong with 1st 
> server I'll just put its IP on second one and will go on.

So, where does the duplicate name comes from?
This paragraphe sounds as no user accesses the secondary server by
default.

> And the problem is that rsynced mailboxes sometimes have duplicates that may 
> confuse users. It happens when box changes between rsyncs by means of 
> Dovecot's ordinary operations (when msg file move from new/ to cur/ on 1st 
> server and after rsync to 2nd this may produce two files with same filename 
> in new/ and cur/

When Dovecot on the second server is not running - well, I guess that's
true as long as nobody logs in - ,  you can do a

rsync --delete -razH primaryServer secondaryServer

so the secondary server has a complete copy of the Maildir of the primary
server (well, if you have separated INDEXes or CONTROL from there,
another rsync is required).

If you omit the "--delete", you should have plenty of duplicate messages
in cur/, because any change of keywords or status will change the
filename, too. Also, any deleted message would be still there.
So I still wonder, where your duplicates come from.

Your user won't complain that a message is back "NEW", once the
secondary took over, will they?

I make "rsync backups" as well, but restore them as "new" folders, e.g.
.Archive.Sub.Folder becomes .RESTORE.Archive.Sub.Folder, in order to
avoid the problem you describe.

> and Dovecot for some reason renames one of it).

Because Maildir is designed that way that no duplicate filename stem
(part before colon) must exist. So any server may handle this situation
on its own.

Regards,

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBS0tAg7+Vh58GPL/cAQIYhgf+OpvlwRZS1JcNXnCeBY7tsNunWk6zIHQD
cU1I5LS8it/zLLBt2ORYkm0+u7rRxMYcigEgNsHB1m71f2BeYthlczPzYSm+A17b
OmPwb9oZ6ZCJxk8jXzF6GZ39PgT6UoPHqiN0oo6RH2Xso6FYrp0/KibU96K9+uO0
3dXBbl10TdxCfPYvLgO46ounaBVBW3D/xDzKIUeW4DTWApnPuB/gjXs68lYKoZrb
F/2pGQAwDGF1uMyOq1dY4Mefe05uzgA4TR/IBzYHMtBhG+YLpKqxg/sGFTTMjTPS
DfMtHc0fFbyiIpJOZ7YwwRpq2hNd4tXm7Yq3PmG7eU+guxQboeBkJw==
=I4Da
-----END PGP SIGNATURE-----