backup_channel_id ist gesetzt. Vorher nachgesehen, ob der Bot den Kanal auch
bedienen KANN -- ein eingetragener Kanal, in dem er nicht posten darf, sieht
von aussen genauso aus wie ein richtig eingetragener:
Kanal #backup-upload-kanal Textkanal, richtige Gilde
Bot D4rk DevBot VIEW_CHANNEL, SEND_MESSAGES, ATTACH_FILES
Dann von Hand ausgeloest, und der ganze Weg lief durch -- inklusive der heute
gebauten Gegenpruefung:
[backup] d4rkbot-2026-08-12.db.gz erstellt (1021 KB),
geprueft: 55 Tabellen, 89 Einstellungen
last_backup 2026-08-12T13:54:44Z, last_backup_ok 1, kein Fehler
Der Zaehler der Einstellungen ist zwischen zwei Laeufen von 87 auf 89
gewachsen: das sind die Laeufe selbst, die last_backup schreiben. Ein huebscher
Beleg, dass wirklich das neue Archiv geoeffnet wurde und nicht ein altes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Abholung laeuft taeglich um 03:30 -- nach der Sicherung des Bots (ab 03:00)
und vor der von d4rk_media (04:30), damit nicht zwei Vorgaenge gleichzeitig auf
derselben Platte arbeiten.
Ueber die geplante Aufgabe gemessen, nicht von Hand: Ergebnis 0, Archiv auf
Platte Nr. 1 statt Nr. 0, Pruefsumme identisch, 55 Tabellen und 86
Einstellungen im ausgepackten Archiv, last_zweitziel steht in der Datenbank.
Zwei Dinge liegen ausserhalb des Repos und stehen deshalb im Bericht, damit sie
nach einem Neuaufsetzen nicht fehlen: die Arbeitskopie unter
Desktop\d4rkbot (vorher gab es gar keine, der Bot lief nur aus Portainers
Checkout) und die Aufgabe "d4rkbot Sicherung abholen". Sie startet pwsh ueber
den stabilen Ausfuehrungsalias und nicht ueber den Pfad mit Versionsnummer --
genau daran hing bei d4rk_media eine Sicherung, die beim naechsten
PowerShell-Update aufgehoert haette zu laufen.
Offen bleibt: beide Kopien liegen im SELBEN RECHNER. Gegen einen Plattenausfall
hilft das jetzt, gegen Feuer oder eine verschluesselte Maschine nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei falsche Diagnosen hintereinander, beide aus einem Zwischenstand
geschlossen, waehrend der Vorgang noch lief. Was wirklich passiert ist:
12:48:18 Push 93156e5
12:48 Portainer hat die Dateien im Stack-Verzeichnis
12:57 hier gemessen: Abbild 15 h alt, Container von gestern
-> daraus "er baut nicht" geschlossen. FALSCH.
13:01:02 Abbild neu gebaut
13:01:14 Container neu gestartet
13:02 pruefeSicherung im Container: 2, melden.js da, Panel HTTP 200
Zwischen Push und laufendem neuen Code liegen rund DREIZEHN MINUTEN -- Portainer
fragt in Intervallen nach, nicht sofort. Die Messung um 12:57 fiel mitten in
dieses Fenster: die Dateien waren schon da, das Abbild noch nicht neu. Aus dem
Schnappschuss habe ich einen Systemfehler gemacht.
Das ist genau der Fehler, gegen den der Bericht geschrieben ist -- eine
plausible Erklaerung, die zum Schnappschuss passt, behauptet, bevor der Vorgang
zu Ende war.
pull_policy: build bleibt drin, aber NICHT mehr aus dem Grund im Commit davor.
Es repariert nichts; es macht das Neubauen nur ausdruecklich, damit ein
handgetipptes `docker compose up -d` dasselbe tut wie die Automatik. Folgenlos
entfernbar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der erste Verdacht ("kein Runner") war die halbe Wahrheit. Portainers
GitOps-Weg funktioniert, nachgemessen in seinem eigenen Datenverzeichnis:
/d/compose/1/src/melden.js 12:48 <- die Uhrzeit des Pushes
/d/compose/1/stack.env 12:57 <- Portainer hat neu geschrieben
docker images d4rkbot:latest 00:21 <- das Abbild 15 Stunden alt
Portainer holt den neuen Stand also brav ins Stack-Verzeichnis und ruft dann
docker compose up -d. UND DAS BAUT NUR, WENN DAS ABBILD FEHLT. d4rkbot:latest
gab es -- also kein Bau, kein neuer Container, und der Bot lief weiter mit dem
Code von vorgestern.
Kein Runner, kein Webhook, keine Fehlermeldung: es sah nach "nichts zu tun"
aus. Das ist die unangenehme Sorte Fehler -- man pusht, hakt es ab, und der
Fehler, den man gerade behoben hat, laeuft weiter.
pull_policy: build laesst compose bei jedem Ausrollen neu bauen. Geprueft mit
docker compose config (v5.3.1 nimmt es an und gibt es aufgeloest zurueck).
Einmal noch von Hand, denn die Zeile wirkt erst, wenn sie selbst ausgerollt
ist: Portainer -> Stack ecobot -> Pull and redeploy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nach dem Push von 93156e5 nachgesehen, ob der Bot den neuen Stand bekommt:
Push registriert updated_at 12:48:18Z
Workflow-Laeufe "total_count": 0 <- keiner, nie
Act-Runner auf dem Wirt kein Container
d4rkbot neu gestartet? nein, laeuft seit 11.08. 22:21
Code im Container grep pruefeSicherung -> 0
has_actions ist am Repo AN, es gibt also nur niemanden, der die Laeufe
abarbeitet -- und der Webhook-Weg, der ohne Runner auskaeme, ist offenbar auch
nicht eingerichtet.
Pushen allein rollt also nichts aus. Das gehoert aufgeschrieben, weil ein
Deploy, von dem man GLAUBT dass er laeuft, schlimmer ist als gar keiner: man
pusht, hakt es ab, und der Fehler, den man gerade behoben hat, laeuft weiter.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Befund 2, 3 und 4 aus docs/befunde-2026-08-12.md. Befund 1 bleibt offen, Befund
5 war falsch und ist zurueckgezogen.
DER BOT SAGT JETZT BESCHEID. src/melden.js ist neu und enthaelt, was vorher in
watchdog.js eingeschlossen war: dmAdmin. Genau deshalb hat alles andere im Bot
geschwiegen oder in die Konsole geschrieben -- und eine Konsolenzeile in einem
Container liest niemand.
Dazu dmAdminEinmalig: meldet nur bei ZUSTANDSWECHSEL. Sonst wuerde eine
Pruefung, die alle zehn Minuten laeuft, denselben Ausfall alle zehn Minuten
melden, und nach der dritten DM liest man sie nicht mehr. Der Merker steht in
den Einstellungen und nicht im Arbeitsspeicher -- ein Bot, der nach jedem
Update neu startet, haette sonst nach jedem Update wieder eine frische Meinung.
Gemessen gegen eine KOPIE der Datenbank, sechs Schritte, alle wie beabsichtigt.
DER WACHHUND AUF last_backup. pruefeSicherung() meldet, wenn die letzte
Sicherung aelter als 26 Stunden ist, wenn sie fehlgeschlagen ist, oder wenn es
nie eine gab. Im Fehlerfall steht NICHT last_backup als Zeitpunkt im Embed: der
wird nur bei Erfolg gesetzt, dort staende also der letzte GUTE Lauf, und das
liesse die Sicherung frischer aussehen als sie ist.
DER TAG FAELLT NICHT MEHR AUS. Vorher "if (now.getHours() !== 3) return" -- wer
waehrend dieser einen Stunde unten war, hatte den Tag verloren, und ein Bot,
der nach jedem Update neu startet, ist genau dieser Fall. Jetzt zaehlt nur: es
ist nach 03:00 und heute war noch keine.
DAS ARCHIV WIRD AUSGEPACKT UND GEZAEHLT. integrity_check plus Tabellenzahl
gegen die laufende Datenbank. Faellt das durch, wird das Archiv GELOESCHT (im
Sicherungsordner saehe es sonst aus wie eine Sicherung), die Rotation laeuft
nicht, und last_backup bleibt stehen.
An echten Archiven gemessen, mit zwei Gegenproben, damit die Pruefung nicht nur
"ja" sagen kann:
2026-08-10 817 KB 54 Tabellen 86 ms
2026-08-11 886 KB 54 Tabellen 64 ms
2026-08-12 970 KB 55 Tabellen 78 ms (laufend: 55)
halbes gzip -> "unexpected end of file"
Muell -> "incorrect header check"
Die 54 gegen 55 sind kein Fehler, sondern eine gewachsene Tabelle zwischen dem
11. und dem 12. Verglichen wird zeitgleich, also stoert das nicht -- wissen
sollte man es, bevor jemand alte Archive gegen die heutige Zahl haelt.
BEFUND 5 WAR FALSCH. pruneMessageCache wird sehr wohl aufgerufen, taeglich, in
mod-tools.js:239 -- und stand schon zum Zeitpunkt der Durchsicht dort. Gezaehlt
wurden "Aufrufe ausserhalb von db.js", und die Sammel-Importzeile ist als
Import durchgegangen, waehrend der Aufruf zwanzig Zeilen tiefer nicht mitkam.
Das ist genau der Fehler, den zu vermeiden dieser Bericht dasteht; die anderen
vier sind deshalb einzeln nachgemessen worden und stimmen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gesucht wurde nach denselben Fehlermustern, die beim Bau von d4rk_media
aufgefallen sind. 24105 Zeilen liest niemand am Stueck; gesucht wurde gezielt
nach nie aufgerufenen Aufraeumfunktionen, Wachen an '*', SQL mit eingesetzten
Zeichenketten, fetch auf fremde Adressen, ungelesenen Antwortkoerpern,
Schleifen mit Zeitlimit und Sicherungen ohne Gegenprobe.
AN DIESEM BOT WURDE NICHTS GEAENDERT. Die Entscheidungen gehoeren dem
Betreiber.
DER WICHTIGSTE BEFUND: Datenbank (5,0 MB) und alle vierzehn Sicherungen
(5,7 MB) liegen im SELBEN Volume ecobot_ecobot_data. Geht es verloren, geht
beides zusammen verloren -- das ist keine Sicherung, das ist eine Kopie. Der
eingebaute Ausweg (Upload in einen privaten Discord-Kanal) laeuft nie, weil
backup_channel_id nicht gesetzt ist.
DAZU: niemand prueft last_backup. Es wird geschrieben und im Panel ANGEZEIGT,
aber nichts vergleicht es mit heute. Und weil der Zeitplan auf getHours() === 3
steht, faellt der Tag still aus, wenn der Bot waehrend dieser Stunde unten ist
-- bei einem Bot, der nach jedem Update neu startet, kein Sonderfall. Die
Maschinerie dafuer ist vollstaendig da (dmAdmin, brandEmbed, Incidents) und
wird nicht benutzt.
WEITER: "zu gross fuer Discord" endet in einem console.warn, das niemand liest;
die Archive wachsen um rund 70 KB je Tag auf eine Grenze von 9 MB zu. Das
Archiv wird nie ausgepackt und gegengeprueft. Und pruneMessageCache wird
nirgends aufgerufen -- exakt dasselbe Muster wie pruneEvents in d4rk_media,
heute mit 18 Zeilen harmlos.
WAS GEPRUEFT WURDE UND IN ORDNUNG IST, damit es niemand ein zweites Mal prueft:
db.backup() statt Dateikopie ist richtig und WAL-sicher; das gefaehrlich
aussehende ORDER BY ${ord} ist eine feste Weissliste; die oeffentliche
Serverliste zaehlt ihre Felder einzeln auf; die zwei bekannten Geheimnisse
gehen nur als Ja/Nein hinaus; der Spielserver-Monitor nutzt bereits
Promise.all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
D4rkst3randClaude Opus 5