Hosting des OTOBO Ticketsystems – Leitfaden für Einsteiger und Fortgeschrittene

Einleitung

OTOBO ist ein vielseitiges, open-source Ticketsystem (ein Fork der ((OTRS)) Community Edition) für Helpdesks und Service-Management. Unternehmen können damit Kundenanfragen und interne Aufgaben effizient verwalten. Im Gegensatz zu Cloud-Lösungen ist OTOBO kostenlos, muss aber auf einem eigenen Server betrieben werden – weshalb das Hosting eine entscheidende Rolle spielt. Ein stabiles und sicheres Hosting stellt sicher, dass das Ticketsystem jederzeit verfügbar ist, performant läuft und sensible Daten geschützt bleiben. Dieser Artikel gibt einen umfassenden Überblick zum OTOBO Hosting – von den Voraussetzungen über die Installation (per Docker) bis hin zu Anbieter-Vergleichen und Best Practices.

Hardware- und Betriebssystemanforderungen für OTOBO (Docker-Installation)

Bevor Sie mit der Installation beginnen, sollten Sie sicherstellen, dass Ihre Hardware und das Betriebssystem den Anforderungen von OTOBO genügen. Grundsätzlich läuft OTOBO nur auf Linux/Unix-Systemen; Für die Docker-basierte Installation empfiehlt das OTOBO-Projekt ein aktuelles Linux (beispielsweise Ubuntu 20.04 LTS oder neuer) als Host-System.

Minimale Hardware (Testsystem): Für kleine Testinstallationen reicht ein Server mit etwa 2 CPU-Kernen, 4 GB RAM und **15–20 GB Speicher. Dies ermöglicht die Verarbeitung weniger Tickets pro Tag und kleinere Anhänge.

Empfohlene Hardware (Produktion): Für den produktiven Einsatz mit höherem Ticketaufkommen sollte die Maschine leistungsfähiger sein – z.B. 4 vCPU, 8 GB RAM (besser 16 GB) und **40+ GB Festplattenspeicher Gerade viel Speicher (RAM) stellt sicher, dass die Datenbank, der Webserver und Dienste wie Elasticsearch flüssig laufen. Die genaue Dimensionierung hängt von der Nutzung ab (Anzahl Tickets, Benutzer, Anhänge); planen Sie im Zweifel lieber etwas Reserve ein.

Tipp

Nutzen Sie möglichst SSD-basierten Speicher für schnelle Datenbankzugriffe und Backups. Achten Sie auch darauf, dass Docker auf dem Host installiert ist (getestet wurden mindestens Docker 19.03+ und Docker Compose 1.25+). Weitere Details finden Sie in der OTOBO Installationsanleitung ( Abschnitt Systemvoraussetzungen).

Vergleich von Hosting-Anbietern für OTOBO

Die Wahl des Hosting-Anbieters beeinflusst maßgeblich Aufwand, Kosten und Leistung Ihres OTOBO-Systems. Im Folgenden vergleichen wir vier gängige Optionen – von deutschen Rechenzentren bis zur globalen Cloud – mit ihren Vor- und Nachteilen.

Hetzner

Hetzner ist ein deutscher Anbieter, der für preiswertes Hosting mit hoher Leistung bekannt ist. Vorteile sind u.a. Serverstandorte in Deutschland (gut für Datenschutz) und ein hervorragendes Preis-Leistungs-Verhältnis – vergleichbare Ressourcen kosten bei AWS/Azure oft ein Vielfaches (AWS and Azure are At Least 4x–10x More Expensive Than Hetzner). Hetzner bietet sowohl Cloud-Server (flexibel skalierbar, stündlich abrechenbar) als auch Dedizierte Server mit vollem Root-Zugriff. Für OTOBO Docker-Installationen sind Hetzners Cloud VPS oder CX/CPX-Server beliebt, da sie Docker sofort unterstützen. Vorteile: Günstige Preise, schnelle Hardware (NVMe-SSDs, AMD EPYC/Intel Xeon CPUs), einfache Verwaltung über eine Web-Konsole, Datenhaltung in deutschen Rechenzentren. Nachteile: Kein weltweit verteiltes Netzwerk – Rechenzentren primär in DE (und Finnland), also weniger ideal für internationale Benutzer mit Latenzanforderungen. Zudem müssen Sie das System selbst administrieren (kein Managed Support im Basistarif). Insgesamt ist Hetzner ideal für erfahrene Nutzer oder Unternehmen, die kosteneffizient in Deutschland hosten wollen.

AWS (Amazon Web Services)

