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-dovecot@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 n5d9xq3ti233xiyif2vp@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.hile@coyhile.com