Andy mit gromox-pff2mt Name.pst | gromox-mt2exm -u target@mailbox.de

Im Moment muss ich davon ausgehen, dass die obige Importsequenz nicht funktioniert bzw. vlt. einen Bug hat.

Ich habe nun versuchsweise alle User gelöscht, neu gebooted und einen der User wieder neu angelegt und zunächst noch nichts importiert usw. Öffne ich dann das Profil mit Outlook, gibt es keinen Absturz, dann läuft es ohne Störungen.

Klar ist es so, dass ich mit Outlook bei einem Major-Releasewechsel jedesmal den Export in eine PST und in der Neuinstallation mit Outlook auch den Import mittels der PST durchführen kann. Ich habe dahingehend eben immer bedenken, dass etwas verloren geht, insbesondere bei so grossen Postfächern. Von daher wäre mir ein Servertool, wie das obige, im Grunde viel lieber, noch besser, wenn das Tool neben Import auch den Export durchführen könnte.

Ich kann leider erst in ein paar Tagen einen neuen Import dann mit Outlook durchführen, insofern komme ich nochmals darauf zurück.

Joa, wir ham ja Zeit 🙂

Ansonsten probier es halt einfach mal wie @WalterH sauber beschrieben hat mittels Upgrade statt einem "Export->Neu-Installation->Import"
https://community.grommunio.com/d/792-update-form-open-suse-153-to-154

Und alternativ kannst du auch eine Neuinstallation mit allen benötigten Paketen(wo ich glaube wieso du das so machen möchtest) machen, alle Benutzer Importieren/Anlegen, alle gromox-Dienste runter fahren und die Daten dann einfach in /var/lib/gromox/user/X/Y wieder reinkopieren.