AWS ist ein globaler Cloud-Marktführer und bietet eine riesige Auswahl an Diensten. Für OTOBO-Hosting kann man z.B. Amazon EC2 Instanzen verwenden (virtuelle Linux-Server) oder verwaltete Datenbanken via RDS anbindung. Vorteile: Höchste Flexibilität und Skalierbarkeit – Sie können je nach Bedarf Serverleistung hoch- oder runterfahren, Load Balancing und Auto-Scaling einsetzen und aus vielen Regionen weltweit wählen. Außerdem gibt es zahlreiche Zusatzdienste (Backup, Monitoring, CDN), die sich ins OTOBO-Setup integrieren lassen. Nachteile: Kosten – AWS ist deutlich teurer als Hetzner bei gleicher Hardwareleistung (AWS and Azure are At Least 4x–10x More Expensive Than Hetzner), vor allem wenn dauerhaft Ressourcen gebucht sind. Die Preisstruktur ist komplex (z.B. Kosten für Traffic, Speicher, Backups extra), was für Einsteiger unübersichtlich sein kann. Zudem erfordert AWS Fachwissen, da die Vielzahl der Optionen auch die Konfiguration aufwändiger macht. AWS lohnt sich insbesondere für große Deployments oder wenn man Wert auf globale Verfügbarkeit und Managed-Services legt. Für ein mittelständisches Unternehmen, das OTOBO einzeln betreibt, sind die AWS-Mehrkosten oft nicht gerechtfertigt.

Microsoft Azure

Azure (von Microsoft) ist – ähnlich wie AWS – eine globale Cloud-Plattform mit umfangreichen Services. Azure bietet Linux-VMs für Docker genauso wie Container-Dienste (z.B. Azure Container Instances oder AKS, falls man Kubernetes einsetzen möchte). Vorteile: Gute Integration in Microsoft-Ökosysteme – ideal, wenn Sie bereits Microsoft-Dienste nutzen (Azure AD für Single Sign-On, Office 365 Anbindung etc.). Azure hat Rechenzentren weltweit, inklusive in Europa, und bietet zuverlässige Infrastruktur mit umfangreichen Compliance-Zertifizierungen (wichtig für enterprise Kunden). * Nachteile:* Kosten und Komplexität sind vergleichbar mit AWS – Azure gehört ebenfalls zu den hochpreisigen Optionen, insbesondere wenn viele Ressourcen oder Windows-Server genutzt werden. Die Verwaltung über das Azure-Portal erfordert Einarbeitung; für reine Linux/Docker-Hosts ist es manchmal Overkill. Wenn hauptsächlich ein einzelnes OTOBO-System betrieben werden soll, kann Azure – wie AWS – überdimensioniert wirken. Es ist jedoch eine starke Option für Unternehmen, die ohnehin auf Microsoft setzen oder zusätzliche Azure-Dienste (AI, BI, etc.) einbinden möchten.

IONOS (1&1 IONOS)

IONOS ist ein deutscher Hosting-Anbieter, der sowohl klassische Webhosting-Pakete als auch Cloud-Server und Managed-Services anbietet. Für das Hosting eines OTOBO Ticketsystems empfiehlt sich bei IONOS ein Cloud Server oder VPS mit Linux, auf dem Sie Docker installieren. Vorteile: Datenstandort Deutschland (für DSGVO ideal) und deutschsprachiger Support. IONOS ist auf Benutzerfreundlichkeit ausgerichtet – das Dashboard ist anfängerfreundlich, und es gibt One-Click-Installer für manche Anwendungen (für OTRS/OTOBO allerdings soweit bekannt nicht als fertiges Image, Stand heute). Preislich liegen die Cloud-Server im mittleren Bereich, oft günstiger als AWS/Azure, allerdings tendenziell etwas teurer als Hetzner bei gleicher Leistung. Nachteile: Etwas weniger Community-Ressourcen und Tutorials im Netz im Vergleich zu AWS/Hetzner. Außerdem sind die wirklich günstigen Tarife (Shared Hosting) nicht geeignet für OTOBO, man benötigt mindestens einen dedizierten VM-Tarif mit Docker-Unterstützung. Insgesamt ist IONOS eine gute Wahl, wenn man einen deutschen Anbieter mit Support möchte und mit einer konventionelleren Hosting-Umgebung zufrieden ist.

Managed OTOBO Hosting

Falls Sie den technischen Aufwand scheuen, gibt es auch Managed Hosting Angebote für OTOBO. Dabei kümmert sich ein Dienstleister um Installation, Updates, Monitoring und Backups, während Sie das Ticket-System einfach nutzen. Einige spezialisierte Firmen bieten OTOBO Managed Hosting an.

