Where do you store your backups?

shadesofcyber

I am planning on backing up everything every 1-2 days via cronjob using the “backup_and_restore.sh” script.

Where do you guys usually store your backup? Considering the possibility of a malicious attack, it is probably not the smartest idea to just dump it somewhere on the VPS / dedicated server again.

But what other good and suitable options are there? Amazon S3 buckets?

stefan21

shadesofcyber on the VPS / dedicated server again.

I assume you’re running a dedicated mailserver?

get a cert (if you already don’t have one)
get yourself an image from your server. Can be done from time to time. I.e. netcup charges an extra fee (don’t remember the exact price, could be 1,50 Eur) for exporting. Store it somewhere safe local.
install and configure properly fail2ban for the vps. Mailcow has its own netfilter system.
use the mailcow backup script. The path to the backups can be on your vps.
create a wireguard vpn between your vps server and a local machine, which is always online. Can be i.e. a raspberry PI. Cheap while running 24/24. USB thumb is better as a sdcard out of several reasons.
plug a USB thumbdrive in this RPI
create a ssh key on the PI
on your vps server install open-ssh. Chnage the port. Configure the sshd_conf in a way, that access is allowed only via wireguard VPN and the client key. +++ NO OTHER ACCESS METHODS +++. You have to transfer in some way the key to your vps.
take special care to the iptables on the vps. Make sure you have the mailcow ports in the chain. Then you want to allow ONLY the IP from the PI via wireguard VPN. Take care of the ssh port. Everything else should be DROPPED. This ensures that mailcow will work properly and access is only allowed via your WG-VPN and ssh-key.
create a script that uses rsync to mirror the mailcow backup to your local (RPI USB thumb) drive.
create a cron job that fires your VPN up
create a cron job that runs your rsync script
create a cron job, that shuts your VPN down
create a cron job, that purges the number of backups, you don’t want to keep any longer

Works rock stable. Unattended. Does not interfere with blacklist tables (abuse IPDB) here in the forum. If you like add (a second) more blacklists like firehol and spamhouse. And your VPS is very safe. Mailcow takes care of the rest (if properly configured).

Did this in parts with help of claude.ai

So - back to the question: I store them local.

DocFraggle

I put the backups on my NAS at home

shadesofcyber

DocFraggle I read about that too, however, a NAS costs between 150-300 bucks, therefore, I am looking for a cheaper alternative…

maybl8

DocFraggle
How are you doing this?
Are you creating a fstab entry for the locatiion?
Thanks

esackbauer

Google Drive is about 20$ per year for 100GB.

shadesofcyber

esackbauer Isn’t that problematic considering the fact that I’d need to use rclone to upload my backups to Google Drive, which would let a potential attacker (in case he gains access to my VPS) see and download everything from my Google Drive?

stefan21

esackbauer Google Drive is about 20$ per year for 100GB.

Well - I don’t like the idea of sharing my emails/any data with the U.S. gov. –> US cloud act 2018. M$ and bitlocker is another violation against EU law. And so on…

If you want to keep your email (or any other data) private, stay away from any US cloud service including any M$ windows, outlook, office 365, bla, bla product. They’re all violating the DSGVO.

Sorry for beeing inconvinient. It’s my personal opinion.

esackbauer

shadesofcyber Simply use a google account only for this mailcow backup. rclone can encrypt the backup data, too.

Ganzjahresgriller

Hetzner Storagebox, 1TB / € 3,81 Month

SebS

From your reply in this thread I’d guess that my method is a bit over-the-top fpr you:

I clone the entire docker container & data to a fallback VM in a different data center every night, so that even in the very unlikely case that the main server somehow ends up “broken beyond repair” some DNS changes will get the fallback up and running.

Apart from that, backups created with the on-board script go to rented storage space in two different data centers twice a day (via sshfs).

I wouldn’t do the clone-to-different-VM-part if it was only for private use, but even my private backups involve multiple offsite-backups.

