Dokumente werden von keiner Sicherung erfasst #41
Notifications
Total Time Spent: 8 minutes
florian.wilde
8 minutes
No due date set.
Dependencies
No dependencies set.
Reference: florian.wilde/betreuungs-cockpit#41
Reference in New Issue
Block a user
Was fehlt
Der Sicherungsdienst führt täglich um 3:15 Uhr ausschließlich ein
pg_dumpaus (scripts/sicherung.sh). Die Dokumente liegen im Docker-Volumeminio-datenbzw. beim Dateitreiber unterDATEI_SPEICHER_PFADund werden nicht mitgenommen.Warum das schwer wiegt
Nach einem Plattenschaden ließe sich die Datenbank vollständig wiederherstellen — mit allen Akteneinträgen, Verweisen und Prüfsummen. Dahinter läge keine einzige Datei. Die Prüfsumme in der Akte belegt dann ein Dokument, das es nicht mehr gibt. Gegenüber dem Betreuungsgericht ist das der schlechteste denkbare Zustand: Die Akte behauptet einen Nachweis, den niemand vorlegen kann.
Bis 31.08.2026 war das folgenlos, weil der Objektspeicher leer war (siehe #41). Seit dem ersten abgelegten Schreiben ist es das nicht mehr.
Umsetzung
Die Dokumente in denselben Lauf aufnehmen wie die Datenbank — gleiche Verschlüsselung, gleiche Prüfsumme, gleiche Aufbewahrungsfrist.
Zwei Punkte, die dabei bedacht werden müssen:
tarüber das Volumenverzeichnis kann einen halbfertigen Stand erwischen. Sauberer istmc mirrorin ein Zwischenverzeichnis und erst davon die Sicherung.SPEICHER_TREIBER=dateifunktionieren, sonst hängt die Sicherung an der Speicherwahl.Akzeptanzkriterien
scripts/wiederherstellung.shstellt beides wieder her; danach ist ein zuvor abgelegtes Dokument über die Oberfläche abrufbar.INSTALLATION.mdbeschrieben, Wiederherstellung eingeschlossen.SICHERUNG_AUFBEWAHRUNG_TAGEgilt für beides.Korrektur zum Text oben: Der Verweis muss #42 lauten (leerer Objektspeicher wegen fehlgeschlagener Ablage), nicht #41 — das ist dieses Issue selbst. Beim Anlegen war die Nummer noch nicht vergeben.
🚀 Umgesetzt und nach
mainübernommen.Vorgehen
tar -tzf), nicht nur angetippt.tests/skripte.test.ts, gegen vier Mutationen abgesichert.Zwei Abweichungen von der Aufgabenstellung, beide begründet
Kein
mc mirror. Der MinIO-Client fehlt im Sicherungsbehälter und müsste bei jedem Lauf aus dem Netz geholt werden. Eine Internetabhängigkeit im Sicherungspfad ist das Letzte, was man dort will. Das rohe Verzeichnis ist vertretbar, weil MinIO Objekte erst vollständig unter.minio.sys/tmpschreibt und dann umbenennt — ein laufender Upload liegt nie halbfertig im Archiv, er fehlt höchstens.Nur Lesezugriff, und kein automatisches Zurückschreiben. Der Dienst läuft unbeaufsichtigt per cron. Ein Dienst, der die Daten zerstören kann, die er sichern soll, ist ein Risiko ohne Gegenwert — genau der Fall, gegen den eine Sicherung da ist. Deshalb
:ro, und deshalb packt die Wiederherstellung nach./backupsaus und gibt den letzten Handgriff als Einzeiler aus.Geprüft
Die Kernlogik einmal vollständig von Hand durchgespielt, nicht nur statisch geprüft:
725 Unit-Tests ·
tscsauber · Lint sauberBeim Ausrollen
docker compose up -derstellt den Sicherungsdienst neu — er braucht die neue Einhängung. Danach einmal von Hand:Erwartet:
Datenbank gesichert,Dokumente gesichert,Selbstpruefung bestanden - Datenbank und Dokumente.Der Notnagel von gestern (
docker run … tar czf … dokumente-<datum>.tar.gz) kann danach weg — er ist unverschlüsselt und ohne Rotation.Pull Request: #48 (gemergt)