ok sorry for the confusion, i understand now kinda of what you are doing
at this point i am assuming the laptop is portable and offsite.
to answer the pgsql setup first :
basically when a new email comes in on a server it gets flagged in the user entry in the db explaining that a replication event needs to occur.
this is what the notify option does, when a notify event in imap happens that user gets flagged in the db entry for that user. it also tracks weather or not it is an active mailbox in the db versus an alias etc adding to the logic of what is a real mb that needs to be replicated.
this is how dopvecot knows what to push and when on the fly.
in your case without the database dsync is forced to go sequentaly one mailbox at a time because there is no quick way to know if the mailbox changed or not.
please be aware that there IS a replicator db that runs locally to both sides under the dovecot config dir but cross references with the db (at least it is for me)
however as i mentioned i have only ever used it with a pgsql database ?
and with user mailbox config's
{{{ mail_location = maildir:~/
service doveadm { process_limit = 0 process_min_avail = 0 idle_kill = 0 client_limit = 1 user = vmail inet_listener { port = 12345 } }
service config { unix_listener config { user = vmail } }
}}}
basically the above tells dovecot to make a dir for the doman under a user dir and then the users full email address
aka mine is
/data/dovecot/users/scom.ca/paul@scom.ca
again this is all handled by the database (aka user name, passowrd loctions etc etc etc)
in general i have setup scripts to support various status reporting for replication
{{{
cat /programs/common3/sync.status
doveadm replicator status echo ' ' doveadm replicator dsync-status | grep -v 'Not connected' }}}
{{{
cat /programs/common3/sync.fullstatus
doveadm replicator status '*' echo ' ' doveadm replicator dsync-status | grep -v 'Not connected' }}}
the one above give yeplication status pending
{{{
/programs/common3/sync.fullstatus | grep info
info@bedrockconstruction.ca none 01:47:05 71:24:40 02:46:22 - info@pick-a-mix.com none 00:04:09 11:22:21 00:15:22 - info@terravolt.ca none 03:28:59 03:28:59 03:28:59 - info@22automotive.ca none 00:18:59 01:54:06 00:18:59 - info@willsagriquipandfencing.ca none 01:19:48 01:28:30 01:28:30 - info@mgmpos.ca none 03:28:31 03:28:31 03:28:31 - info.send@elirpa.com none 10:57:20 10:57:20 10:57:19 - info@22racing.ca none 00:59:58 00:59:58 00:59:57 - info@elirpa.com none 01:14:58 01:38:15 01:38:15 - info@ekst.ca none 03:41:30 03:41:30 03:41:30 -
/programs/common3/sync.status
Queued 'sync' requests 0
Queued 'high' requests 0
Queued 'low' requests 0
Queued 'failed' requests 0
Queued 'full resync' requests 0
Waiting 'failed' requests 0
Total number of known users 322
username type status
}}}
in the above example the '-' means the user is in sync between both servers on THIS server. aka no replication push is needed.
This is how dovecot speeds up dsync requests as it knows what to skip.
In general if the db user entry is flagged to push emails (aka a change happend on the local servers email account)
when a replicated server (in your case your laptop i guess) when the laptop comes on line then the main server will push only mailbox changes.
and skip anything else
with all due respect the dsync / replication was not really designed to auto update a server (laptop in your case) that can go offline all the time.
it was more designed for live replication and more so recovery when the slave server went back on line.
aka server maintence,upgrades etc.
in general you could setup something that would work but if one end is portable then a vpn/static ip's etc etc would be a good recomendation.
as i mentioned (and other people have) ssh does work but will bog down on large email server replica's (like scom's) thus causing timeouts when replicating.
this was all mostly by experience on what worked for SCOM. (With much help from AKI)
without access to the main server and laptop i can not really elaborate any further as testing this kind of setup would be key to get it working.
hope this helps a bit.
Thanks - Paul Kudla (Manager SCOM.CA Internet Services Inc.)
Have A Happy Wednesday AND Happy Sucessful 2026 !
Scom.ca Internet Services <http://www.scom.ca> 104-1009 Byron Street South Whitby, Ontario - Canada L1N 4S3
Toronto 416.642.7266 Main 1.866.411.7266 Fax 1.888.892.7266 Email paul@scom.ca
On 2026-06-10 9:59 AM, Jesus Cea via dovecot wrote:
On 10/6/26 13:25, Paul Kudla via dovecot wrote:
also ssh does not work well, are you replicating on a private network connection (aka direct connection between servers on a different sub net) - i use 10.xx.xx.server1 & 10.xx.xx.server2 with a crossover cable.
I use SSH because my laptop is at home/hotel/on the go, and the server is in a datacenter thousands of kilometers away :-). Yes, I am running a local dovecot server in my laptop.
I just learned that replication is removed in 2.4. Ouch!
Thanks for your configuration, but you are not addressing the main point of my email: performance.
I am using manual replication using "doveadm sync". It works fine, but even when nothing changed, it takes 30 seconds because it compares each of my >400 mailboxes in my IMAP4 account.
I was wondering if I am missing something and that if using internal dovecot replication (dead in 2.4, but apparently solvable via the external wormhole extension) the overload would be lower.
also this is based on using mysql or postgresql databasing for auth, other auth mechs will be a crap shoot as dovecot uses a database entry to track the replication requests
Could you elaborate this?
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org