Falls die Zuweisung der Ordner anders ist einfach mittels grommunio-admin user query username maildir auf beiden Servern machen und dementsprechend neu zuordnen falls sich was geändert hat.
Am Ende noch prüfen das die Ordnerberechtigungen passen chown -Rf grommunio:gromox /var/ib/gromox/user/*/* und dann sollte das eigtl. auch passen.

Das war erstmal nur grob beschrieben.. aber im grunde alles was nötig wäre.

  • Andy replied to this.

    crpb Daten dann einfach in /var/lib/gromox/user/X/Y wieder reinkopieren

    Ich müsste die von VM zu VM kopieren, nehm ich da WebDAV oder wie stelle ich das so direkt wie möglich an?

    Im ersten Schritt habe ich den Outlookimport durchgeführt, die zuletzt angesprochene Variante werde ich in einem Testsystem durchführen. Mit dem Import habe ich nun auch damit eine voll funktionsfähige Installation mit allen soweit funktionierenden Modulen.

    Klar scheint damit, dass die Importsequenz gromox-pff2mt Name.pst | gromox-mt2exm -u target@mailbox.de einen Bug aufweist, was sehr schade ist, denn das Handling damit, würde einen Umstieg zB. bei Major-Releasewechseln doch ziemlich erleichtern und vereinfachen. Wenn es dazu noch eine Exportvariante gäbe, noch besser.

    Klar geht auch ein Import über Outlook und bei kleinen Postfächern ist auch gut verifizierbar, ob alles ankommt. Bei grossen Postfächern dauert das gegenüber der obigen Methode um ein vielfaches länger und man hat nur den einen Anhalt, wenn sich in der WebAPP nach Stunden auch ganz unten im Baum im letzten Verzeichnis alle Emails zeigen, kann der Import zunächst als abgeschlossen gelten. Mit Verzeichnisstichproben muss man halt checken und vergleichen, bislang konnte ich jedoch keine Abweichungen feststellen, sodass diese Methode von der Sache her auch zuverlässig funktioniert.

    • crpb replied to this.

      Andy Klar scheint damit, dass die Importsequenz gromox-pff2mt Name.pst | gromox-mt2exm -u target@mailbox.de einen Bug aufweist

      Das ist erst klar wenn man das ganze evtl. mit den -t [-p] Parametern laufen lässt um es zu diagnostizieren. Es geht ja sonst bei etlichen Installationen problemlos.

      Andy mstieg zB. bei Major-Releasewechseln doch ziemlich erleichtern und vereinfachen.

      Der normale Weg ist ein Upgrade durchzuführen und keine komplette Neuinstallation und Import via PST. Der PST-Import setzt ja auch voraus das du hier alle Postfächer exportierst was bei einer größeren Installation einfach nicht tragbar/möglich wäre.

      Das letzte Systemupgrade von 15.3 auf 15.4 war holprig, keine Frage, aber ich denke aus diesen Fehlern wurde auch seitens Grommunio bestimmt genügend Erfahrung gesammelt und somit vermute ich mal das dies beim nächsten mal besser laufen wird.

      Mit dem in der Dokumentation beschriebenen Backupverfahren ist die Neuinstallation/Wiederherstelliung aber auch recht einfach zu bewerkstelligen.
      Natürlich setzt dies voraus das man ein gewisses Grundwissen hat oder sich aneignen muss. Aber das ist ja nichts neues ¯_(ツ)_/¯.

      Da sich in Outlook das bisherige Profil nicht verwenden hat lassen

      Natürlich nicht. Im Profil und/oder der .ost-Datei sind ein Haufen UUIDs vermerkt, die durch Neuanlage des Mailstore oder gar Neuanlage des Users serverseitig neu ausgewürfelt werden.

      Wenn man die MySQL-DB, das Zeug unter /var/lib/grom* und /etc/grom* behält, kann man sich auch den Neuimport komplett sparen. Warum einfach wenn's auch kompliziert geht 🤦

      • Andy replied to this.

        jengelh Warum einfach wenn's auch kompliziert geht 🤦

        Wenn das so einfach ist, wäre für mich eine Migration durch Scriptabläufe einfach und vor allem prozeßsicher. Natürlich ist mir auch klar, dass PST-Handling im Grunde nicht die Lösung für sowas ist und dass man für Migrationen Grundwissen braucht.

        Dennoch PST Export, PST Import, das ist einfach, wenn man einen schnellen und vor allem einen Sicherheit vermittelnden Weg möchte. Upgrades, die nicht funktionieren und Migrationen mit x-Schritten, die von der Sache her manuell nun mal nicht prozeßsicher sind, vermitteln keine Sicherheit, ich hoffe, dass auch mal auf diese Weise verständlich wird, weshalb ich für meine Umstände diesen Weg wähle.

        Den oben angerissenen Weg werde ich testen unter diesem Aspekt, Dienste stoppen, Daten rüber, Dienste starten. Noch Rechte checken und ggf. geraderücken ist dann auch noch okay. Das wäre für mich dann auch noch einfach.

        • Andy replied to this.

          Andy testen unter diesem Aspekt

          Habe ich nun durchgeführt. Die Daten gehen rüber mit rsync, alles da soweit, die Zuordnungen in den User-Unterordnern muss man anpassen, zB. /var/lib/gromox/user/0/1/ in /var/lib/gromox/user/2/2/ und die Rechte, jedoch gibt es im WebAPP noch folgende Meldung, die ich nicht zuordnen kann oder wegbekomme:

          Ich kann alle Inhalte lesen, auch wenn der "Fehler" auftaucht. Der "Fehler" kommt in jedem Verzeichnis, den kann ich zwar wegklicken, aber er kommt nach rund 10 Sekunden immer wieder. Ansonsten kann ich momentan keine Fehler feststellen, auch die Outlookanbindung funktioniert.

          Kann jemand sagen, was noch zu prüfen wäre? Es scheint wohl keine grosse Sache zu sein, da abgesehen davon alles zu funktionieren scheint.

          Das war der Vorgang:

          1. Quell- und Zielsystem updaten und rebooten -> gleicher Stand lp.154.53.1
          2. Neues System mit denselben Parametern einrichten wie das alte System
          3. Dienste beenden auf beiden Systemen
          4. Export der MariaDB-Datenbank: mysqldump --all-databases > quell_dump_grommunio.sql
          5. Transfer: rsync -aH -essh --delete --numeric-ids -P --stats --inplace /var/lib/gromox/ root@Quell-IP:/var/lib/gromox/
          6. Ordnerberechtigungen prüfen: chown -Rf grommunio:gromox /var/ib/gromox/user/*/*
          7. Importuser x und y anpassen /var/lib/gromox/user/x/y/ mittels grommunio-admin user query username maildir
          8. Import der MariaDB-Datenbank: mysqldump --all-databases < quell_dump_grommunio.sql
          9. Dienste starten auf beiden Systemen

          Dann Reboot des Neusystems.

          • crpb replied to this.

            Andy Importuser anpassen /var/lib/gromox/user/x/y/ mittels grommunio-admin user query username maildir
            Import der MariaDB-Datenbank: mysqldump --all-databases < /usr/local/share/quell_dump_grommunio.sql

            Wenn du erst die Datenbank importierst (Grundinstallation durchgeführt und sonst nichts) musst du keinerlei Ordner anpassen. Das steht schon alles drin.

            grommunio-2022121:/etc/gromox # mysql grommunio <<< "select username,maildir from users;"
            username        maildir
            admin
            cb@test.local   /var/lib/gromox/user/0/1
            test@test.local /var/lib/gromox/user/1/0

            Hier muss man natürlich aufpassen! Nur die "grommunio"-Datenbank willst du wahrscheinlich importieren. Denn wenn du auch die DB mysql importierst wird du dir wahrscheinlich die Zugriffsrechte für die anderen DBs zerhacken.

            Vielleicht sowas nehmen zum einzeln sichern

            mysql --execute="SHOW DATABASES" --skip-column-names --batch |grep -Ev '^(mysql|(performance|information)_schema)$' |while read -r DB; do mysqldump --single-transaction --routines --triggers --events --add-drop-database $DB > $DB.sql ; done

            UNGESTESTET!

            Siehe auch noch mal https://community.grommunio.com/d/307-mailbox-backup/5 und auch Walters Beitrag danach https://community.grommunio.com/d/307-mailbox-backup/6

            • Andy replied to this.

              crpb Nur die "grommunio"-Datenbank willst du wahrscheinlich importieren

              Stimmt natürlich.... Die Quelle hat die Module nicht, das Ziel hat die aber. Ansonsten ist alles andere identisch. Führe ich die obige Sequenz für die Einzelsicherungen aus, bleibe ich in der Konsole hängen mit ">", als wenn ich in der Datenbank wäre.

              Im Zweifel müsste ich doch nur die Grommunio Datenbank /var/lib/mysql/grommunio/ übertragen, oder nicht?

              schreib ein done 😛 das fehlte und hatte ich schon ersetzt im text oben

              Nochmals zur Doku, dieser Weg ist überschaubar und hat klare Schritte, damit läuft eine Neuinstallation, in welche aus einer Bisherinstallation die Daten übernommen werden:

              1. Quell- und Zielsystem updaten und rebooten: zypper refresh && zypper update
              2. Neuinstallation identisch zu Bisherinstallation als Basis einrichten, keine User
              3. Dienste beenden auf beiden Systemen: systemctl --all --output json list-units| jq '.[]|select(.unit|test("(^grom.*|nginx|.*fpm).service")).unit' |xargs systemctl stop
              4. Export der MariaDB-Datenbank: mysql --execute="SHOW DATABASES" --skip-column-names --batch |grep -Ev '^(mysql|(performance|information)_schema)$' |while read -r DB; do mysqldump --single-transaction --routines --triggers --events --add-drop-database $DB > /usr/local/share/$DB.sql ; done
              5. Nutzerdatenübertragung Q -> Z: rsync -aH -essh --delete --numeric-ids -P --stats --inplace /var/lib/gromox/ root@192.168.xxx.xxx:/var/lib/gromox/
              6. Ordnerberechtigungen prüfen: chown -Rf grommunio:gromox /var/ib/gromox/user/*/*
              7. Import der MariaDB-Datenbank: mysql grommunio < /usr/local/share/grommunio.sql
              8. Import der MariaDB-Datenbank: mysql sys < /usr/local/share/sys.sql
              9. Importuser prüfen /var/lib/gromox/user/x/y/: grommunio-admin user query username maildir auf beiden Systemen ausführen
              10. Reboot

                Und denke noch an die Konfigurationen.

                WalterH Eigentlich muss man alles im /etc/gromox/ zurück kopieren, in einigen Dateien sind die x500 IDs des Systems enthalten.
                Die Zertifikate darf man auch nicht vergessen.

                Wenn du alles kopierst musst du nur aufpassen wegen dem Mysql-Kennwort aber das kannst du zur Not ja auch neu setzen.

                Die Frage wäre, was passieren könnte, bislang gibt es keine Probleme. Die Outlookprofile wurden alle neu angelegt und entsprechend neue Zertifikatsanfragen auch in anderen Programmen werden ggf. bestätigt, wie zu einer Neuinstallation. Wenn man das damit umgehen könnte, dann wäre das verstanden für die nächste Runde. Mir war im ersten Schritt wichtig, mit wenigen Schritten eine übersichtliche und serverbasierte Migration hinzubekommen und das halte ich nun Dank Dir für gelungen.

                Vielleicht könnte man für weitere Upgrades alle installationsrelevanten Daten weiter zentralisieren. Momentan muss man mindestens 1. und 2. und demnach zumindest 3 verschiedene Locations im Blick haben:

                1. /var/lib/gromox/user/x/y/
                2. /var/lib/mysql/
                3. /etc/gromox/

                Je transparenter das wird, um so einfacher ist ein Major-Upgrade insbesondere für neuere Admins.

                • crpb replied to this.

                  Andy /var/lib/mysql/

                  Den wirst du nicht händisch kopieren wollen. Ein Mysqldump ist kinderleicht und auch die sicherste Methode

                  Und zu den beiden anderen Ordnern:
                  Das ist ganz normale Datenstruktur in UNIX/Linux seit eh und je. Da wird wohl niemals was dran gerüttelt.
                  Du hast ja auch im Windows für gewöhnlich Regisitrierungseinstellungen, dann vielleicht noch Domänenobjekte mit Exchange und die Installation des Exchange landet für gewöhnlich auch meist auf mindestens drei verschiedenen Platten/Partitionen.
                  Da sind wir hier noch einfach gestrickt was das angeht.

                  6 days later

                  Many Thanks to @Andy and @crpb (and the many others who have contributed input) into working out this upgrade process. Today I have followed Andy basic process in a test environment to hopefully 'dot the i's and cross the t's' on the process (see below). Although I have been an IT professional for many years I have little experience in the Linux world so have been following the many threads in the Community to make moving from each major version upgrade as simple as possible. Hopefully, if others find this process useful, it may make it into the Grommunio documentation for others who follow.

                  Migrate Grommunio from old to new Server with all data

                  `1. Update and reboot the source and target system: zypper refresh & & zypper update.

                  1. Build new server installation identical to current live server. Follow your build documentation upto the point of creating user accounts (call this ‘new server’ in steps below).
                  2. Stop inbound Internet email and user access to your live server mailboxes to avoid missing emails during migration.
                  3. Optional step - If Grommunio is in Virtual Environment, clone (or take backup of) live server to avoid any damage/corruption to current live server during migration (call this ‘old server’ in steps below), just in case you need to revert to what was your current live server.
                  4. Stop services on both systems: systemctl --all --output json list-units| jq '.[]|select(.unit|test("(grom.|nginx|.fpm).service")).unit' |xargs systemctl stop
                  5. Export of the MariaDB database on old server: mysql --execute="SHOW DATABASES" --skip-column-names --batch |grep -Ev '^(mysql|(performance|information)_schema)$' |while read -r DB; do mysqldump --single-transaction --routines --triggers --events --add-drop-database $DB > /usr/local/share/$DB.sql ; done
                  6. User Data transfer old server to new server: rsync -aH -essh --delete --numeric-ids -P --stats --inplace /var/lib/gromox/ root@192.168.xxx.xxx:/var/lib/gromox/
                  7. Move MariaDB backup (from step 4) from old system to new system. Run this on old server: rsync -aH -essh --delete --numeric-ids -P --stats --inplace /usr/local/share/ root@192.168.xxx.xxx:/usr/local/share/
                  8. Check folder permissions on new server: chown -Rf grommunio:gromox /var/ib/gromox/user//
                  9. Import of the MariaDB database on new server: mysql grommunio < /usr/local/share/grommunio.sql
                  10. Import of the MariaDB database on new server: mysql sys < /usr/local/share/sys.sql
                  11. Check import user /var/lib/gromox/user/x/y/: run grommunio-admin user query username maildir on both systems - make sure they match.
                  12. Reboot
                    `
                    Nearly forgot this mention this bit, you will need to update your router/reverse proxy to allow your inbound email and users to the new server.

                  I have a fairly basic mail only Grommunio system so I don't have any advanced configuration hiding in the background. If you have any specific customisations these will need migrating to your new server as well (but this should be in your own documentation already).

                  © 2020-2024 grommunio GmbH. All rights reserved. | https://grommunio.com | Data Protection | Legal notice