Update schief gegangen, wie mails wiederherstellen?

Pete

Hi,

ich wollte heute wieder ein update von meiner mailcow anstoßen, also wie üblich update.sh ausgeführt. Mailcow ist nach dem Update allerdings nicht mehr hochgekommen, gab nur folgende Fehlermeldung:
ERROR: Configuration for volume vmail-vol-1 specifies "device" driver_opt :/data/docker_vol/vmail-vol-1, but a volume with the same name uses a different "device" driver_opt (:/data/docker_vol/vmail-vol). If you wish to use the new configuration, please remove the existing volume "mailcowdockerized_vmail-vol-1" first: $ docker volume rm mailcowdockerized_vmail-vol-1
Ich habe daraufhin in die docker-compose.yml geschaut und gesehen, dass hier meine Mount-Options für vmail-vol-1 weg waren (ich habe das auf einem NFS-volume liegen). Also die Mount-options wieder eingefügt und erneut versucht zu starten. Gab allerdings immer wieder die gleiche Fehlermeldung. Somit bin ich auf die glorreiche Idee gekommen, das angemeckerte Volume aus Docker zu löschen(liegt ja eh auf NFS). Jetzt gab es folgende Fehlermeldung:
ERROR: Configuration for volume vmail-attachments-vol-1 specifies "device" driver_opt :/data/docker_vol/vmail-attachments-vol-1, but a volume with the same name uses a different "device" driver_opt (:/data/docker_vol/vmail-attachments-vol). If you wish to use the new configuration, please remove the existing volume "mailcowdockerized_vmail-attachments-vol-1" first: $ docker volume rm mailcowdockerized_vmail-attachments-vol-1
Anstatt jetzt auch nur dieses Volume (welches ebenfalls auf NFS liegt) zu entfernen, habe ich alle ungenutzen Volumes in Docker entfernt. Mailcow ist jetzt zwar hochgefahren, allerdings natürlich in einem fresh install-Status… was natürlich klar ist, wenn man alle persistenten Volumes löscht, auf denen auch die Konfiguration und Datenbanken liegen. Ich gehe mal davon aus, diese Volumes bekomme ich nicht zurück und darf mir mailcow neu konfigurieren -> Gerechte Strafe (?), weil nicht richtig nachgedacht, lessons learned.

ABER: Wie bekomme ich jetzt meine alten Mails wieder sauber rein?

Pete

Kleine Ergänzung, mir ist gerade aufgefallen, dass ich mit den Mounts auch schlicht Blödsinn gemacht habe… nachdem das Uppdate-script durchgelaufen war und mailcow nicht hochgekommen ist, habe ich in der docker-compose.yml gesehen, dass die NFS-optionen weg waren. Ich habe diese dann einfach c+p aus einem alten Backup eingefügt, dabei aber nicht drauf geachtet, dass der Pfad etwas anders ist (vol-1 anstatt wie aktuell richtig nur vol).
Die Frage bleibt aber dennoch: Wie bekomme ich jetzt meine alten Mails in Mailcow wieder rein?

Pete

Habe jetzt das Volume mal “normal” eingebunden, mailcow gestartet und angefangen die Domains und Mailboxen in mailcow wieder anzulegen. Mein IMAP-Client funktioniert, ich kann auch wieder mails senden und empfangen, allerdings ist mir ein Problem in SoGO aufgefallen: Alle mails werden “leer” angezeigt, sprich ich sehe weder Absender, noch inhalt noch sonstwas von den Mails, nur die Anzahl an Mails. In der Mailcow-Konfiguration sehe ich bei den Mailboxen auch eine falsche Anzahl an Mails und Mailstore-usage, an Mails werden mir dort nur die Anzahl angezeigt, welche ich als Probemails hin un her geschickt habe um zu testen, ob Mailempfang wieder funktioniert. In den Logs von dovecot finde ich jetzt folgendes:
12.10.2020, 14:50:38 err indexer-worker(pa@aXXXXXXXXXXXe)<1287><g2LHvnix285Xt0N+:Yg8SJB5RhF8HBQAASLpKFw>: Error: Mailbox Trash: Transaction commit failed: FTS transaction commit failed: transaction context (attempted to index 1 messages (UIDs 1..1)) 12.10.2020, 14:50:38 err indexer-worker(pa@aXXXXXXXXXXXe)<1287><g2LHvnix285Xt0N+:Yg8SJB5RhF8HBQAASLpKFw>: Error: Mailbox Trash: Mail search failed: Internal error occurred. Refer to server log for more information. [2020-10-12 14:50:38] 12.10.2020, 14:50:38 err indexer-worker(pa@aXXXXXXXXXXXe)<1287><g2LHvnix285Xt0N+:Yg8SJB5RhF8HBQAASLpKFw>: Error: Failed to read mailbox Trash mail UID=1 stream: Mailbox Trash: UID=1: read() failed: read(/var/vmail/aXXXXXXXXXe/pa/Maildir/.Trash/cur/1589994796.M513796P2489.mail.aXXXXXXXXXXXe,S=21624,W=21996:2,S) failed: Decryption error: no private key available (read reason=fts indexing) 12.10.2020, 14:50:38 err indexer-worker(pa@aXXXXXXXXXXXe)<1287><g2LHvnix285Xt0N+:Yg8SJB5RhF8HBQAASLpKFw>: Error: Mailbox Trash: UID=1: read() failed: read(/var/vmail/aXXXXXXXXXXXe/pa/Maildir/.Trash/cur/1589994796.M513796P2489.mail.aXXXXXXXXXXXe,S=21624,W=21996:2,S) failed: Decryption error: no private key available (read reason=fts indexing) 12.10.2020, 14:50:38 err indexer-worker(pa@aXXXXXXXXXXXe)<1287><g2LHvnix285Xt0N+:Yg8SJB5RhF8HBQAASLpKFw>: Error: Mailbox Trash: UID=1: read() failed: read(/var/vmail/aXXXXXXXXXXXe/pa/Maildir/.Trash/cur/1589994796.M513796P2489.mail.aXXXXXXXXXXXe,S=21624,W=21996:2,S) failed: Decryption error: no private key available (read reason=prefetch)

