From 480aa52941000e00197ea96316de6c890fe4b7f9 Mon Sep 17 00:00:00 2001 From: sysops Date: Sun, 30 Aug 2026 00:55:53 +0200 Subject: [PATCH] docs(archive): QA-04 Pruefgate Backup & Restore 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. --- archive/docs/QA-04-ABNAHMEPROTOKOLL.md | 61 ++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 archive/docs/QA-04-ABNAHMEPROTOKOLL.md diff --git a/archive/docs/QA-04-ABNAHMEPROTOKOLL.md b/archive/docs/QA-04-ABNAHMEPROTOKOLL.md new file mode 100644 index 0000000..fea0bc9 --- /dev/null +++ b/archive/docs/QA-04-ABNAHMEPROTOKOLL.md @@ -0,0 +1,61 @@ +# QA-04 – Abnahmeprotokoll: Prüfgate Backup & Restore + +Voraussetzung BAK-04, BAK-05, BAK-06, BAK-07 – alle Fertig, siehe +jeweilige Prüfprotokolle. Gate fasst deren Ergebnisse zusammen und +fordert einen ZUSÄTZLICHEN, eigenständigen Nachweis: ein realer +Restore-Lauf plus Reconciliation, ausgeführt als Abnahme-Handlung, +nicht nur als Entwicklungs-Test. + +## Prüfungen + +| # | Prüfung | Zielwert | Messwert | Bewertung | +|---|---|---|---|---| +| 1 | Realer Restore-Testlauf erfolgreich und protokolliert | Beide Restore-Arten (DB + Objekt) laufen ohne Fehler, real gegen 192.168.1.131 | `systemctl start nexarch-archive-restoretest.service` (2026-08-29 22:54:53 UTC): DB-Restore `erfolg=true` (Quelle `20260829T222054Z`), Objekt-Restore `erfolg=true` (Quelle `4af7bf18`); Ergebnis in `/var/nexarch-archiv/restoretest/history.log` protokolliert | **bestanden** | +| 2 | Reconciliation nach dem Testlauf liefert einen sauberen Bericht | `missing_in_storage`/`orphaned_in_storage` beide leer | `systemctl start nexarch-archive-reconcile.service` (2026-08-29 22:55:02 UTC): `{"missing_in_storage": null, "orphaned_in_storage": null, "existing_in_storage": null}` | **bestanden** | +| 3 | Offene Restrisiken sind schriftlich benannt | Vollständige, ehrliche Liste (siehe unten) | 5 Punkte identifiziert und dokumentiert | **bestanden** | + +## Offene Restrisiken (Akzeptanzkriterium/Pflichtprüfung 3) + +1. **Keine Kohärenz zwischen DB- und Objekt-Rotation** (BAK-07). Beide + Rotationswege laufen unabhängig, ohne Garantie, dass der älteste noch + erreichbare restic-Snapshot und die älteste noch erreichbare + DB-Generation zeitlich zusammenpassen. Aktuell identische + Keep-Werte sind Zufall, kein erzwungenes Invariant. +2. **BAK-04-Rollenrechte nicht automatisiert für produktive Mandanten.** + `nexarch_tenantbackup` braucht je Mandant manuell/administrativ + eingerichteten Lesezugriff (Rollenmitgliedschaft), bis TEN-01/TEN-07 + dies automatisiert bereitstellen. Aktuell nur für die Test-Tenant-DB + eingerichtet. +3. **BAK-08 deckt keine Storage-Provider-Lücke.** Der Scrub-Job erkennt + Abweichungen nur bei Objekten, die gelesen und erneut geprüft werden + können — ersetzt keine storage-seitige WORM-/Versionierungsstrategie + und keine Zugriffs-/Audit-Logs des Storage-Providers. Bei extern + eingebundenem, nicht-kompatiblem Kunden-Storage (Betriebsmodus 3, + ohne Versioning/Object Lock/Audit-Logs) bleibt eine technisch nicht + schließbare Lücke (aus dem BAK-08-Ticket selbst übernommen, hier + erneut benannt statt stillschweigend vorausgesetzt). +4. **Core FDN-03/FDN-09-Wiring-Lücke** (aus früheren Prüfprotokollen + bekannt, nicht Archive-Scope): Core-seitige Handler für Speicher- + Nutzungsmeldung und Tenant-KEK-Abruf existieren, sind aber in keinem + laufenden Core-Dienst registriert. Betrifft indirekt BAK-08s + OPS-05-Anbindung (funktioniert unabhängig davon, aber der breitere + Meldeweg für Speicher-Nutzung bleibt lückenhaft). +5. **`existing_in_storage`/Reconciliation-Basis aktuell leer im + Testsystem.** Der saubere Bericht dieses Gates (Prüfung 2) beweist + Abwesenheit von Abweichungen, nicht Abdeckung eines befüllten + Bestands — `dms_tenant_test` enthält aktuell keine Testdaten (von + früheren Testläufen geleert). Ein Gate-Wiederholungslauf mit echtem + Datenbestand vor Produktivbetrieb wird empfohlen. + +## Gesamtergebnis + +**Bestanden.** Alle drei Prüfungen real durchgeführt und dokumentiert. +Fünf Restrisiken benannt, keines davon blockiert die Freigabe der +Backup-Funktionen, alle sind entweder bereits als Folgeticket-Kandidaten +dokumentiert (1, 4) oder liegen strukturell außerhalb des +Archive-Moduls (2, 3) bzw. sind ein Hinweis für den Produktivbetrieb (5). + +**Abnahmeprotokoll:** technisch vollständig, alle drei Prüfungen real +durchgeführt (siehe oben) — Unterschrift steht noch aus, da eine +Unterzeichnung nicht durch das System selbst erfolgen kann. Ausstehend: +Bestätigung durch den Betreiber.