On 8.4.2013, at 1.32, Bob Gustafson <bob...@rcn.com> wrote: > Ok, how is this for a scheme: > > 1) Initially rsync Maildir to destination system > 2) Do initial 'dsync backup' from Maildir to sdbox on destination system > 3) Do a 2nd rsync of new Maildir data from live system to destination > system, but don't copy the old maildir-uidlist still in the Maildir of > the live system. > rsync -ar --times --exclude=dovecot-uidlist <live sys Maildir> <dest > system Maildir> > > I could also use the --ignore-existing option > > In theory, rsync would not touch the dovecot-uidlist file, would not > touch the existing message files, but would copy over the new messages > received during the time 'dsync backup' was doing its previous run. > > 4) Do a 2nd 'dsync backup' from the Maildir to the sdbox (which hasn't > changed since the 1st 'dsync backup')
Without rsync --delete you may end up with duplicates if message flags had changed during it. There's also another potential problem. Since you don't now update the dovecot-uidlist, the message UIDs may change. Some clients cache messages by their UID. These clients may lose messages or show wrong messages to users. So for example if: 0. rsync + dsync is run to sdbox. dovecot-uidlist now says that next_uid=123 1. Maildir receives mail A that gets assigned UID 123 2. Maildir receives mail B that gets assigned UID 124 3. User deletes mail A 4. rsync is run, which copies the new mail B 5. dsync is run, which notices a new mail B, and assigns it the a new UID 123 6. You switch user to new Dovecot 7. dbox receives a new mail C, and gets assigned UID 124 8. User's client is now pretty much completely confused about what UIDs 123 and 124 contain. User may see different mails as subject and body. User may not even see the mail B anymore without a client cache rebuild. Yet another possibility would be to use dsync to migrate the mails using IMAP protocol rather than from Maildir directly: http://wiki2.dovecot.org/Migration/Dsync
