StorageSwitch: DB -> ArticleStorageFS

[c19]

Hallo Zusammen,

wir haben ein gewachsenes OTRS System. Die Installation war irgendwann 2011 in Version 2.x von meinem Vorgänger durchgeführt worden.
Ich habe nun die Verwaltung des Systems seit der Version 3.x übernommen.
Die Updates sind auch alle einwandfrei durchgeführt worden und befinden uns auf der letzten Version.
Mittlerweile ist das System rechts groß (DB > 8GB) und Filesystem (Article 400GB) geworden.

Ich wollte mittels nachfolgendem Befehl die Tickets aus der Datenbank in das Filesystem pumpen.

Code: Select all

su -c "bin/otrs.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS --micro-sleep 1000 " -s /bin/bash otrs

Das Script läuft ohne Fehler durch - der Witz ist das die DB jedesmal anwächst .

Allerdings kann ich keinerlei erstellte Tickets im FileSystem feststellen.

Code: Select all

 ls -lisah /opt/otrs/var/article/
2012 2013 2014 2015 2016

Ich vermisse den 2011 Ordner mit den UnterOrdnern 07-12

Mein otrs User hat die Schreibrechte.

Kann mich jemand in die richtige Richtung schubsen, wo ich noch nachschauen kann warum das nicht funktioniert?

Gruß
Christian

[c19]

Keiner eine Idee ?

[jojo]

was sagt das Logfile?

[c19]

Hi jojo,

ich habe den Befehl erneut (am 14.07.77 um 9:00Uhr) ausgeführt

Code: Select all

root@otrs /opt/otrs # su -c "bin/otrs.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS --tickets-closed-before-days 1812" -s /bin/bash otrs

Ausgabe war folgende

Code: Select all

1/10 (TicketID:3)
2/10 (TicketID:35)
3/10 (TicketID:36)
4/10 (TicketID:34)
5/10 (TicketID:84)
6/10 (TicketID:96)
7/10 (TicketID:103)
8/10 (TicketID:104)
9/10 (TicketID:105)
10/10 (TicketID:107)
Done.
root@otrs /opt/otrs #

Anschließend habe ich mir die log-verzeichnisse durchgeschaut.

Code: Select all

tail /var/log/syslog
Jul 14 09:00:01 otrs postfix/qmgr[4908]: 962A0AE1B6B: from=<#@#.#>, size=697, nrcpt=1 (queue active)
Jul 14 09:00:01 otrs postfix/local[15062]: 962A0AE1B6B: to=<#@#.#>, orig_to=<otrs>, relay=local, delay=0.05, delays=0.03/0/0/0.01, dsn=2.0.0, status=sent (delivered to mailbox)
Jul 14 09:00:01 otrs postfix/qmgr[4908]: 962A0AE1B6B: removed
Jul 14 09:02:05 otrs postfix/pickup[13101]: 026C7AE1B6B: uid=33 from=<#@#.#>
Jul 14 09:02:05 otrs postfix/cleanup[15150]: 026C7AE1B6B: message-id=<#@#.#>
Jul 14 09:02:05 otrs opendkim[4701]: 026C7AE1B6B: no signing table match for '#@#.#'
Jul 14 09:02:05 otrs opendkim[4701]: 026C7AE1B6B: no signature data
Jul 14 09:02:05 otrs postfix/qmgr[4908]: 026C7AE1B6B: from=<#@#.#>, size=13685, nrcpt=1 (queue active)
Jul 14 09:02:07 otrs postfix/smtp[15152]: 026C7AE1B6B: to=<#@#.#>, relay=####[17.##.##.66]:25, delay=2.3, delays=0.04/0.01/0.46/1.8, dsn=2.5.0, status=sent (250 2.5.0 Ok.)
Jul 14 09:02:07 otrs postfix/qmgr[4908]: 026C7AE1B6B: removed

nix

/opt/otrs/var/log/otrs/otrs5.log.2016-07

Code: Select all

[Thu Jul 14 07:41:56 2016][Error][Kernel::System::Ticket::Article::ArticleSend][2255] Impossible to send message to: #@#.# .
root@otrs /opt/otrs #

auch nix

Im Verzeichnis hatte ich mir zumindest erhoft das dort was geschehen ist.

Code: Select all

root@otrs /opt/otrs # ls -lisah var/article/2011/*
var/article/2011/01:
total 8.0K
84205848 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..

