Backup für mailcow — Anleitung

Installation

Das Modul steckt im mailcow Toolkit 0.7.0 oder neuer (ein Paket, eine Lizenz pro Produkt). Führe auf dem mailcow-Host als root den Toolkit-Installer wie gewohnt aus: sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized --name <instance>, oder aktualisiere das Toolkit unter System → Updates (Toolkit). Der Installer kopiert data/web/mlw-backup/, installiert das Host-Skript /usr/local/sbin/mlw-mailcow-backup-<instance> und legt die Verlaufstabelle sowie den Timer mlw-mailcow-backup-<instance>.timer an (alle 5 Minuten prüft er, ob ein Backup fällig ist).
Installiere GnuPG auf dem Host, falls es fehlt: apt install gnupg.
Öffne System → Backup im mailcow-Adminmenü.

Lizenz

Öffne System → Updates (Toolkit) und such die Karte Backup for mailcow: Schlüssel einfügen und aktivieren oder den 30-tägigen Test starten. Auf der Shell: php /web/mlw-toolkit/cli.php activate mailcow-backup <KEY> in php-fpm-mailcow.

Ohne gültige Lizenz stoppen die geplanten Backups und die Uploads zu Google Drive. Prüfen, Wiederherstellen und Löschen funktionieren weiter, du bekommst deine Daten also immer zurück.

Erste Einrichtung

Settings → Local folder: ein absoluter Pfad auf dem Host, idealerweise auf einer anderen Festplatte als mailcow (zum Beispiel /srv/backup/mailcow oder eine eingehängte Festplatte). Er wird nur für root lesbar angelegt. Lass Platz für etwa zwei Backups.
Encryption: Klick auf Set mit generated (recommended): Die Passphrase wird einmal angezeigt — bewahre sie außerhalb des Servers auf (Passwortmanager, Papier). Oder wähl my own und gib zweimal eine mit mindestens 12 Zeichen ein.
Back up now in der Status-Karte erstellt das erste Backup; Fortschritt und Log werden live angezeigt.

Zeitplan, Komponenten und Aufbewahrung

Unter Settings:

Scheduled backups ein oder aus; Times (Serverzeit, mehrere erlaubt, z. B. 03:15, 15:15) und Days.
What is backed up: Mails (vmail), Verschlüsselungsschlüssel (crypt — nötig, um verschlüsselte Mails zu lesen), redis, rspamd, postfix, Datenbank (SQL). Standardmäßig sind alle eingeschaltet.
Local copies kept und Copies kept on Drive: Die neuesten N bleiben; ältere werden nach jedem Backup gelöscht.
Compression threads für mailcows Skript.
E-mail: nur bei Fehlern (Standard), nach jedem Backup oder nie; leere Adresse = die Benachrichtigungsadresse des Toolkits.

Ein Backup, das verpasst wurde, während der Server aus war, läuft einmal nach, sobald er wieder da ist. Geplante Backups laufen mit niedriger CPU- und Festplattenpriorität.

Was ein Backup ist

mailcows eigenes backup_and_restore.sh schreibt die gewählten Komponenten; das Modul packt sie in ein einziges Archiv und verschlüsselt es mit GnuPG (AES-256, mit Integritätsschutz) unter deiner Passphrase:

Datei	Inhalt
`mailcow-<host>-<date>.tar.gpg`	das verschlüsselte Archiv (mailcows `backup_*.tar.zst`-Dateien und seine `mailcow.conf`)
`mailcow-<host>-<date>.json`	das Manifest: Komponenten und Größen, SHA-256 des Archivs, Passphrase-ID, mailcow- und Toolkit-Versionen

Ohne mailcow: gpg -d mailcow-…tar.gpg > backup.tar fragt nach der Passphrase und gibt mailcows gewohnten Backup-Ordner zurück.

Google Drive

Das Modul nutzt deinen eigenen Google-OAuth-Client, damit der Zugriff auf dein Drive auf deinem Server bleibt:

Leg in der Google Cloud Console ein Projekt an (oder wähl eines aus) und aktiviere die Google Drive API.
OAuth consent screen: Typ External, deine E-Mail-Adresse als Support- und Entwicklerkontakt; dann Publish app („In production“). Im Testmodus lässt Google den Zugriff nach 7 Tagen ablaufen.
Credentials → Create credentials → OAuth client ID, Typ Web application, mit der Weiterleitungs-URI, die auf der Seite angezeigt wird: https://<your mailcow UI host>/mlw-backup/oauth.php.
Füg Client ID und client secret auf der Seite unter Google Drive ein, klick auf Save, dann auf Connect Google Drive und erlaube den Zugriff. Google warnt eventuell, dass die App nicht verifiziert ist: Es ist deine eigene App, mach weiter.
Schalte unter Settings die Option Upload every backup to Google Drive ein und wähl den Ordnernamen.

Der Scope ist drive.file: Das Modul sieht nur die Dateien, die es selbst angelegt hat, nie den Rest deines Drive. Uploads laufen in Teilen zu 32 MiB und gehen nach einem Netzwerkfehler weiter. Test listet den Ordner auf; Disconnect widerruft den Zugriff (die Backups bleiben auf Drive).

Prüfen und wiederherstellen

Unter Backups zeigt jedes Backup, wo es liegt (lokal, Drive oder beides):

Verify: entschlüsselt und liest das ganze Archiv (von Drive heruntergeladen, wenn es nicht lokal liegt), ohne etwas wiederherzustellen.
Restore…: Komponenten ankreuzen, RESTORE eintippen, bestätigen. Die SHA-256 des Archivs wird gegen sein Manifest geprüft, es wird entschlüsselt und seine Pfade werden geprüft, dann wird jede Komponente mit den Schritten von mailcows eigener Wiederherstellung zurückgespielt: Die betroffenen Container werden gestoppt und wieder gestartet; die Datenbank stoppt den ganzen mailcow für ein paar Minuten und übernimmt die SQL-Zugangsdaten aus der mailcow.conf des Backups. Was sich in diesen Komponenten nach dem Datum des Backups geändert hat, geht verloren. Es wird kein erzwungener Mail-Resync ausgeführt; wirkt ein Postfach danach falsch: docker exec $(docker ps -qf name=dovecot-mailcow) doveadm force-resync -A '*'.
Delete: entfernt das Backup lokal und von Drive.

Ein neuer Server

Installiere mailcow und das Toolkit, aktiviere die Lizenz (oder stell ohne Lizenz wieder her).
Encryption → my own: Gib die alte Passphrase ein (auf einem Server, der schon eine hat, kreuz for older backups only an).
Google Drive: Verwende denselben Google-OAuth-Client und verbinde ihn; die alten Backups erscheinen (das Modul sieht die Dateien, die sein Client angelegt hat).
Restore… für das neueste Backup, alle Komponenten.

Shell und Dateien

Das Host-Skript lässt sich von Hand ausführen (als root): MLW_TK_CONF=/etc/mlw-mailcow-toolkit/<instance>.conf mlw-mailcow-backup-<instance> backup|verify NAME|list. Der Fortschritt steht in data/hooks/phpfpm/.mlw-toolkit/backup/run.json und run.log, der Verlauf in der Tabelle mlw_bk_run von mailcows Datenbank. uninstall.sh behält die lokalen Backups und die auf Drive.