1.) Auslagern der Attachments ins Filesystem
Zuerst prüfe ich über die Option
"Ticket::Article::Backend::MIMEBase::ArticleStorage",
ob die Attachments in der Datenbank oder im Filesystem gespeichert sind.
Sollte die Option auf „DB“ stehen, würde ich empfehlen diese von der Datenbank in das Dateisystem auszulagern.
Das würde ich im Vorfeld noch in OTRS erledigen.
Das kann einfach während des Betriebs erfolgen, Du musst nur folgende Optionen in OTRS anpassen:
Ticket::Article::Backend::MIMEBase::CheckAllStorageBackends -> Yes
Ticket::Article::Backend::MIMEBase::ArticleDataDir -> Neues Verzeichnis mit genug Platz
Um die Attachments dann aus der Datenbank in den Ordner zu kopieren, existiert das Skript:
bin/otobo.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS --tolerant
Das würde ich im Vorfeld noch in Ruhe in OTRS erledigen.
Wichtig:
Wenn MySQL/MariaDB mit InnoDB verwendet wird, verkleinert sich die Datenbankgröße noch nicht sofort, der Speicherplatz wird erst beim Dump oder einem "optimize table" freigegeben: https://dba.stackexchange.com/questions/64134/deleting-reclaiming-space-from-innodb-table
Daher darauf achten, dass wirklich genug Speicherplatz für die Aktion zur Verfügung steht.
Die Datenbank wird danach aber dann viel kleiner sein, bei 100 GB vorher mit Attachments sind wir danach bei ca. 10 GB.
-> Achtung! Die Article Daten können dann bei der Migration gleich in OTOBO an den richtigen Platz kopiert werden. Bei der Migration wird hier nichts verändert.
2.) Was tun beim Abbruch der Migration während der Datenbankmigration?
Bei sehr alten Systemen kann es immer passieren, dass Inhalte von Tabellen nicht stimmen, da Upgrades in der Vergangenheit nicht sauber geklappt haben oder Daten per Hand gelöscht wurden. Leider ist es bei der Migration so, dass man normalerweise immer wieder von vorne beginnen muss, wenn die Migration wegen eines Fehlers abgebrochen ist. Um das zu umgehen, gibt es einen Trick:
In der Datei
Kernel/System/MigrateFromOTRS/Base.pm (ca. Zeile 1285)
gibt es die Methode „sub DBSkipTables“.
Hier sind alle Tabellen aufgeführt, die nicht migriert werden sollen.
Wenn die Migration abgebrochen ist, repariere ich zuerst die Datenbank und füge dann alle Tabellen (die vorher sauber durchgelaufen sind) mit in diese Liste/Methode ein. Wenn ich die Migration dann neu starte, werden die schon sauber migrieren Tabellen übersprungen.
Man kann hier auch noch tricksen, in dem man sehr große Tabellen die nicht verändert werden müssen einfach direkt aus OTRS dumped und in OTOBO einfügt und diese dann in die obige Liste mit aufnimmt.
3.) Manuelle Datenbankmigration
Es existiert hier auch die Möglichkeit, die Datenbank Inhalte über ein script schneller zu kopieren. Dies Methode wende ich persönlich nicht mehr häufig an, daher kann ich nicht sehr viel dazu sagen. Eine Beschreibung hierzu findest Du hier:
Damit kann die Datenbank Migration stark beschleunigt werden, dass funktioniert aber nur wenn von und zu Mysql/MariaDB migriert wird.