Files
VacatureRadar/docs/operations/BACKUP_RESTORE.md
T
2026-07-22 05:12:07 +02:00

3.6 KiB

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

./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:

./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:

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.