Kevo Because it’s a production instance and ensuring 100% data reliability is of utmost importance. There is a possibility some data in memory may be lost/not written to the disk resulting in database corruption or inconsistency. Using ‘stop’ mode in the proxmox backup config takes the server down for less than 2 minutes to shutdown/restart and perform the backup (not in that order).
Also, to clarify, there’s actually 2 MC instances involved.
Instance A is the primary and has lowest mx priorioty numerical value. This is on the vps and acts as a relay to instance B. General config is typically unchanged. The only reasons for reboot is vps maintenance, or update (OS or MC). The bulk of the temp bans reside here.
Instance B is the relay target for instance A. It’s a proxmox vm which also houses the mailboxes and mailstores. This one is backed up nightly and before/after updates. There’s few if any temp bans here, but its port 25 is also opened and it’s a secondary mx target in terms of numerical priority. There’s also a significant firewall in front of it with multiple ip blocklists defined (updated x amount of times/day).
I think @ETNyx is on to something with the cronjob. I can save the output to a file in /tmp during uptime operation. At reboot this would be saved to the disk and restored accordingly. What im unclear on is what happens to the timers since this list is cleared at reboot.
Giving more outside the box thought, I think the best approach is to extract the data from the redis database itself at shutdown, restore at boot. According to AI, the rest will be taken care of as far as restoring expiry TTL and purging.