Ops: automatizált restore-próba (a mentés visszaállíthatóságának bizonyítása)

[Xentinus]

Jelenség

A mentés automatizált, a visszaállítás ellenőrzése nem.

Ami megvan: a deploy/backup.sh systemd timerről fut (deploy/systemd/portfoliocms-backup.timer), a dumpot visszaolvasással ellenőrzi, age-dzsel titkosítja, rclone-nal offsite tolja, és a deploy előtt is lefut. A deploy/restore.sh-nak már van drill módja is:

bash deploy/restore.sh <dump> --into portfoliocms_drill
    Drill. Creates a scratch database, restores into it, prints what came back, and leaves
    the live database untouched. Safe to run on production hosts.

Ami nincs: semmi nem futtatja ezt magától. A drill kézi művelet, tehát a gyakorlatban akkor derül ki, hogy a mentés visszaállítható-e, amikor már vissza kell állítani. A dump visszaolvasási ellenőrzése (pg_restore --list) nem ugyanaz: azt mondja meg, hogy a fájl nem csonka, nem azt, hogy a séma és az adat használható belőle.

A titkosított offsite ág külön kockázat: ha a BACKUP_AGE_IDENTITY kulcs elveszik vagy nem az, amivel a titkosítás készült, az összes offsite dump használhatatlan — és ez ma semmilyen ellenőrzésen nem esik át.

Javaslat

1. Ütemezett drill: portfoliocms-restore-drill.service + .timer (heti), ami a legutóbbi dumpot --into portfoliocms_drill módban visszaállítja, majd eldobja a scratch adatbázist.
2. A drill állításokat is tegyen, ne csak fusson le: a fő táblák sorszáma nem nulla (Works, Skills, Experiences, About), és a legutóbbi UpdatedAt nem régebbi egy határértéknél. Egy sikeresen visszaállított, de üres adatbázis ma zöldnek látszana.
3. Az offsite, titkosított ág legyen a drill forrása, ne a helyi dump — az a példány, ami tényleg kellene katasztrófa esetén. Ez egyben a BACKUP_AGE_IDENTITY kulcsot is ellenőrzi.
4. Riasztás: a timer hibás unitja önmagában senkit nem ébreszt fel. Vagy OnFailure= unit, ami értesítést küld (a Feat: SMTP értesítés új kapcsolati üzenetről #52 SMTP küldője ide is használható), vagy egy külső dead-man-switch (healthchecks.io jellegű): a drill siker esetén pingel, elmaradó ping = riasztás. Az utóbbi azt is észreveszi, ha a gép egyáltalán nem fut.
5. Erőforrás: a drill idejére a Postgres konténer terhelést kap. Éjszakai időpont, és a docker-compose.yml-ben beállított memória-limit figyelembevétele.
6. A deploy/RUNBOOK.md egészüljön ki azzal, hol látszik a legutóbbi sikeres drill eredménye, és mit kell tenni, ha elhasal.

Érintett fájlok

• új deploy/systemd/portfoliocms-restore-drill.service, .timer
• deploy/restore.sh (drill mód állításokkal, gépi olvasható kimenettel)
• deploy/backup.sh (ha az offsite letöltés innen kerül ki közös függvénybe)
• deploy/RUNBOOK.md
• .env.example (riasztási cél, dead-man-switch URL)