var/article/2011/02:
total 8.0K
84205849 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..

var/article/2011/03:
total 8.0K
84205850 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..

var/article/2011/04:
total 8.0K
84205851 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..

var/article/2011/05:
total 8.0K
84205852 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..

var/article/2011/06:
total 8.0K
84205853 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..

var/article/2011/07:
total 8.0K
84205854 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..

var/article/2011/08:
total 8.0K
84205855 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..

var/article/2011/09:
total 8.0K
84205856 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..

var/article/2011/10:
total 8.0K
84205857 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..

var/article/2011/11:
total 8.0K
84205858 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..

var/article/2011/12:
total 8.0K
84205859 4.0K drwxrwsr-x  2 otrs www-data 4.0K Jul  8 13:42 .
84183435 4.0K drwxrwsr-x 14 otrs www-data 4.0K Jul  8 13:43 ..
root@otrs /opt/otrs #

Pustekuchen

Nicht einmal im aktuellen Verzeichnis

Code: Select all

root@otrs /opt/otrs # ls -lisah var/article/2016/07
total 348K
88605637 4.0K drwxrws---   16 otrs www-data 4.0K Jul 14 00:00 .
88606327 4.0K drwxrwsr-x    9 otrs www-data 4.0K Jul  1 00:00 ..
88605638  32K drwxrws--- 1049 otrs www-data  32K Jul  4 11:40 01
88656257 4.0K drwxrws---  242 otrs www-data 4.0K Jul  4 08:20 02
88680027  12K drwxrws---  263 otrs www-data  12K Jul  4 08:20 03
89040241  36K drwxrws--- 1477 otrs www-data  36K Jul  7 15:40 04
88647186  36K drwxrws--- 1258 otrs www-data  36K Jul  6 10:00 05
  311297  36K drwxrws--- 1247 otrs www-data  36K Jul  7 08:00 06
  198414  36K drwxrws--- 1360 otrs www-data  36K Jul  8 08:40 07
  468903  28K drwxrws--- 1068 otrs www-data  28K Jul 11 15:40 08
89115007 4.0K drwxrws---  128 otrs www-data 4.0K Jul 11 13:20 09
  590575 4.0K drwxrws---  123 otrs www-data 4.0K Jul 11 13:20 10
89154988  36K drwxrws--- 1447 otrs www-data  36K Jul 12 09:40 11
89115016  36K drwxrws--- 1215 otrs www-data  36K Jul 14 08:20 12
88631807  36K drwxrws--- 1120 otrs www-data  36K Jul 14 08:20 13
 1074992 4.0K drwxrws---  103 otrs www-data 4.0K Jul 14 09:16 14

auch nix

Verständnisfrage:

Code: Select all

root@otrs /opt/otrs # su -c "bin/otrs.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS --tickets-closed-before-days 1812" -s /bin/bash otrs

Der Befehl sagt doch salop gesagt folgendes aus:
Dein neues Backend ist nun das Filesystem und nicht mehr die Datenbank.
Kopiere die geschlossenen tickets von vor 1812 Tagen.


Was sollte mit den Tickets aus der Datenbank passieren ?
Sollten Sie mit absetzen des Befehls automatisch gelöscht werden oder muss man das händisch erledigen?

[jojo]

Hallo,

es fehlt zu einem die Source Angabe (also von wo wird verschoben). Des weiteren werden nicht die Tickets, sondern nur die Attachments ins Filesystem geschoben (und dann aus der DB gelöscht)

[c19]

Hi jojo,

danke für den Hinweis - mit den Attachements

Langsam aber sicher kommt Licht ins Dunkle.

Code: Select all

root@otrs /opt/otrs # su -c "bin/otrs.Console.pl Admin::Article::StorageSwitch --help" -s /bin/bash otrs

Migrate article files from one storage backend to another on the fly.

Usage:
 otrs.Console.pl Admin::Article::StorageSwitch --target ... [--tickets-closed-before-date ...] [--tickets-closed-before-days ...] [--tolerant] [--micro-sleep ...] [--force-pid]

Options:
 --target ...                   - Specify the target backend to migrate to (ArticleStorageDB|ArticleStorageFS).
 [--tickets-closed-before-date ...] - Only process tickets closed before given ISO date.
 [--tickets-closed-before-days ...] - Only process tickets closed more than ... days ago.
 [--tolerant]                   - Continue after failures.
 [--micro-sleep ...]            - Specify microseconds to sleep after every ticket to reduce system load (e.g. 1000).
 [--force-pid]                  - Start even if another process is still registered in the database.
 [--help]                       - Display help for this command.
 [--no-ansi]                    - Do not perform ANSI terminal output coloring.
 [--quiet]                      - Suppress informative output, only retain error messages.

