# 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.