• Feedback
  • DEGerman

  • Maildir auf eigenem Storage

    German

  • crkt

      Moolevel 1
    • Post #1
    • This post is in German

    Hallo,

    ich verwende seit 2 Jahren Mailcow auf einem VPS von Contabo. Soweit ist damit alles in Ordnung und es gibt auch keinerlei Probleme. Dennoch überlege ich aktuell in die Hetzner Cloud zu wechseln um u.A. etwas flexibler zu sein.

    Grundsätzlich geht es mir darum, bei Hetzner ein Block Storage Volume für das Maildir zu verwenden. Die Dokumentation dazu (Move Maildir) habe ich bereits gelesen, ist ja sehr einfach und um das Doing geht es mir nicht. Aber hat das schon jemand so im Einsatz und kann eventuell kurz seine Erfahrung damit teilen? Speziell geht es mir um Zuverlässigkeit und Performance. Also sowas wie “was passiert wenn das Volume nicht verfügbar ist?” usw.

    Ich möchte vermeiden dass z.B. nach einem Neustart das Volume warum auch immer nicht vorhanden ist und es mir die Installation um die Ohren haut. Da die Mailcow Installation auch schon einige Zeit Produktiv im Einsatz ist wäre es auch unschön wenn dadurch etwas verloren geht.

    Da derzeit alles optimal funktioniert muss ich auch nichts erzwingen oder übereilen.

    Wir betrriben mehrere Mailcow-Server in der Hetzner-Cloud und haben neben der Basisfestplatte zwei SSD-Volumes auf diese Verzeichnisse gemountet:
    /var/lib/docker/volumes
    /backup

    Weil die SSD-Volume problemlos jederzeit vergrößert werden können und ebenso auch der Baisserver leicht auf stärkere Hardware skaliert werden kann, ist das System extrem flexibel und kann leicht mitwachsen.

    Have something to say?

    Join the community by quickly registering to participate in this discussion. We'd like to see you joining our great moo-community!

    Hi,

    mache ich auch so seit mehreren Monaten.

    Keinerlei Performance Probleme.

    Ich kann nichts dazu sagen was passiert wenn das volume mal offline ist. Würde wohl ein Script schreiben was mailcow dann abschaltet.

    Lg

    • Qqupfer

        Moolevel 3
      • Post #4
      • Edited
      • This post is in German

      Jup, habe ebenso keine PRobleme mit externen Blockvolumes.
      Würde aber den “old-way” gemäß Anleitung empfehlen, so hat man die “neuen” Pfade gleich mit im compose-File, falls man mal ein Backup wiederherstellen muss.

      Etwas Offtopic:
      Bin sogar soweit gegangen, dass ich den Mountpoint der Docker-Volums (via old-way) mit in den gitlab-Ordner gelegt habe und den ganzen Ordner auf ein btrfs formatiertes via Loop gemountes Image gelegt habe (da mein Root-FS kein btrfs ist)

      Jetzt mach ich stündlich

      • btrfs-Snapshots vom gitlab-ordner (der wie gesagt auch die Docker-Volumes enthält und das docker-compose.overwrite.yml und andere Modifikationen enthält)
      • bennene das sql-volume um (theoretisch ginge auch löschen)
      • mariabackup –backup + mariaback –prepare ins sql-volume –> ReadyToUse DB-Daten aus einer laufenden Instanz
      • sqldump (unnötig, aber fühlt sich sicherer an)
      • setze ReadOnly

      Ich denke zu 99,9% würde auch ein Snapshot ausreichen und der Aufwand mit der Datenbank ist unnötig. Aber es fühlt sich sauberer an, weil die Datenbank ja noch aktiv ist und theoretisch noch was wichtiges im RAM sein könnte, was durch die Backupbfehle noch den Weg auf die Platte und somit ins Backup findet.

      Das kostet kaum Ressourcen, dank CoW. Und man kann je nach Wunsch die Snapshots in aller Ruhe weiterverwenden, sind ja Readonly.
      Ich synce z.B. den letzten nochmal auf mein privates NAS daheim und 1x täglich tare ich einen und schieb den auch nochmal woanders hin und das Image-File mit dem gesamten btrfs-filesystem wird auch nochmal regelmäßig gesichert :-D

      Und im Fehlerfall/neuer Server muss ich mir nur ein Snapshot schnappen, entpacken und hab mein Mailserver wieder im Betrieb.

      • crkt

          Moolevel 1
        • Post #5
        • Edited
        • This post is in German

        Danke für die ausführlichen Informationen!

        Das mit den Snapshots bzw. das Offtopic hört sich interessant an. Ich glaube ich gebe der ganzen Sache einfach mal einen Test und schaue wie es läuft.

        2 months later

        hat schon einmal jemand das ganze in der AWS eingesetzt und als Storage S3 verwendet?
        Ist das möglich?

        No one is typing