Re: migration with doveadm backup to new cluster running dovecot 2.2.36 and replicator
When doing migration, it is very useful to construct a temporary dovecot-migration.conf which lacks *any* automatic mailbox creation and has only the bare minimum you need (sieve needs to be configured, and mailbox attributes). This means no autocreate/autosubscribe loaded, and no auto=create or auto=subscribe in namespace config. It is recommended not to have any mailbox Name entries in your namespace config. You should use doveadm -c /path/to/dovecot-migration.conf backup command on initial sync. The mailboxes must not exist before you do initial sync, if they do, you run into troubles. I tried what you said, no autocreate/autosubscribe... etc., but none of my tests with minimal migration config changed anything in the GUID behavior. No folders for the users existed before this command. doveadm -D -v -c minimal-conf backup -R -u USER imapc: > output 2>&1 doveadm(USER): Debug: Effective uid=500, gid=500, home=/srv/mail/v/USER doveadm(USER): Debug: Namespace : type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=mdbox:/srv/mail/v/USER doveadm(USER): Debug: fs: root=/srv/mail/v/USER, index=, indexpvt=, control=, inbox=, alt= doveadm(USER): Debug: Namespace : Using permissions from /srv/mail/v/USER: mode=0700 gid=default dsync(USER): Debug: Effective uid=500, gid=500, home=/srv/mail/v/USER dsync(USER): Debug: Namespace : type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=imapc: dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Created new connection dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Looking up IP address (reconnect_ok=true, last_connect=1610467047) dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Connecting to 137.250.1.99:143 dsync(USER): Info: imapc(zitrone.rz.uni-augsburg.de:143): Connected to 137.250.1.99:143 (local 137.250.1.121:41094) dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Server capabilities: IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Authenticating as admin for user USER dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Server capabilities: IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS QUOTA dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Authenticated successfully dsync(USER): Debug: imapc: root=, index=, indexpvt=, control=, inbox=, alt= dsync(USER): Debug: brain S: Local mailbox tree: Trash guid=7f5af7ba291b2df1a11d573bdb55d7e9 uid_validity=1598518510 uid_next=434 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain M: Remote mailbox tree: Trash guid=7f5af7ba291b2df1a11d573bdb55d7e9 uid_validity=1598518510 uid_next=434 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain S: Local mailbox tree: Sent guid=bfb2e03fdce327671e82bf173b1ccb8b uid_validity=1598518508 uid_next=220 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain M: Remote mailbox tree: Sent guid=bfb2e03fdce327671e82bf173b1ccb8b uid_validity=1598518508 uid_next=220 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain S: Local mailbox tree: Drafts guid=e0187b65e763143666d22094cedfe6a4 uid_validity=1598518507 uid_next=10 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain M: Remote mailbox tree: Drafts guid=e0187b65e763143666d22094cedfe6a4 uid_validity=1598518507 uid_next=10 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain S: Local mailbox tree: INBOX guid=c92f64f79f0d1ed01e6d5b314f04886c uid_validity=1598518506 uid_next=1049 subs=no last_change=0 last_subs=0 dsync(USER): Debug: brain M: Remote mailbox tree: INBOX guid=c92f64f79f0d1ed01e6d5b314f04886c uid_validity=1598518506 uid_next=1049 subs=no last_change=0 last_subs=0 ... for user in USER; do echo $user ; for mailbox in `ls /srv/mail/v/$user/mailboxes/`; do echo $mailbox; doveadm search -u $user mailbox $mailbox ALL | head -n 1; done ; done USER Drafts INBOX c92f64f79f0d1ed01e6d5b314f04886c 28 Junk Sent bfb2e03fdce327671e82bf173b1ccb8b 1 Trash 7f5af7ba291b2df1a11d573bdb55d7e9 1 doveadm -D -v -c minimal-conf backup -R -u USER2 imapc: > output 2>&1 doveadm(USER2): Debug: Effective uid=500, gid=500, home=/srv/mail/v/USER2 doveadm(USER2): Debug: Namespace : type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=mdbox:/srv/mail/v/USER2 doveadm(USER2): Debug: fs: root=/srv/mail/v/USER2, index=, indexpvt=, control=, inbox=, alt= doveadm(USER2): Debug: Namespace : Using permissions from /srv/mail/v/USER2: mode=0700 gid=default dsync(USER2): Debug: Effective uid=500, gid=500, home=/srv/mail/v/USER2 dsync(USER2): Debug: Namespace : type=private, prefix=, sep=/, inbox=yes,
Re: migration with doveadm backup to new cluster running dovecot 2.2.36 and replicator
> On 11/01/2021 05:18 Thomas Winterstein > wrote: > > > we were able to narrow down the cause of the problem. > > > After the initial dsync migration process the mailbox GUIDs are the same > for each mailbox-name across all users. > Is this intended behaviour of dsync? > If not, how can this be changed? > > > After the first replication process the Inboxes of ~20% of users get > different mailbox GUIDs. > > > During the next incremental dsync process the mailbox GUIDs of these > ~20% get overridden by the inital one. > > > Then the incremental replication duplicates those Inboxes where the > mailbox GUIDs don't match. > > > Any ideas? > > > thanks > Thomas > > On 07.01.2021 16:41, Thomas Winterstein wrote: > >>> dsync is intended to be used to change mailbox format, so it should > >>> work just fine. > > > > that's exactly what we thought and why we use dsync to migrate like > > described here > > > > https://wiki2.dovecot.org/Migration/Dsync > > > > > > Our replication is configured according to > > > > https://wiki.dovecot.org/Replication > > > > > > Both processes run separately in time. > > > > > > Still on some accounts mails of Inbox or another folder get duplicated. > > We're currently trying to debug this. > > > > what are we missing? > > > > thanks > > Thomas > > > > On 07.01.2021 10:21, Aki Tuomi wrote: > >> dsync is intended to be used to change mailbox format, so it should > >> work just fine. > >> > >> Aki > >> > >>> On 07/01/2021 11:17 Andrea Gabellini > >>> wrote: > >>> > >>> Hello, > >>> > >>> I had a similar problem some time ago, and the problem was the mailbox > >>> format change. > >>> > >>> Please try to migrate with the same format. > >>> > >>> Andrea > >>> > >>> Il 05/01/21 15:02, Thomas Winterstein ha scritto: > No one? > > If there are limitations in regards to how dsync in migration and > replication can operate together these should be stated clearly in the > documentation. > > On 23.12.2020 20:33, Thomas Winterstein wrote: > > Hello everyone, > > > > > > we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 > > (mdbox). The new cluster has two backend mail servers which replicate > > through doveadm replicator. To move the data initially we use doveadm > > backup (imapc). > > > > arb > > Our migration command > > doveadm -o mail_fsync=never backup -R -u $user imapc: > > > > > > To test the replication of new and purge of old mails with live data > > changes we ran imapc on a daily basis but encountered the problem > > that some mailboxes multiplied in size. We then made sure that imapc > > and replication don't run at the same time but after the first > > incremental imapc process, we still had the same problems. > > > > > > The doveadm-backup man-page states that it's possible to run it > > multiple times during migration. But is it also possible to have the > > replicator running in between? From our understanding the doveadm > > backup should just work as an imap connection between the servers, > > synchronizing all changes made on the source to the destination. Or > > does the conversion from maildir to mdbox format in our case produce > > the problems? > > > > > > If you're not supposed to run the replicator before having fully > > migrated, how can we shorten the downtime? rsync? And how can we be > > sure that similar problems don't occur after the migration if we > > can't test all mechanisms together with live data? > > > > > > thanks > > > >>> When doing migration, it is very useful to construct a temporary dovecot-migration.conf which lacks *any* automatic mailbox creation and has only the bare minimum you need (sieve needs to be configured, and mailbox attributes). This means no autocreate/autosubscribe loaded, and no auto=create or auto=subscribe in namespace config. It is recommended not to have any mailbox Name entries in your namespace config. You should use doveadm -c /path/to/dovecot-migration.conf backup command on initial sync. The mailboxes must not exist before you do initial sync, if they do, you run into troubles. Aki
Re: migration with doveadm backup to new cluster running dovecot 2.2.36 and replicator
we were able to narrow down the cause of the problem. After the initial dsync migration process the mailbox GUIDs are the same for each mailbox-name across all users. Is this intended behaviour of dsync? If not, how can this be changed? After the first replication process the Inboxes of ~20% of users get different mailbox GUIDs. During the next incremental dsync process the mailbox GUIDs of these ~20% get overridden by the inital one. Then the incremental replication duplicates those Inboxes where the mailbox GUIDs don't match. Any ideas? thanks Thomas On 07.01.2021 16:41, Thomas Winterstein wrote: dsync is intended to be used to change mailbox format, so it should work just fine. that's exactly what we thought and why we use dsync to migrate like described here https://wiki2.dovecot.org/Migration/Dsync Our replication is configured according to https://wiki.dovecot.org/Replication Both processes run separately in time. Still on some accounts mails of Inbox or another folder get duplicated. We're currently trying to debug this. what are we missing? thanks Thomas On 07.01.2021 10:21, Aki Tuomi wrote: dsync is intended to be used to change mailbox format, so it should work just fine. Aki On 07/01/2021 11:17 Andrea Gabellini wrote: Hello, I had a similar problem some time ago, and the problem was the mailbox format change. Please try to migrate with the same format. Andrea Il 05/01/21 15:02, Thomas Winterstein ha scritto: No one? If there are limitations in regards to how dsync in migration and replication can operate together these should be stated clearly in the documentation. On 23.12.2020 20:33, Thomas Winterstein wrote: Hello everyone, we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 (mdbox). The new cluster has two backend mail servers which replicate through doveadm replicator. To move the data initially we use doveadm backup (imapc). arb Our migration command doveadm -o mail_fsync=never backup -R -u $user imapc: To test the replication of new and purge of old mails with live data changes we ran imapc on a daily basis but encountered the problem that some mailboxes multiplied in size. We then made sure that imapc and replication don't run at the same time but after the first incremental imapc process, we still had the same problems. The doveadm-backup man-page states that it's possible to run it multiple times during migration. But is it also possible to have the replicator running in between? From our understanding the doveadm backup should just work as an imap connection between the servers, synchronizing all changes made on the source to the destination. Or does the conversion from maildir to mdbox format in our case produce the problems? If you're not supposed to run the replicator before having fully migrated, how can we shorten the downtime? rsync? And how can we be sure that similar problems don't occur after the migration if we can't test all mechanisms together with live data? thanks -- __ Daddy, why doesn't this magnet pick up this floppy ? __ TIM San Marino S.p.A. Andrea Gabellini Engineering R TIM San Marino S.p.A. - https://www.telecomitalia.sm Via Ventotto Luglio, 212 - Piano -2 47893 - Borgo Maggiore - Republic of San Marino Tel: (+378) 0549 886237 Fax: (+378) 0549 886188 -- Informativa Privacy Questa email ha per destinatari dei contatti presenti negli archivi di TIM San Marino S.p.A.. Tutte le informazioni vengono trattate e tutelate nel rispetto della normativa vigente sulla protezione dei dati personali (Reg. EU 2016/679). Per richiedere informazioni e/o variazioni e/o la cancellazione dei vostri dati presenti nei nostri archivi potete inviare una email a priv...@telecomitalia.sm. Avviso di Riservatezza Il contenuto di questa e-mail e degli eventuali allegati e' strettamente confidenziale e destinato alla/e persona/e a cui e' indirizzato. Se avete ricevuto per errore questa e-mail, vi preghiamo di segnalarcelo immediatamente e di cancellarla dal vostro computer. E' fatto divieto di copiare e divulgare il contenuto di questa e-mail. Ogni utilizzo abusivo delle informazioni qui contenute da parte di persone terze o comunque non indicate nella presente e-mail potra' essere perseguito ai sensi di legge. -- Thomas Winterstein http://www.rz.uni-augsburg.de/ Universität Augsburg, Rechenzentrum . Tel. (0821) 598-2068 86135 Augsburg .. Fax. (0821) 598-2028
Re: migration with doveadm backup to new cluster running dovecot 2.2.36 and replicator
dsync is intended to be used to change mailbox format, so it should work just fine. that's exactly what we thought and why we use dsync to migrate like described here https://wiki2.dovecot.org/Migration/Dsync Our replication is configured according to https://wiki.dovecot.org/Replication Both processes run separately in time. Still on some accounts mails of Inbox or another folder get duplicated. We're currently trying to debug this. what are we missing? thanks Thomas On 07.01.2021 10:21, Aki Tuomi wrote: dsync is intended to be used to change mailbox format, so it should work just fine. Aki On 07/01/2021 11:17 Andrea Gabellini wrote: Hello, I had a similar problem some time ago, and the problem was the mailbox format change. Please try to migrate with the same format. Andrea Il 05/01/21 15:02, Thomas Winterstein ha scritto: No one? If there are limitations in regards to how dsync in migration and replication can operate together these should be stated clearly in the documentation. On 23.12.2020 20:33, Thomas Winterstein wrote: Hello everyone, we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 (mdbox). The new cluster has two backend mail servers which replicate through doveadm replicator. To move the data initially we use doveadm backup (imapc). arb Our migration command doveadm -o mail_fsync=never backup -R -u $user imapc: To test the replication of new and purge of old mails with live data changes we ran imapc on a daily basis but encountered the problem that some mailboxes multiplied in size. We then made sure that imapc and replication don't run at the same time but after the first incremental imapc process, we still had the same problems. The doveadm-backup man-page states that it's possible to run it multiple times during migration. But is it also possible to have the replicator running in between? From our understanding the doveadm backup should just work as an imap connection between the servers, synchronizing all changes made on the source to the destination. Or does the conversion from maildir to mdbox format in our case produce the problems? If you're not supposed to run the replicator before having fully migrated, how can we shorten the downtime? rsync? And how can we be sure that similar problems don't occur after the migration if we can't test all mechanisms together with live data? thanks -- __ Daddy, why doesn't this magnet pick up this floppy ? __ TIM San Marino S.p.A. Andrea Gabellini Engineering R TIM San Marino S.p.A. - https://www.telecomitalia.sm Via Ventotto Luglio, 212 - Piano -2 47893 - Borgo Maggiore - Republic of San Marino Tel: (+378) 0549 886237 Fax: (+378) 0549 886188 -- Informativa Privacy Questa email ha per destinatari dei contatti presenti negli archivi di TIM San Marino S.p.A.. Tutte le informazioni vengono trattate e tutelate nel rispetto della normativa vigente sulla protezione dei dati personali (Reg. EU 2016/679). Per richiedere informazioni e/o variazioni e/o la cancellazione dei vostri dati presenti nei nostri archivi potete inviare una email a priv...@telecomitalia.sm. Avviso di Riservatezza Il contenuto di questa e-mail e degli eventuali allegati e' strettamente confidenziale e destinato alla/e persona/e a cui e' indirizzato. Se avete ricevuto per errore questa e-mail, vi preghiamo di segnalarcelo immediatamente e di cancellarla dal vostro computer. E' fatto divieto di copiare e divulgare il contenuto di questa e-mail. Ogni utilizzo abusivo delle informazioni qui contenute da parte di persone terze o comunque non indicate nella presente e-mail potra' essere perseguito ai sensi di legge. -- Thomas Winterstein http://www.rz.uni-augsburg.de/ Universität Augsburg, Rechenzentrum . Tel. (0821) 598-2068 86135 Augsburg .. Fax. (0821) 598-2028
Re: migration with doveadm backup to new cluster running dovecot 2.2.36 and replicator
dsync is intended to be used to change mailbox format, so it should work just fine. Aki > On 07/01/2021 11:17 Andrea Gabellini > wrote: > > > Hello, > > I had a similar problem some time ago, and the problem was the mailbox > format change. > > Please try to migrate with the same format. > > Andrea > > Il 05/01/21 15:02, Thomas Winterstein ha scritto: > > No one? > > > > If there are limitations in regards to how dsync in migration and > > replication can operate together these should be stated clearly in the > > documentation. > > > > On 23.12.2020 20:33, Thomas Winterstein wrote: > >> Hello everyone, > >> > >> > >> we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 > >> (mdbox). The new cluster has two backend mail servers which replicate > >> through doveadm replicator. To move the data initially we use doveadm > >> backup (imapc). > >> > >> arb > >> Our migration command > >> doveadm -o mail_fsync=never backup -R -u $user imapc: > >> > >> > >> To test the replication of new and purge of old mails with live data > >> changes we ran imapc on a daily basis but encountered the problem > >> that some mailboxes multiplied in size. We then made sure that imapc > >> and replication don't run at the same time but after the first > >> incremental imapc process, we still had the same problems. > >> > >> > >> The doveadm-backup man-page states that it's possible to run it > >> multiple times during migration. But is it also possible to have the > >> replicator running in between? From our understanding the doveadm > >> backup should just work as an imap connection between the servers, > >> synchronizing all changes made on the source to the destination. Or > >> does the conversion from maildir to mdbox format in our case produce > >> the problems? > >> > >> > >> If you're not supposed to run the replicator before having fully > >> migrated, how can we shorten the downtime? rsync? And how can we be > >> sure that similar problems don't occur after the migration if we > >> can't test all mechanisms together with live data? > >> > >> > >> thanks > > > > > > -- > __ > Daddy, why doesn't this magnet pick up this floppy ? > __ > > TIM San Marino S.p.A. > Andrea Gabellini > Engineering R > TIM San Marino S.p.A. - https://www.telecomitalia.sm > Via Ventotto Luglio, 212 - Piano -2 > 47893 - Borgo Maggiore - Republic of San Marino > Tel: (+378) 0549 886237 > Fax: (+378) 0549 886188 > > > -- > Informativa Privacy > > Questa email ha per destinatari dei contatti presenti negli archivi di TIM > San Marino S.p.A.. Tutte le informazioni vengono trattate e tutelate nel > rispetto della normativa vigente sulla protezione dei dati personali (Reg. EU > 2016/679). Per richiedere informazioni e/o variazioni e/o la cancellazione > dei vostri dati presenti nei nostri archivi potete inviare una email a > priv...@telecomitalia.sm. > > Avviso di Riservatezza > > Il contenuto di questa e-mail e degli eventuali allegati e' strettamente > confidenziale e destinato alla/e persona/e a cui e' indirizzato. Se avete > ricevuto per errore questa e-mail, vi preghiamo di segnalarcelo > immediatamente e di cancellarla dal vostro computer. E' fatto divieto di > copiare e divulgare il contenuto di questa e-mail. Ogni utilizzo abusivo > delle informazioni qui contenute da parte di persone terze o comunque non > indicate nella presente e-mail potra' essere perseguito ai sensi di legge.
Re: migration with doveadm backup to new cluster running dovecot 2.2.36 and replicator
Hello, I had a similar problem some time ago, and the problem was the mailbox format change. Please try to migrate with the same format. Andrea Il 05/01/21 15:02, Thomas Winterstein ha scritto: > No one? > > If there are limitations in regards to how dsync in migration and > replication can operate together these should be stated clearly in the > documentation. > > On 23.12.2020 20:33, Thomas Winterstein wrote: >> Hello everyone, >> >> >> we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 >> (mdbox). The new cluster has two backend mail servers which replicate >> through doveadm replicator. To move the data initially we use doveadm >> backup (imapc). >> >> arb >> Our migration command >> doveadm -o mail_fsync=never backup -R -u $user imapc: >> >> >> To test the replication of new and purge of old mails with live data >> changes we ran imapc on a daily basis but encountered the problem >> that some mailboxes multiplied in size. We then made sure that imapc >> and replication don't run at the same time but after the first >> incremental imapc process, we still had the same problems. >> >> >> The doveadm-backup man-page states that it's possible to run it >> multiple times during migration. But is it also possible to have the >> replicator running in between? From our understanding the doveadm >> backup should just work as an imap connection between the servers, >> synchronizing all changes made on the source to the destination. Or >> does the conversion from maildir to mdbox format in our case produce >> the problems? >> >> >> If you're not supposed to run the replicator before having fully >> migrated, how can we shorten the downtime? rsync? And how can we be >> sure that similar problems don't occur after the migration if we >> can't test all mechanisms together with live data? >> >> >> thanks > > -- __ Daddy, why doesn't this magnet pick up this floppy ? __ TIM San Marino S.p.A. Andrea Gabellini Engineering R TIM San Marino S.p.A. - https://www.telecomitalia.sm Via Ventotto Luglio, 212 - Piano -2 47893 - Borgo Maggiore - Republic of San Marino Tel: (+378) 0549 886237 Fax: (+378) 0549 886188 -- Informativa Privacy Questa email ha per destinatari dei contatti presenti negli archivi di TIM San Marino S.p.A.. Tutte le informazioni vengono trattate e tutelate nel rispetto della normativa vigente sulla protezione dei dati personali (Reg. EU 2016/679). Per richiedere informazioni e/o variazioni e/o la cancellazione dei vostri dati presenti nei nostri archivi potete inviare una email a priv...@telecomitalia.sm. Avviso di Riservatezza Il contenuto di questa e-mail e degli eventuali allegati e' strettamente confidenziale e destinato alla/e persona/e a cui e' indirizzato. Se avete ricevuto per errore questa e-mail, vi preghiamo di segnalarcelo immediatamente e di cancellarla dal vostro computer. E' fatto divieto di copiare e divulgare il contenuto di questa e-mail. Ogni utilizzo abusivo delle informazioni qui contenute da parte di persone terze o comunque non indicate nella presente e-mail potra' essere perseguito ai sensi di legge.
Re: migration with doveadm backup to new cluster running dovecot 2.2.36 and replicator
No one? If there are limitations in regards to how dsync in migration and replication can operate together these should be stated clearly in the documentation. On 23.12.2020 20:33, Thomas Winterstein wrote: Hello everyone, we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 (mdbox). The new cluster has two backend mail servers which replicate through doveadm replicator. To move the data initially we use doveadm backup (imapc). arb Our migration command doveadm -o mail_fsync=never backup -R -u $user imapc: To test the replication of new and purge of old mails with live data changes we ran imapc on a daily basis but encountered the problem that some mailboxes multiplied in size. We then made sure that imapc and replication don't run at the same time but after the first incremental imapc process, we still had the same problems. The doveadm-backup man-page states that it's possible to run it multiple times during migration. But is it also possible to have the replicator running in between? From our understanding the doveadm backup should just work as an imap connection between the servers, synchronizing all changes made on the source to the destination. Or does the conversion from maildir to mdbox format in our case produce the problems? If you're not supposed to run the replicator before having fully migrated, how can we shorten the downtime? rsync? And how can we be sure that similar problems don't occur after the migration if we can't test all mechanisms together with live data? thanks -- Thomas Winterstein
migration with doveadm backup to new cluster running dovecot 2.2.36 and replicator
Hello everyone, we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 (mdbox). The new cluster has two backend mail servers which replicate through doveadm replicator. To move the data initially we use doveadm backup (imapc). Our migration command doveadm -o mail_fsync=never backup -R -u $user imapc: To test the replication of new and purge of old mails with live data changes we ran imapc on a daily basis but encountered the problem that some mailboxes multiplied in size. We then made sure that imapc and replication don't run at the same time but after the first incremental imapc process, we still had the same problems. The doveadm-backup man-page states that it's possible to run it multiple times during migration. But is it also possible to have the replicator running in between? From our understanding the doveadm backup should just work as an imap connection between the servers, synchronizing all changes made on the source to the destination. Or does the conversion from maildir to mdbox format in our case produce the problems? If you're not supposed to run the replicator before having fully migrated, how can we shorten the downtime? rsync? And how can we be sure that similar problems don't occur after the migration if we can't test all mechanisms together with live data? thanks -- Thomas Winterstein
