Betrieb und Infrastruktur

Dieses Kapitel beschreibt die Daemons, Cron-Jobs sowie den Backup- und Restore-Prozess, an denen das System im laufenden Betrieb hängt. Vollständige Deployment-Details wie Server-Größen, Netzwerk-Topologie, Secrets-Management und der Monitoring-Stack sind in der separaten Infrastruktur-Doku gepflegt und nicht Teil dieses Werks.

Tag und Nacht: Betrieb

Die Architektur steht, die Pipeline funktioniert. Aber wer sorgt dafür, dass alles dauerhaft läuft, auch nachts, auch am Wochenende, auch wenn niemand zuschaut?

Das System besteht im Betrieb aus zwei Arten von Prozessen: dauerhaft laufende Daemons und periodische Cron-Jobs. Kurz zur Abgrenzung: ein Daemon läuft durch und schläft zwischen seinen Aufgaben; ein Cron-Job wird regelmäßig neu gestartet, erledigt seine Aufgabe und beendet sich wieder.

Daemons: immer aktiv

Die Daemons sind als Systemd-Services konfiguriert: sie starten automatisch beim Systemstart, werden bei einem Absturz neu gestartet und schreiben ihre Ausgabe in Log-Dateien.

• Queue-Worker (PHP): Holt Emails aus der Warteschlange und führt die komplette Pipeline aus.
• SMTP-Worker (PHP): Versendet freigegebene Entwürfe und speichert Feedback.
• LLM-Worker (PHP): Verarbeitet asynchrone LLM-Aufgaben aus der LLM-Queue.
• Embedding-Service (Python): HTTP-Server, der Texte in Vektoren umwandelt.
• Entity-Extractor (Python): HTTP-Server für die Entitätenerkennung.

Cron-Jobs: regelmäßig getaktet

• IMAP-Poller: Alle 30 Sekunden (realisiert über zwei Cron-Einträge pro Minute, der zweite mit sleep 30).
• Cleanup: Stündlich. Setzt hängende Queue-Einträge zurück, archiviert alte Emails, anonymisiert Kontakte.
• ArangoDB-Sync: Alle 15 Minuten. Synchronisiert den Gesamtbestand nach ArangoDB.
• Integrity-Check: Alle 15 Minuten. Prüft die Konsistenz zwischen den Datenbanken.

Überwachung und Sicherung

Neben den Arbeitsprozessen gibt es Dienste, die das System selbst überwachen:

• Health-Check: Prüft regelmäßig, ob alle Services aktiv sind und die Queue nicht hängt.
• DB-Backup: Täglich wird ein komprimiertes Datenbank-Backup erstellt. Ältere Backups werden automatisch gelöscht.
• Logrotate: Log-Dateien werden täglich rotiert und komprimiert. Ohne Rotation würden die Worker-Logs unbegrenzt wachsen.

Wiederherstellung: vom Backup zurück in den Betrieb

Ein Backup ist nur dann wertvoll, wenn die Wiederherstellung praktisch funktioniert. Für das System ist der Restore-Ablauf wie folgt dokumentiert:

• Reihenfolge: zuerst MariaDB-Dump einspielen (Source of Truth für Emails, Metadaten, Status). Danach Qdrant-Snapshot zurückladen (Embeddings, rebuildbar aus Emails wenn nötig). Danach ArangoDB-Dump (Wissensgraph, rebuildbar aus Entitäts-Datensätzen wenn nötig). Die IMAP-Queue baut sich aus dem Mailserver neu auf, da ungelesene Emails dort liegen bleiben, bis die Verarbeitung erfolgreich war.
• Testfrequenz: Vierteljährlich Trockenlauf auf Staging. Der Betrieb dokumentiert jeden Testlauf im Audit-Log inklusive Dauer und festgestellten Abweichungen.
• Zielwerte: RTO (Recovery Time Objective) 60 Minuten bei voller Wiederherstellung mit DB-Restore, RPO (Recovery Point Objective) 24 Stunden (entspricht dem täglichen Backup-Zyklus).
• Verantwortlichkeit: Der Betrieb führt Restore-Läufe aus, protokolliert Beginn und Ende im Audit-Log und meldet Auffälligkeiten an die Entwicklung weiter.

Das Kapitel email-rag-ki-zielsystem nennt einen Recovery-Sollwert unter 5 Minuten für Einzelprozess-Ausfälle ohne DB-Restore. Die hier beschriebene volle Wiederherstellung ist davon abzugrenzen.