DarkMatter

I too use a local NAS that I already had. Since cost is a concern, you could use any available local device instead of a NAS, even a Raspberry PI. In the long run, using a local device might prove more cost effective ;-)

CK_beats

DarkMatter
I am an advocate of on-premise solutions. There is no data from me on any servers at any location in the global data network.
We traditionally back up the entire VM daily to a NAS system (Hornetsecurity VM Backup). Further offsite copies are regularly saved on an external storage medium, which is access-protected and stored in another location.

A large data center is more economical than your own on-premise solutions. The local machines are usually only partially utilized, which in turn causes costs per GB to be too high.
You not only have to consider operation, but also maintenance, cooling, spare parts, emergency power, “cold standby” etc.
But of course you have significant added value through independence and the actual physical availability of your own data.

disgustipated

I use the MC cold backup script to push to a local VM which only sits there as a disaster recovery. this vm is then backed up to my nas, which the nas then pushes an encrypted backup up to either google drive or backblaze. I use truenas for the nas storage which has backup jobs (which is actually rclone) where you can set the encryption of the backup at the destination you choose(like google drive or backblaze).

camillef

Backblaze is definitely the best. Very easy to configure with rclone. Only $6 per TB, or $0.006 per GB.
Much cheaper than S3, which costs $23 per TB. S3 also charges for backup extraction, but Backblaze doesn’t.

DarkMatter

The most cost effective backup storage I have found is Hetzner Storagebox, for around 2EUR/TB (the largest box) or a straight 3,20EUR for the 1TB box.

bpsintl

I have a Hetzner storage box setup with borgmatic setup in mailcow. Works like a dream

Ganzjahresgriller

@bpsintl same here

DocFraggle

maybl8 No, I’m mounting it via SSHFS before running the backup and unmount it after it’s finished. Could do this with an fstab entry as well

zx1100e1

Mailcow locally runs as a vm under proxmox. Nightly the entire vm is shutdown and incremental backup generated using proxmox backup server as the target in proxmox VE. The backup server uses nfs shares to host said backup. A bit later, the nas replicates various datasets (truenas) to a remote nas. Once a week, the local nas replicates itself to another local nas that’s normally off, and stays off once the replication is complete.

esackbauer

zx1100e1 I am doing almost the same, but currently with Hyper-V and Veeam Backup (free community edition).
However I do not shutdown the whole mailcow VM, I scripted to stop the docker service (which will gracefully shutdown the containers) while the Hyper-V snapshot is taken, so only like 30 seconds downtime.

I will move to Proxmox in the summer, and will keep Veeam backup.

zx1100e1

esackbauer I suppose that would accomplish nearly the same thing. I just worry there are some log files or something else that hasn’t been flushed to the disk. With the vm completely off this is not an issue.

Here’s the log entry from a recent backup session from pve.

