Recommendations for backing up a mailcow mail server

Looking for recommendations for using Kopia for backing up a Mailcow mail server.

Mailcow already has a backup script but it does a full backup each time so the idea of snapshots was appealing to me.

I don’t have btrfs file system on My NAS so most backup solutions use that with rsync and I can’t do that.

Well… that’s an interesting question. I also have MailCow running, let me see, if I can come up with a viable solution. I am doing VM based backups on my PVE host, but having a separate backup surely can’t hurt.

Well… that’s a bit more involved. Turns out, that the mailcow backup script created a bunch of tar archives which are zsdt compressed. I did not yet check that, but one would have to check the splitters in Kopia and see how well they handle tar archives, which are not compressed, but where the contents changes rather a lot. If the splitters can cope with that reasonably, I guess one coud tweak the backup script to not run zstd and then run a Kopia snapshot on the backup folder.

To check that out, you could run two backups on subsequent days and inflate the backup_vmail.tar.zst manually before running kopia snapshot both times and check how much data has been added to the 2nd snapshot in your Kopia repo. This way you can at least gauge, if the chosen splitter does a good enough job to determine the blocks which can be deduplicated.

On my mailcow the difference between the compressed and uncompressed backup_vmail was rather insignificant - about 100M for a 4.7G volume, but its cheap so why not? :wink:

Okayyy… so, the solution would be to have the backup_vmail.tar not being zstd compressed. Kopia’s splitter does a good job and reduced the 4.7 GB of tar’ed mails to approx. 300 MB - probably a bit less, which where actually uploaded as new data to the repo.

Maybe you can put in a RFE for the mailcow backup script to have zsdt compression as an option - this would spare you either to have unzstd the archive in a pre-snapshot action or to have to tinker with the backup script itself, which would of cause also be fine.