Liebe Commoonity,

Ich habe zum Thema Backup/Restore zwei Fragen.

Erstens: ich plane, für das Backup meines Mailcow-Servers Cold Standby zu verwenden, stoße hierbei jedoch auf eine Merkwürdigkeit. Auf meinem Backup-Server liegt nach dem Durchlauf des Scripts eine funktionsfähige Kopie (Hurra), aber beim Start der Mailcow-Umgebung erhalte ich für jedes Volume eine Warnung:
WARN[0000] volume "[...]" already exists but was not created by Docker Compose. Useexternal: trueto use an existing volume
Da das Script laut Doku auch für die Migration einer Mailcow-Installation von einem Server zu einem anderen verwendet werden kann und ich mir nur schwer vorstellen kann, dass man damit auf Dauer leben soll, frage ich mich (und jetzt euch), ob hier etwas schiefgegangen ist…? Ist das normal, wie werde ich das wieder los? Wenn ich eine Migration wie in der Doku beschrieben mache

, tritt dieser Effekt ja nicht auf.

Und zweite Frage: Wenn ich dem o.g. Vorgehen zur Migration folge, mache ich ja als Erstes per rsync eine 1:1-Kopie meines Mailcow-Verzeichnisses und meiner Volumes, stoppe dann die Kuh und Docker und lasse die beiden rsync-Kommandos noch einmal laufen. Was geht mir eigentlich verloren, wenn ich nur die ersten beiden rsync-Kommandos durchlaufen lasse, also das Stoppen von Docker und den zweiten Durchlauf auslasse? Habe ich dann zwangsweise eine inkonsistente Umgebung oder fehlen mir nur ein paar Dinge, die zwischen Scriptstart und Scriptende liegen? Hätte ich damit nicht auch ein funktionstüchtiges Backup, das ich z.B. täglich über einen weiteren rsync-Lauf aktualisieren könnte?

Danke für Antworten und Ideen,
Andreas

  • DerLinkman replied to this.
  • Diese Meldung ist eine neue “Warnung” von Docker Compose v2, wenn man versucht ein Volume auf ein anderes System zu verschieben, was dort nicht erstellt wurde. Diese muss ignoriert werden. Ist soweit ich weiß nicht lösbar (aktuell zumindest)

    Mit diesem PR wird man die Warn-Meldung ganz einfach los – ohne Nebenwirkungen:
    mailcow/mailcow-dockerized6203

    Je nachdem, ob der PR offiziell durchgeht oder nicht, wird das in Kürze auch offiziell enthalten sein.

    Letztlich wird lediglich nach dem Synchronisieren des Verzeichnisses mailcow-dockerized auf Remote-Seite einmal docker compose create ausgeführt, was dazu führt, dass die ganzen Volumes dem Docker-Daemon “gehören”. Dann synchronisieren wir den Inhalt von der lokalen Maschine hinein und alles ist wie gewünscht migriert.

    13 days later
    • DerLinkman

      • Forum Staff
      • tinc employee
      Moolevel 16

    Hi,

    der Reihe nach:

    andreas_mueller Erstens: ich plane, für das Backup meines Mailcow-Servers Cold Standby zu verwenden, stoße hierbei jedoch auf eine Merkwürdigkeit. Auf meinem Backup-Server liegt nach dem Durchlauf des Scripts eine funktionsfähige Kopie (Hurra), aber beim Start der Mailcow-Umgebung erhalte ich für jedes Volume eine Warnung:
    WARN[0000] volume “[…]” already exists but was not created by Docker Compose. Useexternal: trueto use an existing volume
    Da das Script laut Doku auch für die Migration einer Mailcow-Installation von einem Server zu einem anderen verwendet werden kann und ich mir nur schwer vorstellen kann, dass man damit auf Dauer leben soll, frage ich mich (und jetzt euch), ob hier etwas schiefgegangen ist…? Ist das normal, wie werde ich das wieder los? Wenn ich eine Migration wie in der Doku beschrieben mache docs.mailcow.emailhttps://docs.mailcow.email/i_u_m/i_u_m_migration/No preview could be generated for this link

    , tritt dieser Effekt ja nicht auf.

    Diese Meldung ist eine neue “Warnung” von Docker Compose v2, wenn man versucht ein Volume auf ein anderes System zu verschieben, was dort nicht erstellt wurde. Diese muss ignoriert werden. Ist soweit ich weiß nicht lösbar (aktuell zumindest)

    andreas_mueller Und zweite Frage: Wenn ich dem o.g. Vorgehen zur Migration folge, mache ich ja als Erstes per rsync eine 1:1-Kopie meines Mailcow-Verzeichnisses und meiner Volumes, stoppe dann die Kuh und Docker und lasse die beiden rsync-Kommandos noch einmal laufen. Was geht mir eigentlich verloren, wenn ich nur die ersten beiden rsync-Kommandos durchlaufen lasse, also das Stoppen von Docker und den zweiten Durchlauf auslasse? Habe ich dann zwangsweise eine inkonsistente Umgebung oder fehlen mir nur ein paar Dinge, die zwischen Scriptstart und Scriptende liegen? Hätte ich damit nicht auch ein funktionstüchtiges Backup, das ich z.B. täglich über einen weiteren rsync-Lauf aktualisieren könnte?

    Wenn du nicht so viel Mailtraffic hast geht dir eigentlich nicht viel/gar nichts flöten. Der Sync nach dem Stoppen ist aber auch wichtig für das korrekte herunterfahren der Mariadb Datenbank, die ja sonst noch läuft und temporäre Dateien besetzt die dann weg sind.

    Aber klar: Du kannst das Backup täglich, stündlich, minütlich wie du mags per RSYNC einfach ergänzen lassen. Nur als finalen Schwenk solltest du einmal einen Sync im gestoppten zustand machen, nur um sicher zu sein.

      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!

      2 years later

      DerLinkman
      gibt es hierzu (zum Ergänzen der Backups per RSYNC) ein Beispiel ?
      Es wäre ja je nach Szenario wünschenswert, eine engmaschigere Sicherung zu haben, die einmal pro Tag dann per Sync (gestoppter Zustand) konsistent zu machen ?

      5 months later

      Diese Meldung ist eine neue “Warnung” von Docker Compose v2, wenn man versucht ein Volume auf ein anderes System zu verschieben, was dort nicht erstellt wurde. Diese muss ignoriert werden. Ist soweit ich weiß nicht lösbar (aktuell zumindest)

      Mit diesem PR wird man die Warn-Meldung ganz einfach los – ohne Nebenwirkungen:
      mailcow/mailcow-dockerized6203

      Je nachdem, ob der PR offiziell durchgeht oder nicht, wird das in Kürze auch offiziell enthalten sein.

      Letztlich wird lediglich nach dem Synchronisieren des Verzeichnisses mailcow-dockerized auf Remote-Seite einmal docker compose create ausgeführt, was dazu führt, dass die ganzen Volumes dem Docker-Daemon “gehören”. Dann synchronisieren wir den Inhalt von der lokalen Maschine hinein und alles ist wie gewünscht migriert.

      • DerLinkman

        • Forum Staff
        • tinc employee
        Moolevel 16

      Jo ging durch 🙂 Danke nochmal!

      No one is typing