Tipp

Egal ob Eigenbetrieb oder Managed – achten Sie darauf, dass der Hosting-Standort zu Ihren Compliance-Anforderungen passt. Viele deutsche Firmen bevorzugen z.B. Hetzner oder IONOS, um ihre Daten in Deutschland zu halten.

Installation von OTOBO mit Docker

• OTOBO Installation;
• Fortgeschrittene Installation

Best Practices für ein sicheres und performantes OTOBO Hosting

Hat man OTOBO erfolgreich installiert, sollte man einige Best Practices beachten, um den Betrieb möglichst **sicher **, schnell und zuverlässig zu gestalten. Hier sind die wichtigsten Empfehlungen zu Performance, Sicherheit und Backups:

Performance-Tipps

• Caching und Suchindex nutzen: OTOBO bringt Redis als Cache und Elasticsearch für die Volltextsuche bereits via Docker mit. Stellen Sie sicher, dass diese Container aktiviert sind (otobo_redis_1 und otobo_elastic_1 laufen standardmäßig) – sie verbessern die Performance deutlich (schnellere Seitenaufrufe, schnellere Suchergebnisse). Ohne Elasticsearch muss die Datenbank alle Ticket-Text durchsuchen, was langsamer ist.

• Ausreichend Ressourcen zuweisen: Beobachten Sie CPU- und Speicherauslastung Ihres Servers. Bei vielen gleichzeitigen Agenten oder Tickets können 4 GB RAM knapp werden – skalieren Sie auf 8 oder 16 GB, bevor das System ins Swappen gerät. Ähnliches gilt für die CPU: Mehr Kerne helfen bei vielen parallelen Requests. Nutzen Sie ggf. dedizierte Datenbank-Server, wenn die Last sehr hoch ist (in Docker können Sie die DB auch auf einen separaten Host auslagern).

• Ticket-Anzahl verwalten: Lassen Sie nicht zigtausende offene Tickets in der aktiven Queue liegen. Archivieren oder schließen Sie alte Tickets regelmäßig. OTOBO hat Funktionen zum Archivieren von Tickets, was die Ticket-Listen und Suchindizes entlastet. Außerdem kann ab einer sehr großen Ticketzahl der Wechsel auf den statischen Ticket-Index sinnvoll sein (Performance Tuning — OTOBO Installation Guide 10.1 documentation) (Performance Tuning — OTOBO Installation Guide 10.1 documentation) – dies ist jedoch meist erst bei >80.000 offenen Tickets nötig.

• Dateispeicherung optimieren: Standardmäßig speichert OTOBO Anhänge als Dateien auf dem Volume. Das ist performanter als Speicherung in der DB. Stellen Sie sicher, dass das Volume (otobo_opt_otobo in Docker) auf schnellem Speicher liegt. Bei Bedarf können Sie das Attachments-Verzeichnis auf eine separate Partition legen. Halten Sie genügend freien Speicherplatz vor – bei vielen und großen Anhängen könnte sonst die Platte volllaufen und das System stoppen.

• Monitoring einrichten: Überwachen Sie Ihr System (CPU, RAM, DB-Performance, Docker-Container Health). Frühwarnungen bei hoher Last oder Fehlern ermöglichen proaktives Handeln. Docker bietet mit docker stats einfache Live-Daten je Container. Für längerfristiges Monitoring können Tools wie Prometheus/Grafana oder CloudWatch (bei AWS) genutzt werden.

Sicherheitsmaßnahmen

• Updates und Patches einspielen: Halten Sie OTOBO selbst sowie das Betriebssystem und Docker auf aktuellem Stand. Sicherheitsupdates des OTOBO-Projekts sollten zeitnah installiert werden (bei Docker einfach ein neues Image ziehen und Container neu starten). Aktualisieren Sie auch regelmäßig die genutzten Perl-Module und Bibliotheken, falls Sie ein manuelles System haben.

• HTTPS verwenden: Schützen Sie die Weboberfläche durch SSL/TLS. In der Docker-Umgebung können Sie entweder den mitgelieferten Nginx-Proxy nutzen (siehe .env Option für HTTPS) oder einen externen Proxy/Webserver vorschalten. Kostenlose Zertifikate von Let’s Encrypt lassen sich automatisiert einbinden. So stellen Sie sicher, dass Anmeldeinformationen und sensible Ticketinhalte verschlüsselt übertragen werden.