Die Decryption-errors machen mir sorgen. Soll das heissen, alle meine Mails sind verschlüsselt mit einem Schlüssel, der jetzt weg ist?

Pete

Ich habe jetzt mehrfach versucht meine Mails zu importieren, habe dazu etwas gegoogelt und bin auf folgende Threads gestoßen:
https://github.com/mailcow/mailcow-dockerized/issues/2395
https://community.mailcow.email/d/238-sogo-ladt-die-e-mail-ansicht-bei-einem-user-nicht-mehr
https://github.com/mailcow/mailcow-dockerized/issues/516

Die dort stellenweise beschriebenen Lösungsansätze haben nicht funktioniert. Auch mit dem decrypt-script von https://mailcow.github.io/mailcow-dockerized-docs/u_e-dovecot-mail-crypt/ bin ich nicht weiter gekommen, es fehlt immer der private key. Auch habe ich festgestellt, sobald ich meine alten Mails in Mailcow reinschiebe, kann ich weder Mails empfangen noch senden. Ich habe jetzt erstmal Mailcow frisch neu aufgesetzt, damit ich überhaupt wieder mails empfangen kann. Das alte Maildir habe ich noch auf meinem NFS-server und bin für jeden Tip dankbar, wie ich diese wieder reinbekommen kann.

Pete

Gibt es hier wirklich niemanden, der in der Situation war, wo er ein Maildir wiederherstellen musste, ohne die mail_crypt-keys der vorherigen Installation zu haben? Ich würde sehr ungern meine Mails der letzten 9 Jahre abschreiben…

diekuh

Hi,

du brauchst unbedingt den Key der “alten” Installation. Also das crypt-vol-1. Ich kann mir nicht so richtig vorstellen, dass du das gelöscht hast. Beim Update würde er das Volume nie löschen, in deiner History des Posts sehe ich auch nicht, dass du crypt-vol-1 gelöscht hättest.

Hast du mal die Datei auf dem FS gesucht?

Pete

Ich habe leider ALLE volumes gelöscht, nachdem ich 2x hintereinander die o.g. Fehlermeldungen beim update bekommen habe. Zu ungeduldig gewesen, nicht nachgedacht… wenn ich Dich also richtig verstehe: Keine Keys, keine Kekse, sprich ich habe von meinen alten Mails nur noch Datenmüll… mehr als ärgerlich, aber kein Weltuntergang.

Bzgl. des updates wundert es mich allerdings, warum das script meine volume-parameter verändert hatte. Das war bei den ganzen letzten Updates nie ein Problem.

diekuh

Hast du denn direkt in der docker-compose.yml Dinge geändert? Oder wie empfohlen in der docker-compose.override.yml?

kuhtreiber

diekuh

Denke, die override ist für solche Anwendungen nur bedingt geeignet, denn man kann mit dem System nur Objekte hinzufügen, aber nichts weg lassen. Oder ich hab einen massiven Denkfehler. Die Einträge in der Sektion “volumes:” müssten raus, weil die volumes sonst trotzdem erstellt werden, auch wenn sie danach ungenutzt sind. Da bleibt nur, die docker-compose.yml zu editieren.
Siehe: docker/compose3729

Pete

Ich habe direkt in der docker-compose.yml Änderungen drin gehabt, das mit der docker-compose.override.yml war mir nicht bewusst.

diekuh

Oh, okay. In der override bleibt alles brav bestehen. 🙂

Pete

