Dieses Tutorial ist VALID.

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Haftungsausschluss / Disclaimer

Mailcow installieren – der „dockerisierte“ Mailserver

Backup

Save early, save often! (Al Lowe)

Das Backup der Mailcow funktioniert über unseren Server mittels eines Backup-Scripts.

Falls noch nicht vorhanden, legen wir uns ein Backup-Verzeichnis an (hier /var/backup):

mkdir /var/backup

Danach führen wir das Backup-Script von Mailcow aus:

BACKUP_LOCATION=/var/backup /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all

Das Script legt los und erstellt unterhalb von /var/backup/ ein Verzeichnis mit dem Namen „mailcow-“ und dem aktuellen Datum. Darin werden alle Bestandteile der Mailcow einzeln gesichert. Vor allem der „Crypt“-Key ist wichtig, weil sämtliche Mails verschlüsselt abgelegt werden. Müssen wir umziehen, brauchen wir den Schlüssel, um die Mails damit zu entschlüsseln. Dann werden noch die Inhalte der Datenbank, die Einstellungen von Postfix, Redis, RSPAMd und zu guter Letzt natürlich alle unsere Mails gepackt und gesichert.

Entweder machen wir das regelmäßig manuell, oder per CRON-Eintrag.

Restore

Müssen wir etwas aus dem Backup wiederherstellen, rufen wir das „Backup“-Script mit dem Parameter „restore“ auf. Im Folgenden werden wir dann nach dem Verzeichnis der Sicherung gefragt, welches wir eingeben. Uns werden dann die verschiedenen Sicherungen angezeigt. Aus der Liste wählen wir diejenige aus, aus der wir etwas zurücksichern möchten. Nun fragt das Script, welche der sechs möglichen Dinge wir zurücksichern möchten. Nachdem wir uns hier auch für einen Punkt entschieden haben, legt das Script los und sichert die betreffenden Daten zurück…

/opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh restore
Backup location (absolute path, starting with /): /var/backup
Using /var/backup as backup/restore location.

[ 1 ] - /var/backup/mailcow-2019-08-26-14-47-15/

Select a restore point: 1

[ 1 ] - Redis DB
[ 2 ] - Postfix data
[ 3 ] - Rspamd data
[ 4 ] - SQL DB
[ 5 ] - Crypt data
[ 6 ] - Mail directory (/var/vmail)

Select a dataset to restore: 6
Restoring vmail from /var/backup/mailcow-2019-08-26-14-47-15/...
b4d6e8ee5d45
9daef5a90da9
/vmail/
/vmail/shared-mailboxes.db
/vmail/raser.de/
/vmail/raser.de/schneller/
/vmail/raser.de/schneller/Maildir/
/vmail/raser.de/schneller/Maildir/dovecot-uidvalidity.5d63d33b
/vmail/raser.de/schneller/Maildir/dovecot.mailbox.log
/vmail/raser.de/schneller/Maildir/.Drafts/
/vmail/raser.de/schneller/Maildir/.Drafts/dovecot-uidlist
/vmail/raser.de/schneller/Maildir/.Drafts/cur/
...
/vmail/_garbage/
9daef5a90da9

In most cases it is not required to run a full resync, you can run the command printed below at any time after testing wether the restore process broke a mailbox:

docker exec 9daef5a90da9 doveadm force-resync -A '*'

Force a resync now? [y|N] y

Die Frage nach dem „Resync“ bejahen wir und kurz darauf ist der Server wieder einsatzbereit.

Update

Die Mailcow wird ungefähr im Monatsrhytmus mit Updates versorgt. Diese spielen wir auch über ein Script direkt auf dem Terminal des Servers ein.

Achtung! Bis jetzt hat das Script bei mir immer hervorragend funktioniert. Aber es kann natürlich nicht ausgeschlossen werden, dass ein Update auch mal den Server zerschießt. Bitte in jedem Fall vorher ein Backup ziehen und – noch besser – per Netcup SCP einen Snapshot des Servers machen, bevor wir das Update ausführen!

Wir wechseln ins Verzeichnis von Mailcow und starten das Script:

cd /opt/mailcow-dockerized/
./update.sh

Hier folgen wir den Anweisungen, die sich im Endeffekt auf Drücken der „y“-Taste beschränken.

Sollte es ein neues Script geben, wird das heruntergeladen und wir müssen es erneut starten. Das wird uns aber auch mitgeteilt.

Am Ende des Updateprozesses löschen wir noch die alten Container-Images (per „y“).

Nun machen wir ein

docker ps -a

und schauen, ob *alle* Container laufen: Bei „Status“ *MUSS* „up xxx Zeit“ stehen. Nur, wenn alle Container laufen, führen wir den Vorschlag des Scrips aus und säubern die Docker-Installation via

docker system prune
### mit "y" bestätigen!

Danach ist der Server wieder im normalen Betrieb. Ich lass jetzt gerne noch eine Sicherung laufen, die ja nun mit den aktuellen Updates durchgeführt wird…

Anzeige *