160: 2026-02-25 01:04:00 INFO: Starting Backup of VM 160 (qemu) 160: 2026-02-25 01:04:00 INFO: status = running 160: 2026-02-25 01:04:00 INFO: backup mode: stop 160: 2026-02-25 01:04:00 INFO: ionice priority: 7 160: 2026-02-25 01:04:00 INFO: VM Name: mailcow 160: 2026-02-25 01:04:00 INFO: include disk 'scsi1' 'local-lvm:vm-160-disk-1' 72G 160: 2026-02-25 01:04:00 INFO: include disk 'efidisk0' 'local-lvm:vm-160-disk-0' 4M 160: 2026-02-25 01:04:00 INFO: stopping virtual guest 160: 2026-02-25 01:04:34 INFO: creating Proxmox Backup Server archive 'vm/160/2026-02-25T07:04:00Z' 160: 2026-02-25 01:04:34 INFO: starting kvm to execute backup task 160: 2026-02-25 01:04:35 INFO: started backup task 'f3739f1a-fa3e-42' 160: 2026-02-25 01:04:35 INFO: resuming VM again after 35 seconds 160: 2026-02-25 01:04:35 INFO: efidisk0: dirty-bitmap status: created new 160: 2026-02-25 01:04:35 INFO: scsi1: dirty-bitmap status: created new 160: 2026-02-25 01:04:38 INFO: 5% (3.7 GiB of 72.0 GiB) in 3s, read: 1.2 GiB/s, write: 240.2 MiB/s 160: 2026-02-25 01:04:41 INFO: 10% (7.5 GiB of 72.0 GiB) in 6s, read: 1.3 GiB/s, write: 70.7 MiB/s 160: 2026-02-25 01:04:44 INFO: 15% (11.3 GiB of 72.0 GiB) in 9s, read: 1.3 GiB/s, write: 29.3 MiB/s 160: 2026-02-25 01:04:47 INFO: 20% (15.0 GiB of 72.0 GiB) in 12s, read: 1.2 GiB/s, write: 9.3 MiB/s 160: 2026-02-25 01:04:50 INFO: 26% (19.2 GiB of 72.0 GiB) in 15s, read: 1.4 GiB/s, write: 17.3 MiB/s 160: 2026-02-25 01:04:53 INFO: 33% (24.4 GiB of 72.0 GiB) in 18s, read: 1.7 GiB/s, write: 16.0 MiB/s 160: 2026-02-25 01:04:56 INFO: 40% (29.5 GiB of 72.0 GiB) in 21s, read: 1.7 GiB/s, write: 17.3 MiB/s 160: 2026-02-25 01:04:59 INFO: 47% (34.5 GiB of 72.0 GiB) in 24s, read: 1.7 GiB/s, write: 42.7 MiB/s 160: 2026-02-25 01:05:02 INFO: 54% (39.6 GiB of 72.0 GiB) in 27s, read: 1.7 GiB/s, write: 21.3 MiB/s 160: 2026-02-25 01:05:05 INFO: 61% (44.6 GiB of 72.0 GiB) in 30s, read: 1.7 GiB/s, write: 40.0 MiB/s 160: 2026-02-25 01:05:08 INFO: 68% (49.5 GiB of 72.0 GiB) in 33s, read: 1.6 GiB/s, write: 34.7 MiB/s 160: 2026-02-25 01:05:11 INFO: 79% (57.5 GiB of 72.0 GiB) in 36s, read: 2.7 GiB/s, write: 21.3 MiB/s 160: 2026-02-25 01:05:14 INFO: 86% (62.5 GiB of 72.0 GiB) in 39s, read: 1.6 GiB/s, write: 24.0 MiB/s 160: 2026-02-25 01:05:17 INFO: 93% (67.6 GiB of 72.0 GiB) in 42s, read: 1.7 GiB/s, write: 9.3 MiB/s 160: 2026-02-25 01:05:20 INFO: 99% (71.9 GiB of 72.0 GiB) in 45s, read: 1.4 GiB/s, write: 2.7 MiB/s 160: 2026-02-25 01:05:21 INFO: 100% (72.0 GiB of 72.0 GiB) in 46s, read: 68.0 MiB/s, write: 0 B/s 160: 2026-02-25 01:05:21 INFO: backup is sparse: 14.15 GiB (19%) total zero data 160: 2026-02-25 01:05:21 INFO: backup was done incrementally, reused 70.25 GiB (97%) 160: 2026-02-25 01:05:21 INFO: transferred 72.00 GiB in 46 seconds (1.6 GiB/s) 160: 2026-02-25 01:05:21 INFO: adding notes to backup 160: 2026-02-25 01:05:21 INFO: prune older backups with retention: keep-last=90 160: 2026-02-25 01:05:21 INFO: running 'proxmox-backup-client prune' for 'vm/160' 160: 2026-02-25 01:05:21 INFO: pruned 1 backup(s) not covered by keep-retention policy 160: 2026-02-25 01:05:21 INFO: Finished Backup of VM 160 (00:01:21)