Vielleicht ein kleiner Improvement-Vorschlag: Wenn beim Update die docker-compose.yml geändert wird, kurze Warnung ausgeben “Du hast eine geänderte docker-compose.yml, die Änderungen gehen gleich verloren”, als Bonbon vielleicht noch mit einem diff der Änderungen… ähnlich, wie man das von Debian-Systemen kennt. Das würde dann vielleicht Leute wie mich vor solchen Grandiosen Ideen bewahren… 😉

diekuh

Es wird ein Commit erstellt mit “before update on blabla”, falls dir das hilft. 🙂

Pete

Naja, ich hab jetzt mein Lehrgeld bezahlt und werde zukünftig anders mit der Installation umgehen… sprich Änderungen nur in der docker-compose.override.yml und für Backup das backup-helper-script nutzen, anstatt mich einfach nur auf snapshots auf meinem NFS-filer zu verlassen… Aber vielleicht hilft das anderen “Grandiose Ideen” zu überdenken…

diekuh

Passiert leider. 🙁 Tut mir leid, dass die Mails futsch sind.

kuhtreiber

Hi Pete. Bin auf Deinen Post gestoßen, weil ich gerade mailcow einrichte und tatsächlich genau wissen will, wo meine Nutzdaten liegen. Meiner Meinung nach ist es ein Schwäche in der Anwendung von docker, sich auf die internen Mechanismen zu verlassen und persistente Daten unter /var/lib/docker/ zu speichern. In komplexen Installationen macht man bei der Wartung schnell mal eben ein ‘prune’ und die eigentlich gewünschten Nutzdaten sind futsch, weil ein Container gerade während des Update fehlt. Aus diesem Grunde mounte ich immer meine persistenten Daten in eigene Verzeichnisse, die jeden prune überstehen. Unter /var liegt so nur das, was das Image selbst jederzeit wieder erstellen kann. Aber das ist eine Frage des Geschmacks und der persönlichen Vorlieben.

Hast Du zufällig mal ein Backup eingerichtet? Da könntest Du noch alles finden.
https://mailcow.github.io/mailcow-dockerized-docs/b_n_r_backup/

diekuh

Ich habe in 5 Jahren Docker kein Problem damit gehabt persistente Daten dort zu speichern.

Solange die Befehle den Docs entsprechend verwendet werden, ist das alles absolut problemlos.

Pete

@kuhtreiber in meinem Docker-Setup nutze ich an sich für Volumes, die tatsächliche Daten tragen, NFS-shares. Die Shares werden mittels zfs-snapshot alle 2 Stunden “gesichert” und in regelmäßigen Abständen auf einen externen Datenträger repliziert. Ein “prune” ist aufgrund dessen i.d.R. bei mir also auch nicht dramatisch, da ein Volume mit Verweis auf NFS schnell wieder eingerichtet ist und die Daten noch vorhanden sind.
In dieser speziellen Situation hatte ich allerdings 2 Denkfehler:

ich bin davon ausgegangen, dass vmail ausreicht, um meine Bewegtdaten zu sichern. Volumes, die mehr oder minder stateless sind, sprich wo ich die Daten schnell wieder generieren kann, wie z.B. ein Index, sicher ich nicht, wofür auch? In meine Überlegung zu mailcow hätte also mindestens noch das crypt-volume gehört…
Mir war die Existenz von docker-compose.override.yml nicht klar

Beides fällt somit für mich unter ein RTFM-Problem, somit auch keinerlei Vorwurf in Richtung des Projekts.

kuhtreiber

@Pete, habe gerade Deinen ersten Post nochmal gelesen, da schreibst Du es sogar #-) Also nutzt Du bind mount für die wichtigen Daten statt volumes (nur waren nicht alle wichtigen Daten dabei). Genau das meinte ich.

Und richtig: Das ist kein Vorwurf in Richtung des Projektes mailcow(-dockerized)!

@diekuh darum ging es mir. Man hat nicht immer alle Befehle (richtig) gemäß den vielen beteiligten Docs im Kopf und es passieren Fehler. Deshalb versuche ich die Systeme möglichst robust auch gegen Bedienfehler zu gestalten. Ob man das möchte und wie man dabei vorgeht ist Geschmackssache.

Heute werde ich wahrscheinlich soweit sein, das bisher konfigurierte System komplett weg zu schmeißen und aus den gesicherten Daten bzw. mit den vorhandenen Daten (bind mount) die Umgebung neu zu starten. Dann das Vorgehen für den Ernstfall dokumentieren und danach kann es wichtige Mails verarbeiten.

hanswurst

Die eigentliche Frage ist doch in diesem Fall eher, warum die Mails überhaupt verschlüsselt werden. So wie das ganze implementiert ist, hat das doch gar keinen Mehrwert, oder? Wenn der Key neben den Mails liegt? So hat man doch nur ein weiteres System, das unter Umständen Probleme machen kann.

Nur so ein Gedanke :-) vielleicht sollte man das optional machen für Leute, die passende Hardware zum Verschlüsseln haben - oder den Key bei einem Reboot händisch eingeben möchten.