sysops
480aa52941
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.
3.9 KiB
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)
- 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.
- BAK-04-Rollenrechte nicht automatisiert für produktive Mandanten.
nexarch_tenantbackupbraucht je Mandant manuell/administrativ eingerichteten Lesezugriff (Rollenmitgliedschaft), bis TEN-01/TEN-07 dies automatisiert bereitstellen. Aktuell nur für die Test-Tenant-DB eingerichtet. - 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).
- 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).
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_testenthä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.