Die Sicherung war zwei Loecher gross -- gefunden, weil sie zum ersten Mal wirklich zurueckgespielt wurde

"Wir haben eine Sicherung" war bis heute ein Satz, kein Nachweis. Die
taegliche Kopie ausserhalb des Servers prueft `PRAGMA integrity_check`
und meldet seit dem 31.08. jeden Tag "in Ordnung". Das heisst: die Datei
ist nicht zerschossen. Es heisst NICHT, dass man damit weiterarbeiten
kann.

tools/wiederherstellung-proben.mjs geht den Weg jetzt wirklich: juengste
Sicherung in ein Wegwerf-Verzeichnis kopieren, die echte Anwendung
dagegen starten (damit laufen alle Schemawanderungen durch), vorher und
nachher zaehlen, anmelden, jede Seite aufrufen. Drei Ausgaenge, nicht
zwei -- "konnte nicht nachsehen" ist weder Erfolg noch Fehler.

BEIM ERSTEN LAUF BLIEB GENAU EINE VON ACHTZEHN SEITEN ROT: der
Steckbrief, mit einem 404 fuer ein Bild. Daran hingen zwei echte Luecken:

  1. PROFILBILDER WAREN NIE GESICHERT. sicherung-holen.sh holte
     dateien/ und wissen/ -- die Bilder liegen aber in einem dritten
     Ordner (profilbilder/, siehe workspace-steckbrief.js). Nach einem
     Plattenausfall waeren alle Profilbilder weg gewesen, waehrend die
     taegliche Meldung weiter "in Ordnung" sagte. Sie hat ja nie
     behauptet, vollstaendig zu sein.

  2. DIE RUECKMELDUNG AN DEN SERVER LIEF INS LEERE. Das Skript meldete
     sich bei dogfather-universe.com/workspace/... -- seit dem Umzug am
     06.09. antwortet diese Adresse mit 410 "Gone". Der Server erfuhr
     also seit dem Umzug nicht mehr, dass die Kopie laeuft; auf der
     Automationen-Seite waere sie mit jedem Tag aelter erschienen,
     obwohl sie taeglich lief. Ein 410 wird jetzt eigens gemeldet -- es
     heisst etwas anderes als "Netz kaputt", naemlich "die Adresse
     stimmt nicht mehr".

Beides behoben. Und damit es kein drittes Mal passiert, vergleicht die
Probe die Ordnerliste des Sicherungsskripts gegen die Ordner, die der
Server im Quelltext wirklich benutzt (`join(DATEN_ORDNER, "...")`). Wer
morgen einen vierten Datenordner anlegt und ihn nicht sichert, bekommt
hier einen Fehler statt eines stillen Lochs -- mit Gegenprobe, dass der
Vergleich einen fehlenden Ordner auch wirklich erkennt.

Ergebnis nach den Reparaturen: 18 Pruefungen, alle gruen,
"DIE SICHERUNG LAESST SICH ZURUECKSPIELEN." Der Lauf traegt sich mit
Datum in die Sicherungsablage ein -- sonst weiss beim naechsten Mal
niemand, wann zuletzt wirklich zurueckgespielt wurde.

Co-Authored-By: Claude Opus 5 <[email protected]>

tools/sicherung-holen.sh

