feat(archive): BAK-03 Restore-Verfahren fuer Datenbank und Objekt-Storage
internal/restore: Atomarer Restore ueber Temp-Verzeichnis + Rename, nicht-leeres Ziel ohne -force bricht VOR jeder Beruehrung ab, JSONL- Protokoll jedes Laufs. Drei reale Defekte beim Bau gefunden und behoben: pg_combinebackup braucht Plain- statt Tar-Format (Extraktionsschritt ergaenzt), pg_wal.tar.gz wurde nie verifiziert/wiederhergestellt (BAK-01s Verify jetzt erweitert), Go-exec haengt bei pg_ctl start wegen vererbter Pipes (Testfix: echte Logdatei statt CombinedOutput). Beide Restore-Pfade real auf 131 ueber restore-cli nachgewiesen, inkl. echtem Postgres-Start aus wiederhergestelltem Verzeichnis.
This commit is contained in:
sysops
@@ -85,3 +85,13 @@ nachweislich am neuen Ort.
|
||||
real erfüllt — inklusive tatsächlicher systemd-Timer-Installation und
|
||||
manuell ausgelöstem End-to-End-Lauf aller drei Dienste auf dem Testhost,
|
||||
nicht nur isolierter Testcode.
|
||||
|
||||
## Nachtrag (BAK-03): Verify prüft jetzt auch pg_wal.tar.gz
|
||||
|
||||
Beim Bau von BAK-03s echtem Restore-Test fiel auf, dass `pg_basebackup`
|
||||
(Standard-WAL-Methode `stream`) bei `-Ft -z` NEBEN `base.tar.gz` eine
|
||||
zweite Archivdatei `pg_wal.tar.gz` erzeugt, die `Verify` bislang nie
|
||||
geprüft hat — eine Sicherung mit beschädigtem WAL-Archiv wäre unbemerkt
|
||||
nicht crash-konsistent wiederherstellbar gewesen. `Verify` prüft seither
|
||||
beide Archive vollständig (siehe `BAK-03-PRUEFPROTOKOLL.md`). Das
|
||||
Sicherungsverfahren selbst (Format, Ort, Rotation) bleibt unverändert.
|
||||
|
||||
@@ -0,0 +1,122 @@
|
||||
# BAK-03 – Prüfprotokoll: Restore-Verfahren
|
||||
|
||||
Voraussetzungen BAK-01, BAK-02 – erledigt, siehe eigene Protokolle.
|
||||
|
||||
## Grundsatzentscheidung: Atomarität über Temp-Verzeichnis + Rename
|
||||
|
||||
`internal/restore.AtomicRestore` kennt weder Postgres noch restic —
|
||||
reine Ablaufsteuerung: Wiederherstellung IMMER in ein frisches
|
||||
temporäres Verzeichnis (nie direkt in das Ziel), Übernahme erst bei
|
||||
Erfolg per `os.Rename` (selbes Dateisystem wie das Ziel, daher atomar).
|
||||
Ist das Ziel nicht leer und keine Bestätigung (`-force`) gegeben, wird
|
||||
NICHT einmal die Wiederherstellungsfunktion aufgerufen — Abbruch vor
|
||||
jeder Berührung des Ziels (Akzeptanzkriterium 2). Jeder Aufruf — Erfolg,
|
||||
Abbruch oder Fehler — erzeugt genau einen JSONL-Protokolleintrag
|
||||
(Akzeptanzkriterium 3).
|
||||
|
||||
Die eigentliche Wiederherstellung bleibt in `internal/backup.Restore`
|
||||
(Datenbank) und `internal/objectbackup.Restore` (Objekt-Storage) —
|
||||
`internal/restore` orchestriert nur.
|
||||
|
||||
## Drei reale Defekte während der Implementierung gefunden und behoben
|
||||
|
||||
Alle drei erst durch den ECHTEN Restore-Test (Postgres-Instanz tatsächlich
|
||||
gestartet, nicht nur Dateien verglichen) aufgedeckt:
|
||||
|
||||
1. **`pg_combinebackup` braucht Plain-Format, BAK-01 liefert Tar+Gzip.**
|
||||
`Restore` extrahiert jetzt jede Sicherungsstufe zunächst in ein
|
||||
temporäres Plain-Verzeichnis (inkl. `backup_manifest`-Kopie) und
|
||||
speist erst DIESE in `pg_combinebackup`. BAK-01s Speicherformat selbst
|
||||
unverändert (kleinere, leichter prüfbare Dateien).
|
||||
2. **`pg_wal.tar.gz` wurde nie verifiziert oder wiederhergestellt.**
|
||||
`pg_basebackup`s Standard-WAL-Methode (`stream`) erzeugt bei `-Ft -z`
|
||||
eine ZWEITE Archivdatei neben `base.tar.gz` — ohne sie ist keine
|
||||
crash-konsistente Wiederherstellung möglich (Postgres findet sonst
|
||||
keinen gültigen Checkpoint). `backup.Verify` prüft jetzt BEIDE
|
||||
Archive vollständig; `backup.Restore` extrahiert das WAL der ZULETZT
|
||||
gezogenen Stufe (nicht aller Stufen) nach `pg_wal/` im
|
||||
Wiederherstellungsziel. Ergänzung zu BAK-01s Prüfung, keine
|
||||
Umstellung des Sicherungsverfahrens.
|
||||
3. **Go-`exec`-Hänger bei `pg_ctl start`:** `pg_ctl` startet Postgres als
|
||||
Hintergrundprozess, der die geerbten stdout/stderr-Pipes NICHT
|
||||
schließt — `CombinedOutput()` (wartet auf Pipe-EOF) hängt sich
|
||||
dadurch auf, obwohl `pg_ctl` selbst längst zurückgekehrt ist. Fix nur
|
||||
im Testcode: echte Logdatei (`-l`) statt Pipe, Standard-`pg_ctl`-Muster.
|
||||
|
||||
Zusätzlich real (nicht Ticket-relevant, aber notiert): auf diesem
|
||||
Debian-Postgres liegen `postgresql.conf`/`pg_hba.conf` NICHT in PGDATA
|
||||
(sondern `/etc/postgresql/17/main/`) — ein echtes Restore-Runbook muss
|
||||
diese Dateien separat mitführen/rekonstruieren, `pg_basebackup` sichert
|
||||
sie nicht. Für den Testnachweis minimal nachgereicht, kein Produktcode.
|
||||
|
||||
## Umsetzung
|
||||
|
||||
- `internal/restore.AtomicRestore` — Ablaufsteuerung, JSONL-Protokoll
|
||||
(`Timestamp`, `Kind`, `Source`, `Target`, `Result`).
|
||||
- `internal/backup.Restore` — `pg_combinebackup` gegen extrahierte
|
||||
Plain-Verzeichnisse + WAL-Wiederherstellung der letzten Stufe.
|
||||
- `internal/backup.extractTarGz` (in `verify.go`, neben der bestehenden
|
||||
Tar/Gzip-Leselogik) — vollständige Extraktion, kein Kopf-only-Read.
|
||||
- `internal/backup.Verify` — prüft jetzt `base.tar.gz` UND
|
||||
`pg_wal.tar.gz` vollständig.
|
||||
- `internal/objectbackup.Restore` — `restic restore --target`.
|
||||
- `cmd/restore-cli` — `database`/`objects`-Unterbefehle, `-force`-Flag
|
||||
(vor Positionsargumenten, Go-`flag`-Konvention), kein systemd-Timer
|
||||
(Notfall-/Einzelfall-Werkzeug, kein Zeitplan).
|
||||
|
||||
## Prüfungen
|
||||
|
||||
| # | Prüfung | Ergebnis |
|
||||
|---|---|---|
|
||||
| 1 | Restore auf leerem System vollständig und erfolgreich durchgeführt | **bestanden** — real: `TestRestore_CombinesIntoStartablePostgresInstance` (Postgres tatsächlich aus wiederhergestelltem Verzeichnis gestartet, `SELECT 1` über echte Verbindung beantwortet); zusätzlich real per `restore-cli database` auf 131 ausgeführt (PG_VERSION/base/pg_wal vorhanden, Exit 0); `TestRestore_RecoversRealContentFromSnapshot` (Objekt-Storage, echter Dateiinhalt verglichen) UND real per `restore-cli objects` auf 131 (echter restic-Snapshot wiederhergestellt) |
|
||||
| 2 | Restore auf nicht-leeres Zielverzeichnis lässt bei Abbruch den ursprünglichen Inhalt unverändert | **bestanden** — `TestAtomicRestore_NonEmptyTargetWithoutForce_LeavesOriginalUntouched` (restoreFn wird nachweislich NIE aufgerufen) und `TestAtomicRestore_FailedRestoreFn_LeavesTargetUntouched`; real auf 131: `restore-cli database` gegen nicht-leeres Ziel ohne `-force` → Abbruch, bestehende Testdatei unverändert vorhanden |
|
||||
| 3 | Protokolleintrag zum Restore ist vollständig und nachvollziehbar | **bestanden** — `TestAtomicRestore_LogsCompleteEntry` (Quelle, Ziel, Zeitpunkt, Ergebnis für Erfolgs- UND Abbruchfall in derselben Datei); real auf 131: `/tmp/restore-cli-test.log` zeigt alle vier realen Läufe (Abbruch, Fehler mangels PATH, Erfolg, Force-Überschreiben) korrekt protokolliert |
|
||||
|
||||
Zusätzlich: `TestAtomicRestore_EmptyTarget_Succeeds`,
|
||||
`TestAtomicRestore_ForceOverwritesNonEmptyTarget` (bewusste Bestätigung
|
||||
ersetzt bestehenden Inhalt real, alter Inhalt nachweislich weg, neuer da).
|
||||
|
||||
## Echte Verdrahtung auf 192.168.1.131
|
||||
|
||||
- `restore-cli` gebaut nach `/opt/nexarch-archive/bin/`
|
||||
- Kein systemd-Timer (bewusst — Notfall-/Einzelfall-Werkzeug)
|
||||
- Vier reale CLI-Läufe durchgeführt und protokolliert: Abbruch bei
|
||||
nicht-leerem Ziel ohne `-force`, Fehler mangels `pg_combinebackup` im
|
||||
PATH (zeigt: Fehler wird korrekt erkannt UND protokolliert, kein
|
||||
stiller Fehlschlag), erfolgreicher Restore einer echten Generation
|
||||
(`20260829T222054Z`) in leeres Ziel, erfolgreiches Überschreiben mit
|
||||
`-force`. Objekt-Storage-Restore real gegen echten restic-Snapshot
|
||||
(`43da36bf`) — Inhalt (`.placeholder`-Datei) tatsächlich vorhanden.
|
||||
- Alle Testartefakte (`/tmp/restore-*`, Testlog) nach Prüfung entfernt.
|
||||
|
||||
## Build/Test-Ergebnis
|
||||
|
||||
```
|
||||
go build ./... -> clean
|
||||
go vet ./... -> clean
|
||||
golangci-lint run ./... -> 0 issues
|
||||
```
|
||||
|
||||
`internal/restore`: 5/5 Tests (reine Funktionen, kein Setup nötig).
|
||||
`internal/objectbackup`: `TestRestore_RecoversRealContentFromSnapshot`
|
||||
bestanden (zusammen mit den bestehenden BAK-02-Tests).
|
||||
`internal/backup`: `TestRestore_CombinesIntoStartablePostgresInstance`
|
||||
bestanden — **Hinweis**: dieser eine Test läuft NICHT als root
|
||||
(`pg_ctl: cannot be run as root`) und braucht `pg_combinebackup`/
|
||||
`pg_ctl` im PATH (`/usr/lib/postgresql/17/bin` auf Debian, dort nicht
|
||||
standardmäßig verlinkt) — daher separat als `postgres`-Systemnutzer mit
|
||||
entsprechendem PATH ausgeführt, nicht Teil des root-`make check`-Laufs;
|
||||
dort wird er mit klarer Meldung übersprungen (`pg_combinebackup nicht
|
||||
installiert`), kein stiller Fehlschlag. Alle übrigen BAK-01-Tests
|
||||
(inkl. der um `pg_wal.tar.gz` erweiterten `Verify`) liefen unverändert
|
||||
grün im normalen `make check`-Lauf.
|
||||
|
||||
## Gesamtergebnis
|
||||
|
||||
**Bestanden.** Alle drei Akzeptanzkriterien und alle drei
|
||||
Pflichtprüfungen real erfüllt — beide Restore-Pfade (Datenbank,
|
||||
Objekt-Storage) sowohl testgetrieben als auch manuell über `restore-cli`
|
||||
auf echter Infrastruktur nachgewiesen. Drei während der Implementierung
|
||||
gefundene reale Defekte (Tar-vs-Plain-Format, fehlende WAL-Sicherung/
|
||||
-Verifikation, Go-exec-Pipe-Hänger) behoben und dokumentiert, nicht
|
||||
stillschweigend umgangen.
|
||||
Reference in New Issue
Block a user