Backups and disaster recovery

[Shawn Heisey]

On 12/3/22 16:02, GDS wrote:
> After reading some of the past threads on backups, I was wondering if 
> I could get a sanity check... I run a Maildir configuration for a 
> small (10 mailboxes) mail server. Using "/doveadm backup"/, for each 
> mailbox I do:
>
> - Weekly full backups and then copy the files to a network-based 
> filesystem.
> - Daily incremental backups and then copy the files to a network-based 
> filesystem.
>
> My recovery assumption is that in case of hardware failure, I would 
> re-set up the mail service and for each mailbox I will recover at the 
> right directory the latest full mailbox backup and on top of it, each 
> incremental backup to the latest day.  Does this sound like a sound 
> strategy?
>
> Also, I was thinking of setting up a second dovecot server on another 
> server and replicating my primary on an hourly basis to decrease 
> recovery time.  But I looked at mbsync and it seems to require mailbox 
> login/password for each mailbox (which I don't have). Is there an 
> alternative?

At 07:00 every day, my mailserver rsyncs its entire root filesystem to 
another server with a large btrfs filesystem.  All the mail is on that 
filesystem.  I am using Maildir, not sure how to figure out whether that 
is Maildir++ or not:

00 7 * * * rsync -axH --delete --delete-excluded --exclude=.git / 
server.domain.tld:/storage0/bilbofull/

The target server has a snapshot maintenance script I wrote that runs 
every night, as well as weekly and monthly:

45 23 * * * /usr/local/sbin/snapshot-maintenance storage0 daily
50 23 1 * * /usr/local/sbin/snapshot-maintenance storage0 monthly
55 23 * * 7 /usr/local/sbin/snapshot-maintenance storage0 weekly

The script keeps 7 daily snaps, 4 weekly snaps, and 6 monthly snaps.   I 
deleted all the snapshots recently because I was doing significant 
maintenance on the filesystem and wanted to actually recover the disk 
space.  This shows the snaps that currently exist:

elyograg at smeagol:/usr/local/sbin$ sudo btrfs subvolume list /storage0
ID 68160 gen 711353 top level 5 path .snapshot/2022.11.01.storage0.monthly
ID 68163 gen 718255 top level 5 path .snapshot/2022.11.06.storage0.weekly
ID 68170 gen 729261 top level 5 path .snapshot/2022.11.13.storage0.weekly
ID 68177 gen 746501 top level 5 path .snapshot/2022.11.20.storage0.weekly
ID 68181 gen 756805 top level 5 path .snapshot/2022.11.24.storage0.daily
ID 68182 gen 759352 top level 5 path .snapshot/2022.11.25.storage0.daily
ID 68183 gen 761844 top level 5 path .snapshot/2022.11.26.storage0.daily
ID 68184 gen 779474 top level 5 path qemu
ID 68185 gen 764384 top level 5 path .snapshot/2022.11.27.storage0.weekly
ID 68186 gen 766942 top level 5 path .snapshot/2022.11.28.storage0.daily
ID 68187 gen 769388 top level 5 path .snapshot/2022.11.29.storage0.daily
ID 68188 gen 771998 top level 5 path .snapshot/2022.11.30.storage0.daily
ID 68189 gen 774588 top level 5 path .snapshot/2022.12.01.storage0.monthly
ID 68190 gen 777168 top level 5 path .snapshot/2022.12.02.storage0.daily

The end result of this is that I have backups of all the email at many 
different points in time.  I back up a lot of other things into the 
btrfs filesystem as well.

elyograg at smeagol:~$ df -h /storage0
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        22T  3.5T   19T  17% /storage0

elyograg at smeagol:~$ sudo du -hs /storage0/bilbofull/var/vmail
6.5G    /storage0/bilbofull/var/vmail

I also have 10 mailboxes across several domains.  There are more than 10 
defined, but only 10 of them actually have email.  The users are in a 
postfixadmin database.

You should be able to use rsync to copy Maildirs from one server to 
another.  That is IMHO one of the advantages to Maildir ... each change 
to the mailbox occurs with a single message file, so it is unlikely the 
mailbox will be corrupted if it changes during the copy.

Thanks,
Shawn