This all gives me an interesting idea. Currently, I only have one box running dovecot doing IMAP duties. For other systems where I want availability (specifically, postgres databases), I use manatee (https://github.com/joyent/manatee). I wonder if something similar would work to have dovecot instances bootstrap themselves:
- discover existing instances via whatever method. - zfs send / zfs recv a snapshot from one of the existing primaries - setup replication from one of the existing boxes. It’s perhaps not quite as straightforward as a database that already has native definitions of “primary”, “synchronous peer”, and “asynchronous peer” Is this something that people see as among the land of the possible or desired? -c > On May 29, 2020, at 10:34 PM, deano-dove...@areyes.com wrote: > > I run a pair of dovecot servers for personal small domains with several > layers of backup in place ... > > - The two dovecot servers replicate to each via a Tinc vpn mesh. That gives > email resiliency. > - All mail is replicated via offlineimap to a 3rd server over that Tinc vpn. > It's on the mesh, it has space, so why not ? > - All mail is replicated as well as via mbsync to a zfs dataset on my main > media server at home once an hour. > - That zfs dataset (and others) is snapshot'd hourly, and zfs send/recv to a > backup box nightly. > > Outside of dovecot procedures, I find mbsync to work extremely well. It was > easy enough to set up a systemd timer and service to pull the mail down. > > > mysync.timer > ============ > # Run the mbsync process to sync mail down to local mediabox > > [Unit] > Description=mbsync timer > ConditionPathExists=%h/.mbsyncrc > ConditionPathIsDirectory=/stuff/Backups/Mailsystems/mbsync-backups > > [Timer] > OnBootSec=15m > OnCalendar=hourly > Persistent=true > > [Install] > WantedBy=timers.target > > > mysync.service > ============== > # mbsync service > > [Unit] > Description=mbsync backup from mailsystems > ConditionPathExists=%h/.mbsyncrc > ConditionPathIsDirectory=/stuff/Backups/Mailsystems/mbsync-backups > > [Service] > Type=oneshot > ExecStart=/usr/local/bin/mbsync backup > > [Install] > WantedBy=default.target > > > "backup" is the mbsync group that includes all the defined channels that > determine what should be backed up. Transparent. In the background. Don't > have to think about it, it's just there. > > I've done test restores to test environments via mbsync, and it all works > flawlessly. > > > On 2020-05-26 12:31 am, Germain Le Chapelain wrote: >>> Le 24 mai 2020 à 14:42, Laura Smith <n5d9xq3ti233xiyif...@protonmail.ch> a >>> écrit : >>> Hi, >>> What are people doing for backups ? >>> My current process is LVM snapshot and backup from that to NFS share. >>> But there seems to be hints around the internet that people use/abuse >>> "doveadm backup" for backup purposes even though it seems its original >>> intention was for transferring mailboxes between dovecot instances. >>> Assuming its ok to "doveadm backup" to an NFS share, is it ok to use >>> "doveadm backup" when dovecot has replication setup (replication-notify >>> etc.) ? Or will it interfere ? >>> Thanks! >>> Laura >> This has came up in the past: >> https://dovecot.org/pipermail/dovecot/2020-February/thread.html#118206 >> I ended up developing my own system based on forwarding all emails to >> a program (from which I back-up as they come in.) >> I am hoping if disaster and/or misfortune were to strike my server, I >> could simply cat >> back all those files in order (or not come to >> think of it) in the /var/mail/<username> (or somewhere even better fit >> in Postfix.) >> I am not interested in saving the state of the mailbox as much as all >> the mails that ever come in (or go out.) > > -- > Dean Carpenter > deano is at areyes dot com > 203 six oh four 6644 -- Coy Hile coy.h...@coyhile.com