@@ -41,12 +41,29 @@ scp -q dogfather-server:/home/dogiweb/workspace-daten/sicherungen/*.db "$ZIEL/"
 #
 # scp loescht nie etwas. Wer auf dem Server versehentlich ein PDF
 # entfernt, hat es hier weiterhin -- das ist Absicht, nicht Nachlaessigkeit.
-echo "Hole hochgeladene Dateien und die Bibliothek ..."
-mkdir -p "$ZIEL/dateien" "$ZIEL/wissen"
-scp -qr dogfather-server:/home/dogiweb/workspace-daten/dateien/. "$ZIEL/dateien/" 2>/dev/null || true
-scp -qr dogfather-server:/home/dogiweb/workspace-daten/wissen/.  "$ZIEL/wissen/"  2>/dev/null || true
+# PROFILBILDER GEHOEREN DAZU (ergaenzt 06.09.2026).
+#
+# Hier standen nur dateien/ und wissen/. Die Profilbilder liegen aber in
+# einem dritten Ordner (workspace-steckbrief.js: profilbilder/) -- und
+# der wurde nie mitgeholt. Nach einem Plattenausfall waeren alle Bilder
+# weg gewesen, obwohl "die Sicherung" jeden Tag gruen gemeldet hat.
+#
+# Gefunden hat das nicht das Nachdenken, sondern die Probe: Beim ersten
+# Lauf von tools/wiederherstellung-proben.mjs blieb genau eine von
+# achtzehn Seiten rot -- der Steckbrief, mit einem 404 fuer ein Bild.
+# Genau dafuer gibt es sie.
+#
+# Wer hier einen Ordner ergaenzt, traegt ihn auch in ORDNER unten ein;
+# die Probe vergleicht die Liste gegen die Ordner, die der Server
+# wirklich benutzt, und schlaegt bei einem vergessenen an.
+echo "Hole hochgeladene Dateien, Bilder und die Bibliothek ..."
+ORDNER="dateien wissen profilbilder"
+for o in $ORDNER; do
+  mkdir -p "$ZIEL/$o"
+  scp -qr "dogfather-server:/home/dogiweb/workspace-daten/$o/." "$ZIEL/$o/" 2>/dev/null || true
+done
 
-DATEIEN=$(find "$ZIEL/dateien" "$ZIEL/wissen" -type f 2>/dev/null | wc -l | tr -d ' ')
+DATEIEN=$(find $(for o in $ORDNER; do echo "$ZIEL/$o"; done) -type f 2>/dev/null | wc -l | tr -d ' ')
 echo "  $DATEIEN Datei(en) aus Ablage und Bibliothek"
 
 # Geprueft wird mit Node, nicht mit dem sqlite3-Programm: Node bringt
@@ -98,9 +115,19 @@ if [ -f "$SCHLUESSEL_DATEI" ]; then
     -H "Content-Type: application/json" \
     -H "X-Kopie-Schluessel: $SCHLUESSEL" \
     -d "{\"dateien\":$DATEIEN,\"sicherungen\":$ANZAHL,\"bytes\":$BYTES,\"rechner\":\"$(hostname)\"}" \
-    https://dogfather-universe.com/workspace/api/zustand/kopie || echo "000")
+    https://workspace.dogfather-universe.com/workspace/api/zustand/kopie || echo "000")
   if [ "$ANTWORT" = "200" ]; then
     echo "  Dem Server zurueckgemeldet."
+  elif [ "$ANTWORT" = "410" ]; then
+    # 410 heisst hier etwas Bestimmtes: Die ADRESSE stimmt nicht mehr.
+    # Genau das war am 06.09.2026 der Fall -- der Workspace ist auf
+    # workspace.dogfather-universe.com umgezogen, die alte Adresse
+    # antwortet seither mit 410 "Gone". Die Rueckmeldung lief seitdem
+    # ins Leere, und auf der Automationen-Seite waere die Kopie mit
+    # jedem Tag aelter erschienen, obwohl sie taeglich lief.
+    echo "  FEHLER: Der Server sagt 410 -- die Adresse in diesem Skript ist veraltet."
+    echo "          Aktuell: https://workspace.dogfather-universe.com"
+    notiere "Rueckmeldung 410: Adresse veraltet, Kopie selbst ist in Ordnung"
   else
     echo "  Hinweis: Rueckmeldung an den Server ging nicht (HTTP $ANTWORT)."
     notiere "Rueckmeldung fehlgeschlagen (HTTP $ANTWORT), Kopie selbst ist in Ordnung"