Commit Graph
1 Commits
Author SHA1 Message Date
D4rkst3randClaude Opus 5 720785c175 backup: die Sicherung verlaesst das Volume -- tools/abholen.ps1 plus Wachhund
Deploy / deploy (push) Canceled after 0s
Deploy / check (push) Canceled after 0s
Befund 1 aus docs/befunde-2026-08-12.md, der wichtigste: Datenbank und alle
vierzehn Sicherungen lagen im selben Volume. Geht das Volume verloren, geht
beides zusammen verloren -- das ist keine Sicherung, das ist eine Kopie.

tools/abholen.ps1 SICHERT NICHT. Das Archiv baut der Bot selbst; hier wird nur
abgeholt, und zwar so, dass am Ende feststeht, dass die Kopie heil ist und
nicht nur, dass ein Kopierbefehl keinen Fehler geworfen hat:

  1. neuestes Archiv im Container finden (und meckern, wenn es aelter als
     24 Stunden ist -- ein Skript, das treu das Archiv von vorletzter Woche
     abholt und "fertig" sagt, ist schlimmer als eines, das gar nicht laeuft)
  2. docker cp heraus
  3. Pruefsumme IM CONTAINER gegen die Kopie hier -- nicht die Dateigroesse:
     eine abgebrochene Kopie auf eine volle Platte hat oft genau die richtige
     Laenge und trotzdem Nullen am Ende
  4. auspacken und die Datenbank darin oeffnen, mit dem Bot-Abbild, weil dort
     better-sqlite3 schon liegt; integrity_check plus Tabellen zaehlen
  5. Bericht als last_zweitziel zurueck in die Einstellungen
  6. ausduennen

Und es warnt, wenn es DIESELBE PLATTE ist. Verglichen wird die physische Platte
und nicht der Laufwerksbuchstabe: zwei Partitionen derselben NVMe sterben
zusammen.

Echter Lauf, kein Trockentest:

    d4rkbot-2026-08-12.db.gz   993.332 Bytes
    andere Platte: Nr. 1 statt Nr. 0
    identisch (ff08516d293d...)
    in der Sicherung: 55 Tabellen, 86 Einstellungen

DAZU EIN ZWEITER WACHHUND, pruefeZweitziel(). Ein Skript auf dem Wirt, das
still aufhoert zu laufen -- Aufgabe deaktiviert, Laufwerk weg, Pfad geaendert --
waere derselbe Schaden noch einmal, nur eine Ebene weiter aussen. Er meldet nur,
wenn die Abholung schon einmal lief: fehlt der Eintrag ganz, ist sie nicht
eingerichtet, und daraus taeglich eine Meldung zu machen waere Naergelei.

Gegen eine Kopie der Datenbank durchgespielt:

    40 h alt   -> "alt:17863965"
    nochmal    -> unveraendert          (keine Wiederholung)
    Fehlschlag -> "fehler:1786540570974"
    wieder gut -> ""                    (Entwarnung)

Nebenbei gelernt, zum zweiten Mal in diesem Projekt: die Kopie der Datenbank
ohne -wal war leer an der Stelle, die zaehlte -- last_zweitziel stand noch im
Write-Ahead-Log. Dieselbe Falle wie beim Zurueckspielen von d4rk_media.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 15:17:01 +02:00