Verschlüsselte mailcow-Backups auf Google Drive: Aufbewahrung, Prüfung und Wiederherstellung

mailcow bringt ein solides Backup-Skript mit, aber es ist ein Befehl, den du von Hand ausführst. Nichts plant es ein, nichts verschlüsselt es, nichts kopiert es vom Server weg, und eine Wiederherstellung bedeutet, seine Fragen auf der Shell zu beantworten. Das funktioniert – bis zu dem Tag, an dem du es wirklich brauchst, meist im ungünstigsten Moment.

Dieses Tutorial zeigt, wie du aus diesem Skript einen Dienst machst, den du einmal unter System → Backup konfigurierst: geplante Läufe mit mailcows eigenem backup_and_restore.sh, GnuPG-Verschlüsselung (AES-256, mit Integritätsschutz), bevor irgendetwas die Platte berührt, eine lokale Kopie plus optional eine Kopie auf Google Drive, Prüfung ohne Wiederherstellen und Wiederherstellung je Komponente aus der Seite. Das Produkt ist Backup für mailcow; die vollständige Referenz findest du im Benutzerhandbuch.

Bevor du loslegst

mailcow-dockerized unter Linux mit docker compose und systemd.
Das mailcow Toolkit 0.7.0 oder neuer von MediaLab Works – dieses Modul ist eines seiner Produkte mit eigener Lizenz.
Root-Zugriff auf dem Host, um den Toolkit-Installer auszuführen, und ausgehendes HTTPS zu medialab.works für die Lizenzprüfung.
GnuPG auf dem Host. Falls es fehlt: apt install gnupg.
Freier Speicherplatz im lokalen Ordner für etwa zwei Backups – eines wird erstellt, während die bisherigen behalten werden.
Optional, für Google Drive: ein Google-Konto und ein eigener OAuth-Client in Google Cloud.

Schritt 1 — Modul installieren

Führe auf dem mailcow-Host als root den Toolkit-Installer wie gewohnt aus:

sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized --name <instance>

Ist das Toolkit bereits installiert, aktualisiere es stattdessen über System → Updates (Toolkit). Der Installer kopiert data/web/mlw-backup/, installiert das Host-Skript /usr/local/sbin/mlw-mailcow-backup-<instance>, legt die Verlaufstabelle an und installiert den Timer mlw-mailcow-backup-<instance>.timer, der alle 5 Minuten prüft, ob ein Backup fällig ist. Danach öffnest du im mailcow-Adminmenü System → Backup.

Schritt 2 — Lizenz aktivieren

Öffne System → Updates (Toolkit) und suche die Karte Backup für mailcow: Schlüssel einfügen und aktivieren oder die 30-Tage-Testversion starten. Auf der Shell geht dasselbe mit php /web/mlw-toolkit/cli.php activate mailcow-backup <KEY> innerhalb von php-fpm-mailcow.

Gut zu wissen: Ohne gültige Lizenz stoppen die geplanten Backups und die Google-Drive-Uploads, aber Prüfen, Wiederherstellen und Löschen funktionieren weiter. Deine Daten werden nie als Geisel gehalten.

Schritt 3 — Lokalen Ordner wählen

Gib unter Einstellungen → Lokaler Ordner einen absoluten Pfad auf dem Host ein, idealerweise auf einer anderen Platte als mailcow – zum Beispiel /srv/backup/mailcow oder eine eingebundene Platte. Der Ordner wird nur für root lesbar angelegt. Lass Platz für etwa zwei Backups.

Schritt 4 — Verschlüsselungs-Passphrase setzen

Drücke unter Verschlüsselung auf Setzen mit generiert (empfohlen). Die Passphrase wird einmal angezeigt: Bewahre sie außerhalb des Servers auf, in einem Passwortmanager oder auf Papier. Oder wähle eigene und tippe eine mit mindestens 12 Zeichen zweimal ein.

Jedes Backup wird eine .tar.gpg-Datei plus ein JSON-Manifest (Komponenten, Größen, SHA-256, Passphrase-ID, mailcow- und Toolkit-Versionen). Es lässt sich auch mit einfachem gpg ohne mailcow entschlüsseln: gpg -d mailcow-…tar.gpg > backup.tar fragt nach der Passphrase und gibt mailcows gewohnten Backup-Ordner zurück.

Schritt 5 — Zeitplan, Komponenten und Aufbewahrung

Weiterhin unter Einstellungen:

Geplante Backups an oder aus, mit Zeiten in Serverzeit (mehrere erlaubt, z. B. 03:15, 15:15) und Tagen. Ein Backup, das verpasst wurde, während der Server aus war, läuft einmal nach, sobald er wieder da ist, und geplante Läufe nutzen eine niedrige CPU- und Plattenpriorität.
Was gesichert wird: Mail (vmail), Verschlüsselungsschlüssel (crypt – nötig, um verschlüsselte Mail zu lesen), redis, rspamd, postfix und die Datenbank (SQL). Alle sind standardmäßig an; wähle, was du brauchst.
Lokal behaltene Kopien und Auf Drive behaltene Kopien: Die neuesten N bleiben, ältere werden nach jedem Backup gelöscht.
Kompressionsthreads für mailcows Skript.
E-Mail: nur bei Fehler (Standard), nach jedem Backup oder nie. Eine leere Adresse bedeutet die Benachrichtigungsadresse des Toolkits.

