- archive/cmd/moduleadapter-api: startet den fertigen RET-05
RegisterHandler als eigenstaendigen HTTP-Dienst, Port 8095
- reines Wiring, kein Diff an internal/moduleadapter/ (verifiziert)
- real deployed auf 131, end-zu-ende per curl: Registrierung +
Idempotenz-Nachweis (widerspruechliche zweite Werte werden ignoriert,
urspruengliche Registrierung bleibt bestehen)
Pruefungen siehe archive/docs/RET-09-PRUEFPROTOKOLL.md
- internal/rbacclient: HTTP-Client fuer Core RBAC-06 (POST /authorize)
- retentionapi.RequireRole (Header-Provisorium) ersetzt durch
RequireRBAC, echter Aufruf gegen RBAC-06, fail-closed bei Fehlern
- Mount nimmt jetzt rbacclient.Client entgegen
- alle bestehenden RET-06-API-Tests weiterhin gruen
- neue Tests: verweigerte Rolle (403 gegen echte RBAC-06-Antwort),
erlaubte Rolle (200), RBAC-06 nicht erreichbar -> fail-closed (403)
- real deployed auf 131, end-zu-ende per curl nachgewiesen (403/403/200/403)
Pruefungen siehe archive/docs/RET-08-PRUEFPROTOKOLL.md
Board-Entscheidung: Backend-API zuerst, echtes Next.js-Frontend als
separates Folgeticket - vermeidet Pseudo-Frontend-Protokoll.
internal/retentionapi: 4 Endpunkte (anlegen/aendern, deaktivieren,
liste, vorschau), Vorschau nutzt dieselbe ListExpiringObjects-Funktion
wie RET-02s periodischer Job (keine Doppel-Implementierung).
RequireRole ist AUSDRUECKLICH kein RBAC-02-Ersatz, sondern ein
dokumentiertes Provisorium (Header-Check) - RBAC-02 ist reiner
Core-interner Go-Code ohne HTTP-Schnittstelle fuer andere Module,
derselbe Befund wie FDN-03/FDN-09. Provisorium real getestet inkl.
Negativfall (403 ohne/mit falscher Rolle). retention_class_rules um
active-Flag erweitert (deaktivieren ohne Historienverlust). Real auf
131 deployed und per curl end-to-end verifiziert.
internal/retentionengine: Frist je Aufbewahrungsklasse als natives
Postgres-INTERVAL, Stichtagsberechnung an Postgres delegiert statt
eigener Kalenderrechnung (Schaltjahr/Monatsende-Referenzwerte real
verifiziert: 2024-02-29+1y=2025-02-28, 2026-01-31+1mo=2026-02-28).
Periodischer Job (ListExpiringObjects) beschraenkt sich per DISTINCT ON
auf die juengste Klassenzuordnung je Objekt - sonst wuerden Objekte mit
mehrfach geaenderter Klasse (RET-01-Historisierung) doppelt auftauchen,
real mit einem Zwei-Zuordnungen-Testobjekt bewiesen. Scope bewusst eng
gehalten: keine RET-05-Anbindung, keine Vernichtungslogik - das ist
Ticket-Scope, dependsOn ist nur RET-01.
Vor Board-Flip bemerkt: Akzeptanzkriterium 1 fordert Objekttyp MIT
Aufbewahrungsklasse UND Rueckruf-Adresse, retention_class fehlte im
ersten Entwurf komplett. Migration, Registration-Struct, Register,
ListRegistrations und RegisterHandler ergaenzt, Tests angepasst
(Idempotenz jetzt auch fuer retention_class geprueft, nicht nur
callback_url). Real auf 131 gedroppt und neu angewendet.
internal/moduleadapter: Registrierungs-API + Rueckruf-Ausloeser fuer
DMS/Mail, bewusst NUR Archives eigene Seite - keine Modul-Empfaenger-
Implementierung (Nutzervorgabe: Interface zuerst festlegen, damit
DMS/Mail spaeter nicht gegen ein sich noch aenderndes Interface bauen).
Register ist ON-CONFLICT-DO-NOTHING (erneute Registrierung aendert nie
bestehende callback_url), NotifyDestruction echter HTTP-POST mit festem
DestructionNotice-Vertrag. Idempotenz sowohl auf Go- als auch HTTP-
Ebene bewiesen, Rueckruf gegen echten Testendpunkt verifiziert.
internal/retention: object_type/object_reference als reine Textfelder
(Adapter-Muster, keine Fremdschluessel auf DMS-/Mail-Tabellen).
Aufbewahrungsklassen-Zuordnung historisiert (jede Zuordnung eigene,
unveraenderliche Zeile). Migration real vorwaerts+rueckwaerts gegen
die tatsaechlichen .sql-Dateien getestet, Mandantentrennung gegen
echtes zweites Tenant-DB bewiesen. Grundlage fuer RET-05 (Adapter-
Interface) und RET-02.
Realer Restore-Testlauf (DB+Objekt) und Reconciliation frisch auf 131
ausgeloest, beide sauber (kein Fund). Fuenf offene Restrisiken
schriftlich benannt (Rotations-Kohaerenz, BAK-04-Rollenrechte fuer
produktive Mandanten, Storage-Provider-Grenze aus BAK-08, Core
FDN-03/FDN-09-Wiring-Luecke, leerer Testbestand). Unterschrift steht
aus - kann nicht durch das System selbst erfolgen.
Nutzerfrage: DB- und Objekt-Rotation laufen unabhaengig, kein Test/
Invariant stellt sicher, dass aeltester erreichbarer Snapshot und
aelteste erreichbare DB-Generation zeitlich zusammenpassen. Aktuell
identische keep-Werte sind Zufall, kein erzwungenes Verhalten - als
Folgepunkt dokumentiert, nicht Teil des Tickets.
internal/backup.PruneTiered: reine GFS-Funktion (Tag/Woche/Monat) fuer
Datenbank-Generationen, behaelt strukturell immer die neueste Generation
(Sicherheitsnetz gegen Legal-Hold-Kollision). internal/objectbackup.
PruneTiered: duenner Wrapper um restics native --keep-daily/-weekly/
-monthly-Staffelung. Beide CLIs nutzen die Staffelung, wenn konfiguriert,
bleiben sonst abwaertskompatibel zur flachen "letzte N"-Regel. Real
gegen zeitversetzt erzeugte restic-Snapshots getestet (Fund: restics
--time-Flag erwartet eigenes Format, nicht RFC3339), Pruning-Sicherheit
nach dem Loeschen alter Snapshots ueber vollstaendigen Restore +
restic check --read-data bewiesen. Beide Rotationswege real ueber
systemd auf 131 ausgeloest.
internal/tenantbackup: datenbank-scharfes pg_dump/pg_restore statt
BAK-01s Cluster-weitem pg_basebackup - bei Modell C (TEN-01, physisch
isolierte DB je Mandant) wuerde ein Cluster-Restore zwangslaeufig ALLE
Mandanten ueberschreiben. Objekt-Seite nutzt BAK-02 direkt (Mandanten
haben eigene Buckets/Pfad-Roots). Eigene Postgres-Rolle
nexarch_tenantbackup (CREATEDB, kein Superuser, getrennt von
nexarch_backup). Zwei-Tenant-Isolation real in beide Richtungen
bewiesen (Markerwert-Nachweis), JSONL-Protokoll fuer Sicherung UND
Restore. Realer End-zu-Ende-Lauf ueber tenantbackup-cli auf 131.
internal/restoretest wiederholt BAK-03s eigene Pruefdiskt als
Produktcode: echter Restore der neuesten Sicherung, echter Kurzstart
einer isolierten Postgres-Instanz, echte SELECT-1-Abfrage; Objekt-Seite
echter restic-Restore + Inhaltspruefung. JSONL-Historie (append-only),
sichtbare Warnung ueber denselben OPS-05-Pull-Weg wie BAK-08, eigenes
/metrics-Modul (archive-restoretest). Zwei reale Defekte gefunden und
behoben: Unix-Socket-Pfadlaenge unter tief verschachtelten Testpfaden,
restic-stderr-Vermischung beim JSON-Parsen unter dem Dienstnutzer.
Real auf 131 verdrahtet und ausgeloest (beide Testarten erfolgreich,
End-zu-Ende ueber OPS-03 bestaetigt).
internal/restore: Atomarer Restore ueber Temp-Verzeichnis + Rename,
nicht-leeres Ziel ohne -force bricht VOR jeder Beruehrung ab, JSONL-
Protokoll jedes Laufs. Drei reale Defekte beim Bau gefunden und behoben:
pg_combinebackup braucht Plain- statt Tar-Format (Extraktionsschritt
ergaenzt), pg_wal.tar.gz wurde nie verifiziert/wiederhergestellt (BAK-01s
Verify jetzt erweitert), Go-exec haengt bei pg_ctl start wegen vererbter
Pipes (Testfix: echte Logdatei statt CombinedOutput). Beide Restore-Pfade
real auf 131 ueber restore-cli nachgewiesen, inkl. echtem Postgres-Start
aus wiederhergestelltem Verzeichnis.
Report enthielt bisher nur Abweichungen. BAK-08 braucht eine
deterministisch sortierte Liste bestaetigt existierender Objekte als
Stichprobengrundlage, nicht nur "keine Abweichung". Ergaenzt vor
BAK-08-Start, real neu getestet (9/9) und auf 131 erneut ausgeloest.
Deterministischer Abgleich zwischen DMS file_revisions und
Objekt-Storage-Verzeichnis, existenz-only (keine Inhaltspruefung,
saubere Abgrenzung zu BAK-08). Report sortiert nach storage_key fuer
stabile Weiterverarbeitung durch BAK-08. Systemd-Timer taeglich,
real auf 192.168.1.131 verdrahtet und ausgeloest.
restic statt Eigenbau (Content-defined Chunking fuer Dedup, verschluesseltes
Repository ab Werk, geprueftes Tooling). internal/objectbackup wrapt
restic init/backup/check/forget ueber os/exec, cmd/objectbackup-cli fuer
systemd-Timer (stuendliche Sicherung, woechentliche Vollstaendigkeitspruefung,
taegliche Rotation).
Auf 192.168.1.131 real verifiziert (kein Mock): zweiter Lauf gegen
unveraenderten Bestand ueberraegt nichts (files_new=0), zwei identische
Dateien erzeugen nachweislich nur 1 data_blob (echter Dedup-Nachweis),
absichtlich gekipptes Byte in einer Pack-Datei wird von check --read-data
zuverlaessig erkannt. Echt verdrahtet: 3 systemd-Timer installiert+
aktiviert, jeder Dienst einmal end-to-end via systemctl start ausgeloest.
Im selben Rutsch BAK-01-Fund korrigiert: NEXARCH_BACKUP_DIR zeigte auf
/var/backups/nexarch (Root-Dateisystem, kein Dataset) statt auf das
persistente ZFS-Dataset /var/nexarch-archiv - korrigiert, erneut ausgeloest,
landet nachweislich am richtigen Ort. objectbackup-cli-Repository liegt von
Anfang an korrekt dort.
Siehe archive/docs/BAK-02-PRUEFPROTOKOLL.md fuer alle Pruefungsergebnisse.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
Neues Modul-Verzeichnis code/archive/ (Monorepo-Muster wie code/dms/).
PostgreSQL-17-natives inkrementelles Backup (pg_basebackup --incremental,
WAL-Summarization) statt WAL-Archiving, um den geteilten Testhost ohne
Neustart umzustellen (summarize_wal=on per pg_reload_conf). Rolle
nexarch_backup mit REPLICATION-Attribut angelegt.
internal/backup: FullBackup/IncrementalBackup (pg_basebackup-Wrapper),
Verify (vollstaendiges Lesen von base.tar.gz, gzip+tar, nicht nur Header),
Rotate/ListGenerations (generationsbasiert, aeltere zuerst entfernt).
cmd/backup-cli fuer systemd-Timer-Aufruf (deploy/systemd/
nexarch-archive-backup-*.timer, taeglich/stuendlich/taeglich).
Auf 192.168.1.131 verifiziert: 4/4 Tests gegen echte Postgres-17-Instanz
(kein Mock) - inkrementelle Sicherung real kleiner als Vollsicherung,
Verifikation erkennt absichtlich beschaedigte Datei, Rotation entfernt nur
die aeltesten Generationen. Zusaetzlich ECHT verdrahtet: backup-cli gebaut,
3 systemd-Timer installiert+aktiviert, jeder der drei Dienste einmal ueber
systemctl start end-to-end ausgeloest (status=0/SUCCESS je Dienst) - nicht
nur go test, sondern der reale Automatisierungspfad selbst geprueft.
Siehe archive/docs/BAK-01-PRUEFPROTOKOLL.md fuer alle Pruefungsergebnisse.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
sysops