The last sentence describes what happened to you: all new mail on the
new machine is a "change" and was discarded (by deleting new mail.) If
I'm not mistaken, this is correct behaviour for backup mode - you get
exact copy of the source side (maildir:/tmp/mail_backup) on
destination side (d...@darklajid.de)
That would be sort of okay. Except that isn't what happened:
- The target mailbox was killed completely
- Nothing was restored
If what you're suggesting here is true I'd expect a clean copy of my
source - even if it destroys all other changes. That did NOT happen
though. It nuked the target and didn't restore a thing.
True - if we move from "problem is dsync deleted new mail" to "problem
is dsync was unable to restore the backup", the described behaviour
looks like a bug to me too. It may have something to do with the maildir
format, I recall some discussion regarding folder INBOX, which needs
special handling (because it's physically stored in maildir root,
whereas every other folder is stored in folder-named subdirectory)
That said, I tried something along what you did and it failed for me
too. So I deleted the mailbox completely, recreated it, tried again and
this time the restore succeeded. It seems the easiest possible way to
reproduce the faulty behaviour is:
1. create mailbox for testing, here t...@example.com
2. create IMAP folder under INBOX
( namespace inbox { separator = / } )
# doveadm mailbox create -u t...@example.com INBOX/test
3. attempt to restore from backup
# doveadm backup -u t...@example.com -R maildir:/mnt/mail-backups/test/
which yields (on Dovecot 2.2.12)
dsync(t...@example.com): Error: Mailbox INBOX sync: mailbox_delete
failed: INBOX can't be deleted.
Another try shows that IMAP folder created somewhere else (not under
INBOX) isn't a problem:
# doveadm mailbox create -u t...@example.com testtest
# doveadm backup -u t...@example.com -R maildir:/mnt/mail-backups/test/
This yields no output, folder testtest is deleted (as expected), INBOX
is populated from backup.
Another try, this time I used mbox instead of maildir by specifying
-o mail_location=mbox:/path/test/mail
to doveadm. Worked without error even with INBOX/test folder (which got
deleted during restore)
No idea if this can be considered as a bug, or the test does something
that is not supposed to be done in the first place (Although different
results with different storage format suggests a bug to me.)
Plus, dsync mirror did exactly the same: Nuked the (live) mailbox once
more, same error message, not a single message restored (but also no
modification to the source).
I was doing some trial and error testing with doveadm sync (should be
the same as dsync mirror.) If used on a mailbox which has seen some
changes, this sync's behaviour is just strange.
Or - to be more precise - it seems strange on first sight, but when you
think about it, it does what is supposed to do. The sync mode is (AFAIK)
designed to keep single mailbox synchronized on two hosts. If you
created new mailbox on the new host, then had some mail delivered to it
and after some time decided to add mail from old host, then you don't
have single mailbox - you have two mailboxes with the same name.
In other words this scenario is probably something dsync wasn't designed
to be used for and there's no surprise mirror mode can't handle it.
And again - I'm no expert, so it's entirely possible everything I wrote
here is complete and utter nonsense Let's hope someone more
knowledgeable corrects me if that is the case.
