Hallo Joachim,

ich denke mal es ist irgendein Proxy dazwischen, der die Verbindung irgendwann kappt, oder es tritt irgendein anderes Problem auf.

Zuerst würde ich im Logfile schauen, ob da irgendwas verwertbares steht, was mit dem Abbruch zusammen hängt:

root> docker logs otobo_web_1 -f

Wenn nicht, dann ist es normalerweise der Fall, dass die Migration weiterläuft, auch wenn die Verbindung im Browser gekappt wird. Dann einfach nur „Diesen Dialog schließen“ klicken und weiter das Logfile beobachten. Wenn er die Tabelle xml_storage als fertig migriert ausgibt, ist der Task abgeschlossen und wenn Du die Migration dann erneut aufrufst, geht es mit dem nächsten Schritt weiter. Der Rest geht dann ganz schnell.

Die Frage ist auch, wo liegt die Datenbank. Wenn uns da ein Proxy dazwischenfunkt, würde ich die DB lokal in die Docker MariaDB importieren (in eine eigene DB otrs). Wenn Du danach noch einen Abbruch bekommst, dann liegt es an der Strecke zwischen Deinem PC/Browser und OTOBO, die nach 60 Sekunden gekappt wird. Dann ist es aber wie gesagt nicht tragisch, so lange man den Task fertig laufen lässt.

Wenn alle Stricke reißen, wir ( https://otobo.io ) bieten die Migration auch als schlüsselfertige Dienstleistung an.

Ich hoffe ich konnte Dir weiterhelfen,

Stefan Rother

Team OTOBO

Hallo Joachim,

ja hier liegen die großen Datenmengen und Dateien. Und da hier keine Fehlermeldung ist, glaube ich auch nicht, dass er wirklich abbricht. Wie stellst Du fest, das keine Daten übertragen werden? Das kann einfach dauern, bis diese angezeigt werden. Und wie groß ist die DB / Tabelle?

Ansonsten die DB mal lokal in die Docker DB ziehen und von da migrieren, dann kannst Du sicher sein, dass nichts anderes dazwischen funkt.

Schöne Grüße,

Stefan

Hallo Joachim,

das klappt nicht lokal in Docker, denn da läuft eine MariaDB. :(

Ich denke das Problem liegt dann an der PostgreSQL Konfiguration, aber mit Postgres kenne ich mich zu wenig aus. Ich würde mal Postgres auf Fehlermeldungen überprüfen.

Ein weiterer Workaround wäre (diesen Schritt würde ich generell irgendwann empfehlen), die Attachments von der DB in das Filesystem zu migrieren und auch dort in Zukunft zu speichern. Ansonsten wird die DB immer weiter wachsen, da die Attachments und Inline-Images immer größer werden. Somit sind die große Dateien raus und die Tabelle sollte keine Probleme mehr machen.

Vorgehen auf dem OTRS Server:

Bitte überprüfe das Du genug Speicherplatz auf dem OTRS Server hast, im Standard schreibt er die Artikel nach /opt/otrs/var/article (Der Pfad kann aber per Config geändert werden).

Dann in der OTRS Konfiguration per SysConfig oder in der Config.pm folgende Optionen setzen:

$Self->{'Ticket::StorageModule'} = 'Kernel::System::Ticket::ArticleStorageFS';
$Self->{'Ticket::StorageModule::CheckAllBackends'} = '1';

Anschließend folgendes Skript ausführen:

bin/otrs.Console.pl Admin::Article::StorageSwitch--target ArticleStorageFS --tolerant

–tolerant würde ich mit angeben, dann überspringt er korrupte Attachments.

Wenn alle Attachments auf dem Filesystem liegen, kannst Du diese Option wieder deaktivieren:

$Self->{'Ticket::StorageModule::CheckAllBackends'} = '0';

Die brauchen wir nur für die Zwischenzeit, wenn teilweise Daten in der DB und im FS liegen.

Die extrahierten Attachements könntest Du dann einfach bei oder nach der OTOBO Migration in den Docker Container an diese Stelle syncen, dann müssen diese nicht kompliziert über https übertragen werden:

/var/lib/docker/volumes/opt_otobo_opt/_data/var/article/*

Danach nur noch die Rechte setzen:

root> chown 1000:1000 /var/lib/docker/volumes/opt_otobo_opt/_data/var/article -R

Das würde ich wie gesagt sowieso machen und ich kann mir vorstellen, dass dadurch die Migration auch klappt.

Schöne Grüße,

Stefan

Hallo Joachim,

weißt du noch was du gemacht hast um dieses Problem zu beheben?

„Nur die Elasticsearch Suche geht nicht. Da kommen keine Ergebnisse. Muss man dazu noch irgendwas laufen lassen ?“

Gruß Lars