Datenübernahme von OTRS 4.x auf 5.0.6 (nach Zweitinstallation)

[TErdogan]

Mahlzeit!

Vorab unser Szenario:
Kunde hat einen OTRS 4.0.8 im Einsatz. Diverse Probleme mit diesem (u.a. wurden die Daten in der DB gespeichert - bei täglich ~200-300 Tickets mit meist Bildern im Anhang... die Performance gleicht einem gemalten Stillleben und auch Probleme, die über die Zeit entstanden sind), verleitete ihn dazu, uns diesen neu aufsetzen zu lassen.

Also: produktiv läuft momentan noch der OTRS 4.0.8. Ich habe auf einer neuen VM (Ubuntu 14.04) OTRS 5.0.6 nun installiert, soweit eingerichtet und bereitgestellt.

Das "Problem":
Gibt es eine Möglichkeit, einen "Generalexport" sowie "-Import" durchzuführen? Sprich: ich nehme das alte System, exportiere alles (inkl. Templates, Tickets, Konfigurationen, Schreibfehler und Golfbälle) - und tu das ganze dann quasi in die neue Welt importieren? Ich hatte damals, beim Einarbeiten ins OTRS System einige Punkte im Manual gefunden, allerdings wäre das so peu à peu; mal hier, mal da, etc.

Vorteilhaft wäre auch das, woran ich damals scheiterte: können die Tickets, dessen Anhänge in der DB gespeichert sind, ebenfalls ins neue System importiert werden - UND die Anhänge aus der DB ins FS extrahiert werden - UND vor allem danach noch verfügbar sein? Wir hatten das Problem nach dem Umstellen vom ArticleStorageDB auf -FS, dass nur die neuen Tickets, die ab dato Umstellung ins Haus kamen im FS gespeichert wurden (Konvetrierung war Fehlerhaft, weshalb sie abgebrochen ist..) geöffnet werden konnten (bzw. die Anhänge) und wenn man alte Tickets aufgerufen hat, die ursprünglich in die DB gespeichert wurden, waren ohne Anhänge... erst beim Zurückstellen von -FS in -DB konnten Anhänge, alter Tickets wieder geöffnet werden, aber die der neuen (-FS) nichtmehr...

Ums nochmal kurz zu fassen: Umzug von alter Welt (4.0.8 ) in neue Welt (5.0.6) mit allem Drum und Dran.

Einen schönen Mittwoch euch noch,
T. Erdogan

[root]

Ein GeneralImport entspricht einem Upgrade wie hier beschrieben: https://otrs.github.io/doc/manual/admin ... ading.html

Die in "Step 2" beschriebenen Daten müssen dann halt auf das neue System kopiert und der Datenbankdump dort wieder eingespielt werden. Alles in allem kein großes Ding.

Wenn es aber eine VM mit einem halbwegs aktuellen Kernel dürfte die Ursache der Performanceprobleme meiner Meinung nach aber woanders zu suchen sein..

- Roy

[TErdogan]

Ein GeneralImport entspricht einem Upgrade wie hier beschrieben: https://otrs.github.io/doc/manual/admin ... ading.html

Die in "Step 2" beschriebenen Daten müssen dann halt auf das neue System kopiert und der Datenbankdump dort wieder eingespielt werden. Alles in allem kein großes Ding.

Wenn es aber eine VM mit einem halbwegs aktuellen Kernel dürfte die Ursache der Performanceprobleme meiner Meinung nach aber woanders zu suchen sein..

- Roy

Danke für die schnelle Antwort!