Corresponding log from proxmox backup server;
Proxmox Backup Server 3.2-7 2026-02-25T01:04:35-06:00: starting new backup on datastore 'nas1-pbe-nvme0' from ::ffff:123.123.123.123: "ns/pve1/vm/160/2026-02-25T07:04:00Z" 2026-02-25T01:04:35-06:00: download 'index.json.blob' from previous backup. 2026-02-25T01:04:35-06:00: register chunks in 'drive-efidisk0.img.fidx' from previous backup. 2026-02-25T01:04:35-06:00: download 'drive-efidisk0.img.fidx' from previous backup. 2026-02-25T01:04:35-06:00: created new fixed index 1 ("ns/pve1/vm/160/2026-02-25T07:04:00Z/drive-efidisk0.img.fidx") 2026-02-25T01:04:35-06:00: register chunks in 'drive-scsi1.img.fidx' from previous backup. 2026-02-25T01:04:35-06:00: download 'drive-scsi1.img.fidx' from previous backup. 2026-02-25T01:04:35-06:00: created new fixed index 2 ("ns/pve1/vm/160/2026-02-25T07:04:00Z/drive-scsi1.img.fidx") 2026-02-25T01:04:35-06:00: add blob "/mnt/nas1-nvme0/ns/pve1/vm/160/2026-02-25T07:04:00Z/qemu-server.conf.blob" (459 bytes, comp: 459) 2026-02-25T01:05:20-06:00: Upload statistics for 'drive-scsi1.img.fidx' 2026-02-25T01:05:20-06:00: UUID: 94db48027dfd4c28a5 2026-02-25T01:05:20-06:00: Checksum: dc630d50dfb7bcd3b81a64c0 2026-02-25T01:05:20-06:00: Size: 77309411328 2026-02-25T01:05:20-06:00: Chunk count: 18432 2026-02-25T01:05:20-06:00: Upload size: 1879048192 (2%) 2026-02-25T01:05:20-06:00: Duplicates: 17984+5 (97%) 2026-02-25T01:05:20-06:00: Compression: 13% 2026-02-25T01:05:20-06:00: successfully closed fixed index 2 2026-02-25T01:05:20-06:00: Upload statistics for 'drive-efidisk0.img.fidx' 2026-02-25T01:05:20-06:00: UUID: e029b3a2762b44afb5662a67c6e659ab 2026-02-25T01:05:20-06:00: Checksum: b4d53d9b8faf207cbd51f72d62d755719fbf9a45cd8acc6da9cf7939989cd475 2026-02-25T01:05:20-06:00: Size: 540672 2026-02-25T01:05:20-06:00: Chunk count: 1 2026-02-25T01:05:20-06:00: Upload size: 4734976 (875%) 2026-02-25T01:05:20-06:00: Duplicates: 0+1 (100%) 2026-02-25T01:05:20-06:00: Compression: 0% 2026-02-25T01:05:20-06:00: successfully closed fixed index 1 2026-02-25T01:05:20-06:00: add blob "/mnt/nas1-nvme0/ns/pve1/vm/160/2026-02-25T07:04:00Z/index.json.blob" (384 bytes, comp: 384) 2026-02-25T01:05:20-06:00: successfully finished backup 2026-02-25T01:05:20-06:00: backup finished successfully 2026-02-25T01:05:20-06:00: TASK OK

Server is down for about 34s + reboot time. So maybe a minute total before it’s ready to accept new mail. This happens early in the am during a time I expect no email at all to arrive. The scheme has been in effect since I started using MC, some 2 ½ years ago. Backend storage is a nvme for proxmox vm’s, so boot times are generally quick. I have it set to keep the last 90 days. Since these are incremental, actual disk space used is minimal