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.
65 lines
4.4 KiB
Markdown
65 lines
4.4 KiB
Markdown
# 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)
|
||
|
||
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. **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.
|
||
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).
|
||
|
||
## 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.
|