• Starke Passwörter & 2FA: Erzwingen Sie komplexe Passwörter für alle Agenten-Accounts. Ändern Sie das Standard-Admin-Passwort sofort nach Installation. OTOBO bietet Zwei-Faktor-Authentifizierung (OTP) für Agenten (OTOBO/Znuny und OTRS ((Community Edition)) Einführung - Get Started | OTOBO) – überlegen Sie, diese zu aktivieren, um den Zugriff noch besser abzusichern.

• Zugriff absichern: Wenn möglich, beschränken Sie den externen Zugriff auf das OTOBO-Interface. Beispielsweise könnten VPN oder feste IP-Whitelist für das Agenten-Interface genutzt werden, falls nur Mitarbeiter intern zugreifen müssen. Mindestens aber sollte die Admin-Dashboard-URL nicht offen ins Internet ragen. Nutzen Sie außerdem Firewalls ( UFW, iptables oder Cloud-Sicherheitsgruppen) um nur die nötigen Ports (HTTP/HTTPS, SSH) zu öffnen. Die Datenbank und Redis/Elasticsearch-Ports sollten nicht öffentlich erreichbar sein.

• Server-Härtung: Auf Linux-Servern schalten Sie ungenutzte Dienste ab und installieren Sie nur notwendige Software. Konfigurieren Sie regelmäßige Sicherheits-Scans. Wenn Sie RHEL/CentOS nutzen, beachten Sie, dass SELinux Docker-Container einschränken kann – entweder konfigurieren Sie die erforderlichen Rechte oder deaktivieren SELinux, sonst funktioniert OTOBO evtl. nicht korrekt.

Backups und Wartung

• Regelmäßige Backups: Führen Sie täglich Backups der OTOBO-Datenbank und der wichtigen Dateiverzeichnisse durch. In Docker-Umgebungen kann man z.B. mit docker exec einen MySQL-Dump erstellen und die Dateien aus dem Volume sichern. Automatisieren Sie dies per Cronjob. Bewahren Sie Backups auf externen Systemen oder Speicher (z.B. Cloud Storage) auf, damit sie auch bei einem Server-Ausfall verfügbar sind.

• Backup-Strategie testen: Überprüfen Sie Ihre Sicherungen regelmäßig durch Test-Wiederherstellungen. Nichts ist schlimmer als ein Backup, das sich im Notfall als unbrauchbar herausstellt. OTOBO bietet offizielle Anleitungen für Backup und Restore folgen Sie diesen und dokumentieren Sie den Ablauf intern.

• Konfiguration dokumentieren: Halten Sie fest, welche Anpassungen Sie an der OTOBO-Konfiguration vorgenommen haben (z.B. in SysConfig, zusätzliche Pakete/Addons, Cronjobs). Im Fehlerfall oder bei Updates hilft dies, Probleme schneller einzugrenzen. Exportieren Sie wichtige Einstellungen und behalten Sie Versionsstände der Docker-Compose-Dateien bzw. .env unter Versionskontrolle.

• Updates einplanen: Planen Sie Wartungsfenster für OTOBO-Upgrades ein. Bei Docker-basiertem Setup kann ein Update bedeuten, neue Container hochzuziehen. Machen Sie vorher ein Backup, prüfen Sie die Release Notes und testen Sie das Upgrade idealerweise in einer Staging-Umgebung. So halten Sie Ihr System langfristig sicher und kompatibel.

Häufige Probleme und Lösungen beim OTOBO Hosting

Trotz guter Vorbereitung können im Betrieb Probleme auftreten. Hier sind einige häufige Probleme beim OTOBO-Hosting (insbesondere in Docker-Setups) und Tipps zur Fehlerbehebung:

• Weboberfläche nicht erreichbar: Wenn das OTOBO-Webinterface nicht lädt, prüfen Sie zuerst, ob alle Docker-Container laufen: docker-compose ps sollte für web, db etc. "Up (healthy)" anzeigen. Stellen Sie sicher, dass der Port (Standard 80 oder 5000) in der Firewall freigegeben ist. Bei Zugriff über eine Domain prüfen Sie die DNS-Einstellung und die .env-Konfiguration (FQDN). Lösung: Führen Sie docker-compose logs web aus, um Hinweise zu Fehlern zu erhalten. Häufig hilft ein docker-compose restart der betroffenen Services. Bei Connection refused Fehlern sicherstellen, dass kein anderer Dienst den Port blockiert.