Drücke in der Status-Karte auf Jetzt sichern, um das erste Backup zu erstellen; Fortschritt und Log werden live angezeigt.

Schritt 6 — Google Drive hinzufügen (optional)

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

Erstelle in der Google Cloud Console ein Projekt oder wähle eines aus und aktiviere die Google Drive API.
OAuth consent screen: Typ Extern, deine E-Mail als Support- und Entwicklerkontakt, dann App veröffentlichen ("In Produktion"). Im Testmodus lässt Google den Zugriff nach 7 Tagen ablaufen.
Credentials → Create credentials → OAuth client ID, Typ Webanwendung, mit der auf der Seite angezeigten Redirect-URI: https://<your mailcow UI host>/mlw-backup/oauth.php.
Füge Client-ID und Client-Secret unter Google Drive auf der Seite ein, Speichern, dann Google Drive verbinden und den Zugriff erlauben. Google warnt eventuell, dass die App nicht verifiziert ist – es ist deine eigene App, fahre fort.
Schalte unter Einstellungen Jedes Backup zu Google Drive hochladen ein und wähle den Ordnernamen.

Der Scope ist drive.file: Das Modul sieht nur die Dateien, die es selbst erstellt hat, nie den Rest deines Drive. Uploads laufen in 32-MiB-Teilen und werden nach einem Netzwerkfehler fortgesetzt. Test listet den Ordner auf; Trennen widerruft den Zugriff, und die Backups bleiben auf Drive.

Schritt 7 — Prüfen ohne Wiederherstellen

Unter Backups zeigt jedes Backup, wo es liegt (lokal, Drive oder beides). Prüfen entschlüsselt und liest das gesamte Archiv – bei Bedarf wird es von Drive heruntergeladen –, ohne etwas wiederherzustellen. Führe es nach dem ersten Backup und dann regelmäßig aus: Es ist der günstigste Weg, um festzustellen, dass eine Passphrase oder ein Upload schiefgelaufen ist.

Schritt 8 — Je Komponente wiederherstellen

Mit Wiederherstellen… hakst du die benötigten Komponenten ab, tippst RESTORE und bestätigst. Der 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 das gesamte mailcow für einige Minuten und übernimmt die SQL-Zugangsdaten aus der mailcow.conf des Backups. Was sich in diesen Komponenten nach dem Backup-Datum geändert hat, geht verloren. Es wird kein erzwungener Mail-Resync ausgeführt; sieht ein Postfach danach falsch aus:

docker exec $(docker ps -qf name=dovecot-mailcow) doveadm force-resync -A '*'

Umzug auf einen neuen Server

Installiere mailcow und das Toolkit und aktiviere dann die Lizenz (oder stelle ohne Lizenz wieder her).
Verschlüsselung → eigene: Tippe die alte Passphrase ein. Auf einem Server, der bereits eine hat, hake nur für ältere Backups an – eine neue Passphrase gilt für die nächsten Backups, und ältere bleiben wiederherstellbar.
Google Drive: Nutze denselben OAuth-Client und verbinde; die alten Backups erscheinen, weil das Modul die Dateien sieht, die sein Client erstellt hat.
Wiederherstellen… des neuesten Backups, alle Komponenten.

Tipps und Fehlerbehebung

Halte die Passphrase vom Server fern. Ohne sie lässt sich ein Backup auf einem anderen Server nicht wiederherstellen. Die eigenen Secrets des Moduls (Passphrase, Google-Zugriff) überstehen eine Wiederherstellung von redis, aber ein verlorener Server nimmt sie mit.
Datenschutz: Backups enthalten deine gesamte Mail. Sie verlassen den Server nur verschlüsselt und nur zum Google-Drive-Konto, das du verbindest; an medialab.works geht außer der Lizenzprüfung nichts.
Google lässt Apps im Testmodus nach 7 Tagen ablaufen – veröffentliche die App wie oben beschrieben.
Verlauf und Logs prüfen: Der vollständige Verlauf von Backups, Uploads, Prüfungen und Wiederherstellungen steht auf der Seite und in der Tabelle mlw_bk_run; der Live-Fortschritt liegt in data/hooks/phpfpm/.mlw-toolkit/backup/run.json und run.log.
Von Hand, als root: MLW_TK_CONF=/etc/mlw-mailcow-toolkit/<instance>.conf mlw-mailcow-backup-<instance> backup|verify NAME|list.
Deinstallieren mit uninstall.sh behält die lokalen Backups und die auf Drive.

Zum Schluss

Lege Ordner und Passphrase einmal fest, wähle Zeiten und Aufbewahrung, verbinde Drive, wenn du eine Off-Site-Kopie willst, und lass den Timer den Rest erledigen. Prüfe ab und zu, und wenn du eine Wiederherstellung brauchst, hakst du Komponenten auf einer Seite ab, statt Fragen auf einer Shell zu beantworten. Mehr im Benutzerhandbuch und im Changelog; Fragen sind willkommen über Kontakt oder die Wissensdatenbank.

Dieser Beitrag wurde mit KI-Unterstützung auf Grundlage unserer Produktdokumentation oder der aufgeführten Quellen verfasst und vor der Veröffentlichung automatisch geprüft.