# Back-up en herstel

## Wat moet worden beschermd

Prioriteit:

1. PostgreSQL-database of lokale SQLite-database;
2. productie-`.env` en reverse-proxyconfiguratie, versleuteld en apart;
3. `media/` met gebruikersdocumenten/snapshots wanneer die functie actief is;
4. `config-data/` met niet-geheime bron- en profielconfiguratie;
5. immutable image/tag en de bijbehorende repositoryrelease.

Redis is een werkqueue/cache en hoeft normaal niet te worden hersteld. Ollama-modellen kunnen opnieuw worden gedownload; behoud alleen wanneer bandbreedte of modelbeschikbaarheid dat vereist.

## Minimumniveau

- database dagelijks;
- configuratie na iedere wijziging;
- minstens 7 dagelijkse en 4 wekelijkse herstelpunten;
- back-up op een ander fysiek of logisch opslagdoel;
- checksums op ieder archief;
- minstens per kwartaal een volledige hersteltest;
- gevoelige back-ups versleuteld at rest en tijdens transport.

## Repositoryscripts

```bash
./scripts/backup.sh
```

Het script gebruikt `pg_dump` wanneer `DATABASE_URL` PostgreSQL is en anders een kopie van `local/db.sqlite3`. Het maakt daarnaast een bestandsarchief en SHA-256-lijst. Voor productie moet de uitvoerdirectory naar een beschermd extern volume worden gesynchroniseerd; een back-up naast de live database is geen volwaardige back-up.

Herstel één databasebestand:

```bash
./scripts/restore.sh /pad/naar/vacatureradar-YYYYMMDDTHHMMSSZ.sql.gz
# of
./scripts/restore.sh /pad/naar/vacatureradar-YYYYMMDDTHHMMSSZ.sqlite3
```

## PostgreSQL-consistente back-up

Aanbevolen vanuit een beheercontainer of host met clienttools:

```bash
pg_dump --format=custom --no-owner --no-acl "$DATABASE_URL" \
  > vacatureradar-$(date -u +%Y%m%dT%H%M%SZ).dump
sha256sum vacatureradar-*.dump > SHA256SUMS
```

De huidige scriptvariant gebruikt gecomprimeerde SQL voor brede compatibiliteit. Een custom-formatdump maakt selectiever herstel mogelijk; kies één formaat en test exact dat formaat.

## Veilige herstelprocedure

1. Meld onderhoud en blokkeer externe toegang.
2. Stop scheduler en worker; stop daarna web zodat geen writes meer gebeuren.
3. Maak een forensische kopie van de defecte huidige database/volumes.
4. Verifieer checksum, datum, appversie en migratieniveau van de back-up.
5. Herstel naar een lege database of aparte testinstantie.
6. Gebruik de code/image die bij het back-upmoment hoort.
7. Voer migraties alleen vooruit uit nadat de restore op dat oude niveau goed opent.
8. Draai health, modelcounts, fixture-import en applicatiesmoke-test.
9. Start web, daarna worker en precies één scheduler.
10. Documenteer RPO/RTO, verloren wijzigingen en vervolgactie.

## Hersteltest

Een hersteltest is pas geslaagd wanneer:

- checksum is geverifieerd;
- database start zonder reparaties;
- migratiestatus verklaarbaar is;
- aantallen gebruikers, profielen, jobs, bronaliassen, sollicitaties en outboxrecords plausibel zijn;
- een bestaande vacaturedetailpagina opent;
- een fixture idempotent importeert;
- een score en digest kunnen worden aangemaakt;
- geen live mailbox of bron onbedoeld wordt gepolld in de testomgeving.

Pauzeer in een hersteltest alle `MailboxConnection`-records, gebruik `CELERY_TASK_ALWAYS_EAGER=1`, consolemail en geen live source polling. Bewaar `MAILBOX_CREDENTIAL_KEYS` afzonderlijk van de databaseback-up; zonder minstens één bijbehorende sleutel zijn opgeslagen app-wachtwoorden niet herstelbaar.

## Verwijdering en privacy

Back-ups verlengen feitelijk de bewaartermijn. Documenteer hoe verwijderde persoonsgegevens na de normale rotatie ook uit back-ups verdwijnen. Gebruik korte retentie voor ruwe vacaturemails en bewaar geen mailboxcredentials in databasedumps.