33 Kommentare zu „Mailcow installieren – der „dockerisierte“ Mailserver“

  1. ZITAT
    “Hostname” darf NICHT “Mailname” sein. Heißt der Mailserver “mail.xp-server.de”, dann darf der Hostname nicht genau so lauten. Hostname wäre hier z.B.: “xp-server.de”.
    ZITAT-END

    Was das für ein Schwachsinn?
    xp-server.de = Domainname!
    Und wo steht bitte das FQDN nicht Mailname sein darf?

  2. Hallo,
    ich habe noch ein Problem mit den Zertifikaten.
    Folgender Fehler im ACME Protokoll:
    mail.mydomain – Cannot validate any hostnames, skipping Let’s Encrypt for 1 hour.
    mail.mydomain – Confirmed A record with IP xx.xx.xx.xx, but HTTP validation failed
    Ich habe keine Idee warum.
    Port 80 ist freigeschaltet.

    Gruß Rolf

    1. Peter Fiedler

      Hallo Rolf,
      tut mir leid, aber den Fehler hatte ich noch nicht und kann darum keinen Tipp geben, woran das liegen könnte.
      Die Mailcow hat keine Firewall – 80 sollte auf dem Server offen sein, ja.

      Bitte mach einen Eintrag im Community Forum, da tummeln sich auch Entwickler. Die sollten Dir da kompetent weiterhelfen können.

      Beste Grüße
      Peter.

  3. Hallo,
    ich habe ein Testsystem aufgesetzt und es lief wunderbar.
    Dann habe ich ./update.sh ausgeführt.
    Nun starten die Container nicht mehr.
    Fehler beim Ausführen von docker-compose up -d
    ERROR: The Compose file ‚./docker-compose.yml‘ is invalid because:
    networks.mailcow-network.ipam.config.subnet is invalid: should use the CIDR format
    Ich habe keine Idee, was ich machen soll.
    Gruß
    Rolf

    1. Peter Fiedler

      Hallo Rolf,
      hab auf meinem Testserver auch gerade ein update.sh gefahren und da ist die Mailcow danach wieder anstandslos hochgekommen.

      Da ich an der Stelle auch nur raten kann, fragst Du am besten direkt im MailCow Forum die Community um Rat:
      https://community.mailcow.email/

      Viel Glück!
      Peter.

    2. Fehler gefunden.
      In der mailcow.conf
      IPV4_NETWORK=172.22.1
      stand dummes Zeug drin.
      Vorsicht beim unsachgemäßen editieren.

      Gruß
      Rolf

  4. Ich möchte die bisherige Installation von Mailcow unter einer anderen URL verfügbar machen, beudetet das Admin-Interface aber auch die SOGO-Instanz. Worauf sollte ich achten und wo muss ich die Anpassungen vornehmen? Der Mail-Hostname ist identisch zur bisherigen URL. Könnte das Probleme geben?

  5. Hallo,
    vielen Dank für die ausführliche Anleitung.
    Hat einer von euch es geschafft Mailcow mit in den Traefik verbund einzufädeln?
    Komme da leider nicht weiter.

    MFG

    1. Okay, habs scheinbar doch selbst geschafft.
      Nachdem ich herausgefunden habe, dass meine DB Passwörter nicht gematched haben.
      Hier meine docker.compose.overwrite.yml – https://pastebin.com/Hg13S0xP
      Zusätzlich halt in der mailcow.conf:
      HTTP_BIND=127.0.0.1
      HTTP_PORT=8080
      HTTPS_BIND=127.0.0.1
      HTTPS_PORT=8443
      SKIP_LETS_ENCRYPT=y
      Dann sollte alles so starten, dass man Mailcow mit dem hier schon vorher eingerichteten Traefik nutzen kann.

      1. Hallo Sascha,
        schön, dass Du es hinbekommen hast und vielen Dank für das Posten der Lösung :)

        Ich hab das immer sein lassen mailcow mit den anderen Diensten zu verbinden, weil die Mailserver bei mir wirklich systemkritisch sind und ich die darum tatsächlich lieber auf eigenen Maschinen hoste. Ein Ausfall würde mein Geschäft schädigen.

        In dieser Anleitung wird das Vorgehen auch beschrieben, die hat Juno damals gefunden:
        https://goneuland.de/mailcow-e-mail-komplettsytem-mit-antivirus-spam-filer-webmail-webfrontend-installieren-mittels-docker-und-traefik/#4_Anpassungen_fuer_Traefik_vornehmen

        Was mich abhält sind zwei Sachen:
        – die Möglichkeit, dass Container „überlappen“ und dann auf einmal Dienste stehen bleiben, weil die sich um die IP prügeln
        – ein Wildcard-Zertifikat für den Mailserver. Für Wildcard muss die API vom Domainanbieter mit in die Config. Und die API von netcup ist leider viel zu mächtig, als dass ich die irgendwo stehen haben will.

  6. Hi, wenn du mal Zeit hast, wäre es toll wenn du mal schauen schauen kannst, ob du eine Möglichkeit siehst, Piler oder einen ähnliches Email Archiv aufzusetzen. Am betsen natürlich in Docker und wie das funktioniert dann. :-)

    1. Da such ich selber so sehr danach, Jan…
      Das ist das Einzige, das dem Mailcow „out of the box“ fehlt – eine Archiv-Funktion.

      Piler hat ein Bekannter von mir am Laufen für seine Firma und dessen Mailarchiv. Muss ich mir doch mal ansehen…

  7. Nachdem ich jetzt mehrmals dieses tolle Tutorial durchforstet habe, habe ich nun doch eine Frage (auf die Gefahr hin, dass ich den Bereich überlesen habe):
    Woher bekomme ich den „Crypt-Key“ für das backup oder wo lege ich diesen fest?

    1. So wie ich das verstanden habe, erzeugt die Mailcow den Schlüssel selbst bei der Installation. Im Backup wird der Schlüssel mit gesichert, damit Du nachher beim Rücksichern die Mails wieder entschlüsseln kannst.
      Jedenfalls hab ich „crypt-key“ beim Backup als Verzeichnis gesehen…

      1. Hallo Peter, danke für die Antwort :-)
        Ich frage nur für den Fall der Fälle. Ich sichere mir den Server auch noch regelmäßig per Backup, aber ggf. benötige ich ja nur mal die Datensicherung.
        Diese tolle ANleitung habe ich übrigens heute einem Freund weiterempfohlen :-D
        Viele Grüße Michael

  8. Ich kam wegen meiner Traefik-Probleme – nun habe ich einen Mail-Server :D

    Deine Erklärungen passen wirklich genau zu meinem Wissenstand. Macht echt Spaß sich da durchzuarbeiten! Danke

  9. Hallo Peter !
    Vielen Dank für diese klasse Anleitung !!!

    Vor allem das Thema Backup & Restore ist sehr hilfreich …
    … sehr passend, da ich es hinbekommen habe, den Cloudspeicherplatz ( HiDrive ) so einzubinden,
    dass nach Aufruf des Backup-Scriptes, die Dateien in ein Verzeichnis gespeichert werden, welches automatisch
    mit HiDrive synchronisiert.

    Jetzt muss ich nur noch die Restore Funktion testen … ;-)
    Gäbe es hier auch die Möglichkeit – wie beim Backup – alles auf einmal wieder herzustellen ?!

    Ach ja, wie sieht es denn mit einer Archiv-Funktion aus ?

    Gruß, Martin

    1. Peter Fiedler

      Gerne, Martin.

      Der Restore funktioniert seit einem der Updates nun auch auf einen Rutsch. Da wurde die Option „All“ mit eingebaut.

      Archiv gibts wohl noch keins – zumindest hab ich noch keins gefunden.

      Beste Grüße
      Peter.

  10. Hallo, hört sich gut an… Ich habe mittlerweile mehrere Container auf deiner Basis installiert. Jetzt möchte ich gerne auch Mailcow ins Leben rufen. Klappt das? Meine Ports sind ja schon sozusagen belegt.

    Danke für deine Hilfe

    1. Nein, leider nicht.
      Die Mailcow läuft bei mir auf einer separaten Maschine. Auch die Macher der Mailcow empfehlen eine eigene Maschine dafür.

      Beste Grüße
      Peter.

        1. Peter Fiedler

          Hi Juno,
          wow, das ist pfiffig…

          Versucht hab ich es, ja. Allerdings hatte ich damals alle Änderungen direkt in der docker-compose.yml drin, die bei jedem Update überschrieben wurde. Dann hab ich es sein lassen.
          Beste Grüße
          Peter.

          1. Schade wie es ausschaut muss ich wohl doch in einen zweiten Server investieren.

          2. Peter Fiedler

            Sorry, da hab ich mich wohl falsch ausgedrückt…
            Mit der Anleitung, die Du mir geschickt hast, ist das Betreiben von mailcow und den Anwendungen auf der selben Maschine möglich. Gibt halt die beschriebenen Konflikte, falls die IP-Range schon in Gebrauch ist. Und Du hängst von einem Image ab, das die Zertifikate von Let’s Encrypt an die mailcow weiterreicht. Aber ansonsten sollte das funktionieren.

            Ich persönlich trenne gerne Mail vom Rest des Systems, nicht nur weil die Macher von der mailcow das empfehlen, sondern auch um unterschiedliche Management-Strategien zu fahren.

          3. Verstehe deine Entscheidung. Die erwähnte Anleitung ist auch sehr kurz gehalten. Über seine DNS-Config erzählt er auch nichts…

          4. Hier geb ich den Tipp den man auch in mailcow’s Anleitungen findet deine Änderungen anstelle sie in die docker-compose.yml zu schreiben, sie in die (zu erstellende Datei) docker-compose.override.yml zu schreiben. Beim Start der docker-compose.yml werden hier noch die Änderungen / überschriebenen Werte aus der docker-compose.override.yml angewendet. Vorteil ist auch bei Updates wird nichts überschrieben, weil die .override.yml nicht Teil des git-repository/des Updates ist.

          5. Danke für den Hinweis!
            Das mit den Updates ist wirklich eine gute Sache… Da bin ich offenbar drüber gestolpert, als ich die Config damals bearbeitet habe.

            Beste Grüße und ein schönes Wochenende ;)
            Peter.

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top