Help:
The Admin::Article::StorageSwitch command migrates article data from one storage backend to another on the fly, for example from DB to FS:

 otrs.console.pl Admin::Article::StorageSwitch --target ArticleStorageFS

You can specify limits for the tickets migrated with --tickets-closed-before-date and --tickets-closed-before-days.

To reduce load on the database for a running system, you can use the --micro-sleep parameter. The command will pause for the specified amount of microseconds after each ticket.

 otrs.console.pl Admin::Article::StorageSwitch --target ArticleStorageFS --micro-sleep 1000

Nur weiss ich leider nicht an welcher Stelle ich die Source Angabe setzen sollte.

Ich ging davon aus, das diese in der SysConfig -> Ticket → Core::Ticket

Ticket::IndexModule

Code: Select all

StaticDB

Standardwert: RuntimeDB

IndexAccelerator: to choose your backend TicketViewAccelerator module. "RuntimeDB" generates each queue view on the fly from ticket table (no performance problems up to ap... Mehr anzeigen
Ticket::StorageModule

Code: Select all

ArticleStorageFS

Standardwert: ArticleStorageDB

Speicherung von Artikel-Anlagen. "DB" legt alle Daten in der Datenbank ab (nicht empfohlen für große Anlagen). "FS" legt alle Daten im Dateisystem ab; dies ist schneller, ... Mehr anzeigen
Ticket::StorageModule::CheckAllBackends

Code: Select all

Ja

Standardwert: Nein

Specifies whether all storage backends should be checked when looking for attachments. This is only required for installations where some attachments are in the file system, and others in the database.
ArticleDir

Code: Select all

<OTRS_CONFIG_Home>/var/article

Standardwert: <OTRS_CONFIG_Home>/var/article

Bestimmt den Ordner, in welchem Daten gespeichert werden, wenn "FS" als TicketStorageModule ausgewählt wurde.

Oder habe ich da etwas falsch verstanden?

Gruß
Christian

Lernbereitschaft hergestellt

[nd0]

Push!?

Habe jetzt im TEST-System "Ticket::StorageModule" auf "ArticleStorageFS" umgestellt.

Was muss ich nun noch tun, damit die bisherigen Anhänge aus der Datenbank ins Filesystem verschoben werden?

[jojo]

Was muss ich nun noch tun, damit die bisherigen Anhänge aus der Datenbank ins Filesystem verschoben werden?

Das was im entsprechenden Kommentar bei dieser Sysconfig Option steht...

[nd0]

Speicherung von Artikel-Anlagen. "DB" legt alle Daten in der Datenbank ab (nicht empfohlen für große Anlagen). "FS" legt alle Daten im Dateisystem ab; dies ist schneller, jedoch sollte der Webserver mit dem OTRS-Benutzer betrieben werden. Sie können im laufenden Betrieb ohne Datenverlust zwischen den Modulen wechseln. Bitte beachten Sie, dass das Suchen nach Anlagen für "FS" nicht unterstützt wird.

... dann fehlt hier wohl der Hinweis auf:

Code: Select all

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

Quelle: https://otrs.github.io/doc/manual/admin ... rs-storage

[nd0]

Kleiner Hinweis an potenzielle Nachahmer:

Ich habe als erstes in der SysConfig "Ticket::StorageModule" auf "ArticleStorageFS" umgestellt, danach dann das oben genannte Script ausgeführt.

Nach Abschluss des Scripts ("done") habe ich überprüft, ob alles glatt gegangen ist und die Anhänge nach wie vor "auffindbar" sind. Zunächst sah es so aus als wäre das nicht der Fall... Aus- und Einloggen hat nichts gebracht, STRG + F5 hat nichts gebracht ... bei mir waren die Anhänge den Artikeln erst wieder zugeordnet nachdem ich in der SysConfig "Ticket::StorageModule" erneut auf "ArticleStorageFS" gestellt habe und anschließend die Änderung gespeichert habe ... ob das Zufall war oder nicht sei mal dahingestellt - eine wichtige Info für jeden der das hier ausprobiert ist es aber auf jeden Fall!