Der erste echte Lauf hat einen Mangel sichtbar gemacht, den das Skript
selbst verursacht hat: root legt Dateien standardmaessig mit 644 an,
also welt-lesbar. Nachgemessen als gewoehnliches Konto, ohne sudo: Die
Sicherung liess sich nach /tmp kopieren und daraus Kundennamen,
E-Mail-Adressen und Paketwahl auslesen; das Upload-Archiv ebenso. Auf
dieser Maschine bestehen fuenf Konten.
Eine Sicherung buendelt an einer Stelle, was sonst verstreut liegt --
sie muss enger geschuetzt sein als das Original, nicht lockerer.
umask 077 fuer alles Neue; fuer die bereits angelegten Verzeichnisse
zusaetzlich ausdruecklich 700 bzw. 600, denn umask wirkt nur auf neu
Erzeugtes.
Der gleiche Mangel besteht beim Original selbst (644 dogiintern) --
das kann ich nicht aendern, es gehoert nicht mir. Wird gemeldet.
Co-Authored-By: Claude Opus 5 <[email protected]>
Bisher gab es keine Sicherung. Ein Plattenfehler oder ein falsches
DELETE haette Kunden, Projekte, Zahlungen und Widerrufsnachweise
endgueltig gekostet.
sicherung.sh legt taeglich einen Stand an -- mit SQLites eigenem
".backup", nicht mit "cp". Der Grund ist messbar: Die Datenbank ist
778 KB gross, ihr WAL 4,1 MB. Eine Kopie der .db allein waere also
nicht bloss veraltet, sondern weitgehend leer. Ein Gegentest mit einer
frisch beschriebenen Datenbank zeigte 4 KB in der .db gegen 2,1 MB im
WAL.
Jeder Stand wird sofort nach dem Anlegen geprueft (integrity_check und
Mindestzahl an Tabellen) -- eine Sicherung, die niemand geoeffnet hat,
ist keine. 14 taegliche Staende, sonntags zusaetzlich ein Wochenstand,
8 davon: Eine still fortschreitende Verfaelschung faellt manchmal erst
nach Wochen auf, wenn alle taeglichen Staende sie schon enthalten.
wiederherstellen.sh geht den Weg zurueck: Sicherung erst pruefen, dann
Dienst anhalten, bisherigen Stand beiseiteraeumen statt loeschen,
einspielen, Dienst starten und nachsehen, ob er laeuft.
Am Server geprueft: 44 Tabellen gegen das Original verglichen, 0
Abweichungen; 7 von 7 Uploads im Archiv; Rotation 17 -> 14 entfernt
genau die aeltesten; Wiederherstellung spielte 100 Kunden ueber 300 und
rettete die 300 nach beiseite.
Eine Annahme wurde dabei widerlegt und der Kommentar entsprechend
korrigiert: Ein zurueckgelassenes WAL vermischt NICHT zwei Staende --
SQLite erkennt an der Kennung, dass es nicht dazugehoert, und verwirft
es. Der echte Schutz ist das Anhalten des Dienstes.
Co-Authored-By: Claude Opus 5 <[email protected]>
DogFatherGitandClaude Opus 5