• Leistungsprobleme: Das System reagiert träge oder hängt? Überprüfen Sie, ob der Server eventuell *Speichermangel ** hat (Swap Nutzung) oder die CPU überlastet ist. Oft ist zu wenig RAM die Ursache – MySQL geht dann in die Knie. * Lösung: Weisen Sie mehr RAM/CPU zu oder skalieren Sie auf einen größeren Server. Prüfen Sie außerdem, ob Redis und Elasticsearch korrekt laufen – ohne Cache und Index wird OTOBO deutlich langsamer. Ein Blick in die OTOBO Systemlog ( Adminbereich oder Datei otobo.log) kann zeigen, ob z.B. Queries zu lange dauern. Archivieren Sie gegebenenfalls alte Tickets, um die aktiven Datenmengen klein zu halten.

• E-Mail-Versand oder -Abruf schlägt fehl: OTOBO holt E-Mails von Postfächern ab und versendet Mails über SMTP. Wenn das nicht funktioniert, liegt es oft an falschen Einstellungen oder Verbindungsproblemen. Lösung: Öffnen Sie die SysConfig in OTOBO und prüfen Sie die Mail-Account-Einstellungen (Server, Port, Benutzer, Passwort). Bei Office 365/Exchange müssen ggf. moderne Authentifizierungsmethoden oder App-Passwörter verwendet werden. Überwachen Sie das OTOBO Log auf Fehlermeldungen beim Mailabruf (Stichwort IMAP/POP errors) oder Versand (SMTP errors). Ein typischer Fehler ist z.B. "Authentication failed" – dann stimmen die Zugangsdaten nicht. Bei SSL/TLS-Problemen ( Zertifikatsfehler) stellen Sie sicher, dass der Container dem Mailserver vertraut (zur Not CA-Zertifikat installieren). Auch Firewalleinstellungen des Servers können das Problem sein – erlauben Sie ausgehende Verbindungen auf Port 993 (IMAPS) und 587/465 (SMTPS) im Server-Firewall.

• Docker-Container-Probleme (Abstürze, Rechte): Falls Container unerwartet stoppen oder Neustarten (Crash Loop), schauen Sie mit docker-compose logs nach Fehlermeldungen. Ein häufiger Stolperstein sind Dateirechte auf den gemounteten Volumes. Der OTOBO-Container läuft als User otobo (UID 1000) – stellen Sie sicher, dass die Verzeichnisse auf dem Host dieser UID Schreibrechte geben. Ein Hinweis darauf sind Fehlermeldungen à la "Permission denied" in den Logs. Lösung: Führen Sie im Zweifel das Script otobo.SetPermissions.pl (im Container unter /opt/otobo/bin/) aus, um die Berechtigungen richtig zu setzen. Oder passen Sie die Owner auf dem Host an (chown -R 1000:1000 ./otobo-docker/opt_otobo). Ein anderes Problem können fehlende Environment-Variablen sein – wenn docker-compose up sofort abbricht, prüfen Sie, ob alle in der .env geforderten Variablen gesetzt sind. Beispiel: Fehlt die Angabe MYSQL_ROOT_PASSWORD, startet die DB nicht. Konsultieren Sie die Doku für erforderliche .env-Einträge.

• Backup/Restore Fehler: Beim Einspielen eines Backups kann es zu Fehlern kommen, z.B. inkompatible Datenbankversion oder fehlende Dateien. Lösung: Achten Sie darauf, dass dieselbe OTOBO-Version verwendet wird, die das Backup erzeugt hat. Importieren Sie zunächst die Datenbank (z.B. via mysql < backup.sql im DB-Container) und stellen Sie dann die Dateianhänge und Konfigurationsdateien wieder her. Setzen Sie anschließend die Berechtigungen korrekt. Prüfen Sie nach dem Restore die OTOBO Logs und die Systemkonfiguration. Bei größeren Versionssprüngen führen Sie das Migrationsskript aus (otobo.Console.pl Maint::Database::Migration), falls notwendig. Im Zweifel finden Sie in der OTOBO Dokumentation unter Backup and Restore weitere Hilfe.

Fazit

Durch sorgfältige Planung und Beachtung dieser Hinweise gelingt sowohl Einsteigern als auch Fortgeschrittenen ein erfolgreiches OTOBO Hosting. Von der richtigen Wahl der Infrastruktur über die optimale Installation bis hin zu Sicherheit und Performance – mit dem obigen Leitfaden holen Sie das Beste aus Ihrem OTOBO Ticketsystem heraus. Bei Fragen oder komplexen Umgebungen zögern Sie nicht, auf die umfangreiche OTOBO-Dokumentation und die Community zurückzugreifen oder einen erfahrenen OTOBO-Dienstleister zurate zu ziehen. Viel Erfolg mit Ihrem OTOBO-Server!