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 (dar@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:
- create mailbox for testing, here test@example.com
- create IMAP folder under INBOX ( namespace inbox { separator = / } )
doveadm mailbox create -u test@example.com INBOX/test
- attempt to restore from backup
doveadm backup -u test@example.com -R maildir:/mnt/mail-backups/test/
which yields (on Dovecot 2.2.12)
dsync(test@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 test@example.com testtest # doveadm backup -u test@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.