Current thinking on backups ?

[Coy Hile]

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 at 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 at 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 at coyhile.com