sysops
d0b6fb8ce5
Rotations-Kohaerenz explizit als NICHT geloest markiert, Nachhol- Pruefung als solche gekennzeichnet (kein archaeologisches Protokoll), Zwei-Namen-Unterschrift (Umsetzung + Gegenzeichnung). Bedingungen des Betreibers erfuellt, Gegenzeichnung erteilt.
4.4 KiB
4.4 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 | Nachhol-Prüfung (dedizierter Abnahme-Lauf für dieses Gate, NICHT identisch mit BAK-06s eigenem Entwicklungstest): 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 |
Nachhol-Prüfung, im selben Abnahme-Durchgang direkt nach Prüfung 1 ausgelöst: 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. Ausdrücklich NICHT gelöst: ein Restore-Punkt ist nur dann belastbar, wenn zum selben Zeitpunkt sowohl ein restic-Snapshot als auch eine DB-Generation existieren — das ist aktuell nicht sichergestellt.
- 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).
Unterschriften
- Umsetzung: Claude (Agent), 2026-08-30 — alle Prüfungen durchgeführt, Protokoll erstellt.
- Gegenzeichnung geprüft: Betreiber, 2026-08-30 — unter den drei Bedingungen (Rotations-Kohärenz als offenes Restrisiko benannt, Nachhol-Prüfung explizit gekennzeichnet, Zwei-Namen-Unterschrift) bestätigt.