Ihren selbst gehosteten DQE One Standalone-Server pflegen

Dieser Artikel richtet sich an diejenige Person, die Ihren eigenen DQE One Standalone-Server (Docker-basiert, selbst gehostet) installiert und betreibt — er behandelt Updates, Backups, Logs, Speicherplatz und die wenigen Einstellungen, die nach der Ersteinrichtung überprüft werden sollten. Wenn Sie Endbenutzer der Anwendung sind statt der Person, die den Server betreibt, lesen Sie stattdessen Maintain your data and processes in DQE One Standalone.

Auf eine neue Version aktualisieren

Es gibt kein separates Update-Skript, das Sie ausführen müssten. Datenbankmigrationen werden bei jedem Start der Anwendung automatisch angewendet — ein Update besteht also einfach darin: das von DQE bereitgestellte neue Image zu übernehmen und Ihre Container neu zu starten (docker compose up -d, oder das Äquivalent für Ihre Umgebung). Das gilt auch für den MCP-Integrationsendpunkt — er läuft im selben Anwendungsprozess, es gibt also nichts Separates dafür zu aktualisieren oder neu zu starten.

Einige ältere Installationsanleitungen erwähnen Variablen wie RUN_COLLECTSTATIC oder eine Gruppe von WAIT_HOSTS-Einstellungen. Prüfen Sie beim Support, ob diese für Ihre Umgebung noch gelten, bevor Sie sich darauf verlassen — in der für diesen Artikel geprüften Version hatten sie nachweislich keine Wirkung.

Ihre Daten sichern und wiederherstellen

Es gibt keine eingebaute Backup-Funktion — behandeln Sie dies wie jede andere PostgreSQL-Bereitstellung. Sichern Sie die Datenbank mit einem Standard-pg_dump, zum Beispiel:

docker compose exec postgres pg_dump -U <DB_USER> -d <DB_NAME> > backup.sql

Stellen Sie sie auf dieselbe Weise mit psql wieder her:

docker compose exec -T postgres psql -U <DB_USER> -d <DB_NAME> < backup.sql

Planen Sie diese Sicherungen selbst regelmäßig ein (oder sichern Sie direkt das Docker-Volume der Datenbank) — die Anwendung erledigt dies nicht für Sie.

Logs

Die eigene Protokolldatei der Anwendung rotiert und bereinigt sich automatisch selbst (tägliche Rotation, 7 Tage Historie werden vorgehalten) — Sie müssen sich darum in der Regel nicht kümmern.

Auch das detaillierte Ausführungsprotokoll eines Runs wird nicht als eigenständige Datei aufbewahrt: Sobald ein Run normal abgeschlossen ist, wird sein Inhalt verschlüsselt in der Datenbank gespeichert und die rohe Protokolldatei entfernt. Benutzer laden es aus der Anwendung selbst herunter (Export Run Logs, siehe Monitor and manage a run in DQE One Standalone).

Wenn die Konsolenausgabe Ihres Containers im Laufe der Zeit stark anwächst, prüfen Sie die Einstellungen Ihres Docker-Logging-Treibers — unsere Referenzkonfiguration begrenzt sie, Ihre kann jedoch anders konfiguriert sein.

Speicherplatz im Blick behalten

Die Umgebungsvariable DB_MAX_CAPACITY (in Byte) ist die einzige eingebaute Speicherschutzfunktion: Nähert sich die Größe Ihrer Datenbank diesem Wert, zeigen neue Datei-Uploads eine Warnung an, und es wird eine E-Mail versendet. Dies wird nur zum Zeitpunkt des Uploads geprüft, nicht fortlaufend, und die Schutzfunktion bewirkt nichts, wenn die Variable überhaupt nicht gesetzt ist.

Überwachen Sie die tatsächliche PostgreSQL-Größe und die Festplattennutzung des Hosts selbst mit Standardwerkzeugen, und erhöhen Sie DB_MAX_CAPACITY, sobald Ihre Daten wachsen — verlassen Sie sich nicht darauf, dass sie Sie proaktiv warnt.

Neu starten und prüfen, ob der Server läuft

Es gibt keinen eingebauten Health-Check-Endpunkt und standardmäßig keine konfigurierte Neustart-Richtlinie — stoppt der Container, bleibt er gestoppt, sofern Sie nicht selbst eine Neustart-Richtlinie festgelegt haben (zum Beispiel restart: unless-stopped in Ihrer Compose-Datei) oder ein externes Überwachungstool einsetzen. Eine schnelle Möglichkeit zu prüfen, ob die Anwendung antwortet, ist, ihre URL aufzurufen und eine Weiterleitung zur Anmeldeseite zu erwarten.

Einstellungen, die im Laufe der Zeit überprüft werden sollten

• Ihr Lizenzschlüssel (DQE_CLIENT_LICENCE) wird bei jeder Anmeldung geprüft — erneuern Sie ihn, bevor er abläuft, statt erst nachdem Benutzer blockiert werden.
• DB_MAX_CAPACITY — erhöhen Sie ihn, sobald Ihre Daten wachsen (siehe oben).

Verlieren Sie SECRET_ENCRYPTION_KEY niemals, und lassen Sie ihn nach dem Setzen nicht neu erzeugen: Ist er jemals nicht gesetzt, wird beim nächsten Start des Servers automatisch ein neuer erzeugt, wodurch sich alles, was mit dem vorherigen Schlüssel bereits gespeichert wurde (Credentials, Webhook-Geheimnisse, Run-Logs), nicht mehr entschlüsseln lässt. Bewahren Sie eine sichere Kopie davon außerhalb des Containers auf.

Grenzen

• Redis ist hier nicht nur ein Cache: Ein Neustart oder das Leeren von Redis führt zum Verlust laufender oder wartender Jobs sowie des von Index Records-Prozessen genutzten Suchindex (bei Bedarf durch erneutes Ausführen dieses Prozesses wiederherstellbar). Auch kurzlebige Anmeldecodes werden dort gespeichert, deren Verlust aber nur bedeutet, einen Anmeldeschritt zu wiederholen.
• Der Server übernimmt HTTPS nicht selbst — betreiben Sie ihn hinter Ihrem eigenen Reverse-Proxy mit einem gültigen Zertifikat, genau wie es bei der Ersteinrichtung bereits erforderlich war.