Problematisch sehe ich nur, wie erwähnt, die Übernahme der Tickets vom alten ins neue System, zumal die ja ArticleStorageDB hatten - und im neues das -FS zum Einsatz kommt. Die Konvertierung der Anhänge aus DB in FS schlägt fehl (dauert im Übrigen auch gut ~3-4 Stunden bis Fehler & Abbruch; wurde ebenfalls mit dem "-l" Parameter (denke, dass es l war: fortsetzen im Fehlerfall), das macht mir ein bisschen Sorgen. Die MySQL DB misst ~25GB mittlerweile.

Als Hypervisor dient ein ESXi 5.0.0 (gut, das Release ist einiges alt, sollte den Dienst aber für die Belangen tun), der VM sind 2x2 CPUs sowie 8G RAM zugeordnet. Der Host selbst besitzt 2 Xeon E5 Kerne und 48G RAM - die Ressourcen/ die VM sollten, denke ich, nicht Hauptursache des Problems sein (sofern das gemeint war).

Schönen Abend,
T. Erdogan

[root]

Problematisch sehe ich nur, wie erwähnt, die Übernahme der Tickets vom alten ins neue System, zumal die ja ArticleStorageDB hatten - und im neues das -FS zum Einsatz kommt. Die Konvertierung der Anhänge aus DB in FS schlägt fehl (dauert im Übrigen auch gut ~3-4 Stunden bis Fehler & Abbruch; wurde ebenfalls mit dem "-l" Parameter (denke, dass es l war: fortsetzen im Fehlerfall), das macht mir ein bisschen Sorgen. Die MySQL DB misst ~25GB mittlerweile.

Er mal die Daten auf das neue System und dann ArticleStorageSwitch. Man kann zwar die Fehler ignorieren aber schöner ist es natürlich die zu beseitigen. Ein Fehler der bei alten Systemen ab und zu auftaucht sind Artikel mit zwei gleichnamigen Attachments. Aber auch das bekommt man hin.

Als Hypervisor dient ein ESXi 5.0.0 (gut, das Release ist einiges alt, sollte den Dienst aber für die Belangen tun), der VM sind 2x2 CPUs sowie 8G RAM zugeordnet. Der Host selbst besitzt 2 Xeon E5 Kerne und 48G RAM - die Ressourcen/ die VM sollten, denke ich, nicht Hauptursache des Problems sein (sofern das gemeint war).

Das kann vieles sein, vom effektiven Disk-IO bis zu ungünstig konfigurierten Diensten (Apache, MySQL, ...). Am wenigsten hat die ESXi Version damit zu tun.

[darkdead]

Mahlzeit!

Das "Problem":
Gibt es eine Möglichkeit, einen "Generalexport" sowie "-Import" durchzuführen? Sprich: ich nehme das alte System, exportiere alles (inkl. Templates, Tickets, Konfigurationen, Schreibfehler und Golfbälle) - und tu das ganze dann quasi in die neue Welt importieren? Ich hatte damals, beim Einarbeiten ins OTRS System einige Punkte im Manual gefunden, allerdings wäre das so peu à peu; mal hier, mal da, etc.

Wieso so schwer? Erstell dir ne neue Maschine mit der OTRS Version die du bereits einstetzt. Dann machst du auf deiner Produktiv Maschine ein Backup (https://otrs.github.io/doc/manual/admin ... tml#backup) und stellst dieses dann auf der neuen´, schnelleren Maschine mit restore wieder her?

Und danach das Upgrade von 4 auf latest 5?

[Hazet]

Wieso so schwer? Erstell dir ne neue Maschine mit der OTRS Version die du bereits einstetzt. Dann machst du auf deiner Produktiv Maschine ein Backup (https://otrs.github.io/doc/manual/admin ... tml#backup) und stellst dieses dann auf der neuen´, schnelleren Maschine mit restore wieder her?

Damit hat er aber das Problem mit dem ArticleStorage noch nicht gelöst...

Ich habe das auch schon mal gemacht (während der Umstellung von 2.4 auf 3.0), zuerst halt in einer Testumgebung.

Backup machen (FS und DB), auf neuer Installation einspielen, sicher stellen daß Mailempfang und Versand deaktiviert sind.
-> Update auf Version (4 oder 5) Deiner Wahl, hier dann das jeweils aktuellste.
-> StorageSwitch
und da dann sukkzessive die Probleme beseitigen. Gut dokumentieren (was hast Du wann warum gemacht), bis der durchläuft

Anschliessend das ganze dann für's Produktive nachziehen.