• MMaKu

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

    Hallo,
    ich betreibe seit ca 2 Jahren eine kleine mailcow Installation. (Ubuntu 18.04. LTS)
    Die Installation der Kuh läuft auf scsi0 und die Mails liegen auf scsi1.
    Die Kuh läuft auf Proxmox als Hypervisor und es ist auch fast alles perfekt. 😄

    Der Redis Container schreibt aber exakt alle 5 Minuten relativ viele Daten auf die Disk.

    Ganz genau sind es bei mir aktuell 2,74TB in 14 Tagen, also 196GB am Tag.

    Ich habe etwas Angst um meine SSDs bei der hohen Schreiblast.
    Als Resultat steigt in Proxmox dann auch der “Dirty-Bitmap” Wert und ich muss (bei 2 täglichen Backups) rund 40GB / Tag an diff Backups wegsichern.

    Stimmt etwas mit meiner Installation nicht?
    Ist das vielleicht einfach nur ein internes Backup? - kann man das Intervall anpassen oder etwas zurücksetzen?
    Danke Euch schon Vorhinein!

    • diekuh

      • Community Hero
      • volunteer
      Moolevel 110
    • Post #2
    • This post is in German

    Hi,
    kannst du mal schauen wie groß die dump rdb im Redis Volume ist?
    Wann das letzte Update?

    • MaKu replied to this.

      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!

      • MMaKu

          Moolevel 0
        • Post #3
        • This post is in German

        diekuh
        Das letzte Update habe ich am 03.06.2021 durchgeführt.

        root@srv01:/var/lib/docker/volumes/mailcowdockerized_redis-vol-1/_data# ls -lh
        total 430M
        -rw-r–r– 1 999 martin 430M Jun 17 20:14 dump.rdb

        oh,… 430MB XD
        ist das “normal” oder gibt es bei meiner Installation ein Problem?

        Danke für dir Hilfe!

          • MMaKu

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

            Was haben die anderen User für eine Filesize der dump.rdb ?
            Könnte mir mal bitte jemand nachsehen und posten? Würde mich interessieren. 👍🏻

            diekuh
            Kann die Größe des Files OK sei, oder habe ich irgendwo ein Problem?
            Wie kann ich denn feststellen was es da hat, bzw warum das File so groß ist und ich so hohen I/O auf den Disken habe? 🥺

            …ich weiß nicht mehr weiter 😵‍💫
            Danke

              8 days later

              Hi,

              Leg dir “docker-compose.override.yml” in deinem mailcow Verzeichnis an.

              version: '2.1'
services:
  redis-mailcow:
    entrypoint: /usr/local/bin/docker-entrypoint.sh redis-server /etc/redis/redis.conf
    volumes:
      - ./data/conf/redis/redis.conf:/etc/redis/redis.conf:Z

              lege folgende Datei an “data/conf/redis/redis.conf”

              save 14400 1
save 7200 100
save 60 10000

              Jetzt brauchst du MailCow nur neustarten.

              Redis speichert die dump.rdb alle 60 Sekunden bei 10.000 Änderungen, alle 2 Stunden bei 100 Änderungen und alle 4Stunden bei mindesten 1 Änderung.

              gruß

              8 months later

              Hallo,

              ich war jetzt lange auf der Suche nach der Ursache für die großen inkrementellen Backups meiner Mailcow VM und der vielen I/O’s. Dabei bin ich nun auf diesen Thread gestoßen.

              Meine dump.rdb ist 350 MB groß und wurde alle 5 Minuten neu geschrieben. Dies hat ein tägliches inkrementelles Backup von über 12 GB verursacht.

              Der Vorschlag von @sigdor hat mir sehr geholfen und die Backupgröße bereits um einiges reduziert.

              Mit folgender data/conf/redis/redis.conf konnte ich das inkrementelle Backup der VM noch mehr reduzieren (unter 1 GB, wenn man die dazugekommenen E-Mails abzieht).

              save ""
appendonly yes
auto-aof-rewrite-percentage 50
auto-aof-rewrite-min-size 64mb

              Mehr infos gibt es hier: https://redis.io/topics/persistence

              redis.io
              https://redis.io/topics/persistence
              Retrieving...

              Vielleicht kann dies auch anderen helfen die inkrementelle Backupgröße und die I/O Last der SSD zu reduzieren.

              No one is typing