⚠️ Hinweis zum Node-/Cluster-System

Das Node- und Cluster-System (Controller/Node-Modus, Heartbeats, Log-Sync zwischen Servern) ist derzeit noch nicht produktionsreif. Es wird aktiv weiterentwickelt. Für den Einsatz in Produktion solltet ihr euch vorerst auf Einzel-Server-Betrieb oder die dokumentierten Features beschränken und das Cluster-Feature nur testweise nutzen.

⚠️ Note on Node/Cluster System

The node and cluster system (controller/node mode, heartbeats, log sync between servers) is not yet production-ready. It’s still under active development. For production use, stick to single-server operation or other documented features for now, and use the cluster feature only for testing.

Deutsch

Überblick über die Änderungen – Logs, Backup-Verlauf, S3 und ein paar Kleinigkeiten.

Logs in der Oberfläche

In den Log-Ansichten (System, Chat, Command, Network) wird jetzt durchgehend vollständiges Datum und Uhrzeit angezeigt. Die Anzeige liest die Zeitstempel zuverlässig aus den Backend-Daten (createdAt / timestamp), sodass die Einträge chronologisch sinnvoll sind.

Die Logger-Spalte hat eine feste Breite und bricht bei langen Namen sauber um – die Meldungen stehen dadurch ruhiger und lesbarer da. Stacktraces (z. B. Java-Fehler) werden weiterhin in einem eigenen Block (<pre>) dargestellt. Auf Syntax-Highlighting per HTML in den Log-Texten wurde verzichtet, damit keine Tags als Text durchrutschen; die Struktur (Zeilenumbrüche, Einrückungen) bleibt erhalten.

Backup-Verlauf („Note-System“ / Backup-Logs)

Die Backup-Historie (Erfolge, Fehler, geplante Läufe) wird in der Log-Datenbank geführt und in der UI angezeigt. Dafür gibt es u. a.:

• Einträge mit Status SUCCESS, FAILED oder SKIPPED
• Speicherort, Größe, Dauer, Fehlermeldung (bei Fehlern)
• Vermeidung von Schema-Fehlern beim erneuten Initialisieren: Es wird geprüft, ob die Spalte server_name schon existiert, bevor ein ALTER TABLE ausgeführt wird – damit entfällt der Fehler „Duplicate column name 'server_name'“.

Die Fortschrittsanzeige beim Backup wurde verbessert: Direkt nach dem Start erscheint z. B. „Starte Backup…“, danach Phasen wie „Zippen“ und „Hochladen“ inkl. Prozent und übertragene Bytes. Während des Zippens wird per Callback die Anzahl verarbeiteter Dateien gemeldet, damit die Anzeige nicht stehen bleibt. Die API wertet außerdem den Wert accepted der Server-Antwort aus – so wird korrekt angezeigt, ob ein Backup wirklich gestartet wurde oder ob bereits eines läuft. Tritt früh ein Fehler auf (z. B. ungültige S3-Konfiguration), wird der Lauf als FAILED geloggt und in der UI angezeigt, statt still zu enden.

Übersetzungen (i18n) für Server-Logs

Die Texte für Server-Logs (z. B. „ZIP wird erstellt…“, S3-Meldungen) liegen jetzt in den gleichen Übersetzungsdateien wie das Frontend (htdocs/i18n/de.json, en.json). Eine kleine Java-Hilfsklasse (Messages) lädt diese JSON-Dateien (orientiert an der JVM-/OS-Sprache) und stellt die Übersetzungen bereit. Die bisherigen .properties-Dateien für diese Meldungen wurden entfernt. Im Frontend lädt der Sprachumschalter die verfügbaren Sprachen dynamisch aus htdocs/i18n/index.json – neue Sprachen lassen sich so durch eine weitere JSON-Datei und einen Eintrag in index.json ergänzen.

S3 Backup: Fehler sichtbar und sauber beendet

Wenn der S3-Client oder der Storage-Provider beim Erstellen scheitert (ungültiger Endpoint, Credentials, etc.), blieb die UI früher bei „Starte Backup…“ ohne weitere Logs. Das ist behoben:

• Fehler beim Erstellen des Storage-Providers werden abgefangen: Exception inkl. Stacktrace auf System.err, Eintrag in der Backup-Historie mit Status FAILED und Fehlermeldung, Fortschritt in der UI auf FAILED gesetzt, running zurückgesetzt.
• Vor dem S3-Verbindungstest erscheint eine Meldung wie „S3-Verbindung wird getestet…“ (i18n-Key: backup.s3.connection.test).

S3: Leerer Endpoint führt nicht mehr zu NPE

Bei leerem Endpoint-Feld (z. B. für normales AWS S3) wurde endpointOverride(null) aufgerufen – die AWS SDK wirft dann eine NPE. Jetzt wird endpointOverride nur noch gesetzt, wenn ein nicht leerer Endpoint konfiguriert ist. Ist das Feld leer, nutzt die SDK den Standard-Endpoint der gewählten Region.

S3 Endpoint: Automatisches „https://“

Ein reiner Hostname wie nbg1.your-objectstorage.com wurde bisher unverändert übergeben; die SDK erwartet aber eine URL mit Schema. Es gibt jetzt eine Hilfsmethode normalizeEndpoint(): Fehlt http:// oder https://, wird automatisch https:// vorangestellt. Bestehende Schemata bleiben unverändert; „www“ wird nicht ergänzt.

English

Overview of what changed – logs, backup history, S3, and a few smaller bits.

Logs in the UI

In the log views (System, Chat, Command, Network), full date and time are now shown consistently. The UI reads timestamps correctly from the backend (createdAt / timestamp), so the order makes sense.

The logger column has a fixed width and wraps long names cleanly, so messages line up better. Stack traces (e.g. Java errors) are still rendered in a <pre> block. We avoided injecting HTML for syntax highlighting into log text so that no tags show up as plain text; line breaks and indentation are preserved.

Backup history (“note system” / backup logs)

The backup history (successes, failures, scheduled runs) is stored in the log database and shown in the UI. This includes:

• Entries with status SUCCESS, FAILED, or SKIPPED
• Storage location, size, duration, and error message when something fails
• A schema fix: we check whether the server_name column already exists before running ALTER TABLE, so you no longer get “Duplicate column name 'server_name'” on re-init.

Backup progress in the UI was improved: right after starting you see e.g. “Starting backup…”, then phases like “Zipping” and “Uploading” with percentage and bytes transferred. During zipping, a callback reports how many files have been processed so the UI doesn’t look stuck. The API also respects the server’s accepted value so it’s clear whether a backup actually started or one was already running. If something fails early (e.g. invalid S3 config), the run is logged as FAILED and shown in the UI instead of ending with no feedback.

Translations (i18n) for server logs

Server log texts (e.g. “ZIP is being created…”, S3 messages) now live in the same translation files as the frontend (htdocs/i18n/de.json, en.json). A small Java helper (Messages) loads these JSON files (based on JVM/OS language) and provides the strings. The old .properties files for these messages were removed. The frontend language switcher loads available languages from htdocs/i18n/index.json, so adding a new language is done by adding a JSON file and an entry in index.json.

S3 backup: errors visible and clean shutdown

When the S3 client or storage provider failed to be created (invalid endpoint, credentials, etc.), the UI used to stay on “Starting backup…” with no logs. That’s fixed:

• Storage provider creation errors are caught: exception and stack trace go to System.err, an entry is written to the backup history with status FAILED and the error message, progress in the UI is set to FAILED, and running is reset.
• Before the S3 connection test, a message like “Testing S3 connection…” is shown (i18n key: backup.s3.connection.test).

S3: empty endpoint no longer causes NPE

With an empty endpoint field (e.g. for standard AWS S3), the code called endpointOverride(null), and the AWS SDK throws an NPE. Now endpointOverride is only set when a non-empty endpoint is configured. If the field is empty, the SDK uses the default endpoint for the selected region.

S3 endpoint: automatic “https://”

A bare hostname like nbg1.your-objectstorage.com was passed through as-is; the SDK expects a URL with a scheme. A helper normalizeEndpoint() was added: if the value doesn’t start with http:// or https://, https:// is prepended. Existing schemes are left as-is; “www” is not added.