Back-up & Herstel

Wat je gegevens vasthoudt in een zelf-gehoste Conzent OCI-installatie, hoe je het op een schema kunt back-uppen en hoe je het op een nieuwe server kunt herstellen.

Back-up & Herstel

Alles wat Conzent opslaat, bevindt zich in Docker-volumes en één configuratiebestand. Deze pagina behandelt wat het waard is om te back-uppen, hoe je het kunt automatiseren en hoe je alles weer terug kunt krijgen.

Wat houdt je gegevens daadwerkelijk vast

Docker Compose maakt vijf benoemde volumes aan. Slechts twee bevatten iets dat je niet kunt opnieuw opbouwen.

Volume / bestand Inhoud Back-up maken?
oci-db-data MariaDB: sites, banners, toestemmingslogs, cookiecategorieën, beleidsregels, gebruikers, scanresultaten Ja — dit is alles
app-sites-data Gegevens van gegenereerde toestemmingsscripts Ja, hoewel opnieuw te genereren
.env Databasewachtwoord, scanner sleutel, inloggegevens van derden Ja — onvervangbaar
app-public Gebouwde CSS/JS-assets Nee — opnieuw opgebouwd vanuit de afbeelding
app-var Cache en logs Nee
oci-redis-data Sessies, takenwachtrij, beaconbuffer Nee — tijdelijk van aard

scripts/backup.sh legt precies de eerste drie vast, plus .conzent-credentials als het nog bestaat.

Toestemmingsscripts zijn inbegrepen omdat het herstellen ervan ervoor zorgt dat actieve banners blijven werken tijdens de minuten tussen een herstel en een regeneratie — maar ze zijn niet de bron van waarheid. Als ze volledig verloren gaan, php bin/oci scripts:regenerate bouwt elk van hen opnieuw op vanuit de database.

Een back-up maken

bash scripts/backup.sh

Dat schrijft backups/conzent-YYYYmmdd-HHMMSS.tar.gz met de volledige database dump, de gegenereerde toestemmingsscripts, je .env, en een manifest dat vastlegt wanneer het is gemaakt en van welke APP_URL.

bash scripts/backup.sh --output /mnt/backups     # schrijf ergens anders
bash scripts/backup.sh --keep 14                 # houd alleen de 14 nieuwste archieven

De dump gebruikt --single-transaction, zodat InnoDB-tabellen consistent worden vastgelegd zonder schrijfbewerkingen te blokkeren. Het is niet nodig om de applicatie eerst te stoppen.

Het archief bevat je database en je geheimen. Het wordt geschreven met modus 600. Behandel het als een wachtwoordbestand: sla het buiten de server op en versleutel het als het ergens gedeeld terechtkomt.

Automatiseren

Een nachtelijke back-up om 03:00, met behoud van twee weken:

0 3 * * * cd /path/to/conzent && /bin/bash scripts/backup.sh --keep 14 >> /var/log/conzent-backup.log 2>&1

Gebruik het absolute pad naar je installatiemap — cron erft de werkdirectory van je shell niet.

Een back-up op dezelfde schijf als de database is geen back-up. Voeg een offsite-stap toe:

15 3 * * * rsync -az /path/to/conzent/backups/ backup-host:/srv/conzent-backups/

Versleutel voordat het vertrekt als de bestemming niet van jou is: gpg --symmetric --cipher-algo AES256 backups/conzent-....tar.gz.

Herstellen

bash scripts/restore.sh backups/conzent-20260722-030000.tar.gz --yes

--yes is verplicht — het herstel vervangt de huidige database volledig. Wat het doet, in volgorde:

  1. Pak het archief uit en valideer het, druk het manifest af.
  2. Stop de applicatiecontainers, laat MariaDB draaien.
  3. Importeer de dump in de database die is genoemd in je huidige .env.
  4. Herstel het toestemmingsscripts-volume.
  5. Start alles weer op.
  6. Voer migrations:migrate uit, zodat een ouder archief wordt bijgewerkt naar het schema dat deze versie verwacht.
  7. Voer scripts:regenerate uit, zodat scripts worden opnieuw opgebouwd tegen je huidige APP_URL, niet de in het archief.
  8. Leeg Redis.

Stappen 6 en 7 zijn waarom een back-up gemaakt op old-domain.com schoon herstelt op een installatie die nu consent.example.com bedient.

Standaard blijft je bestaande .env ongemoeid. Om ook de versie van het archief te nemen, voeg --restore-env toe; je vorige bestand wordt bewaard als .env.before-restore-<timestamp>. Gebruik dat bij het opnieuw opbouwen van een verloren server, niet bij het terugdraaien van gegevens op een werkende — het gearchiveerde DB_PASSWORD komt niet overeen met een vers geïnitialiseerde database.

Een server vanaf nul opnieuw opbouwen

# 1. Verse installatie op de nieuwe machine
curl -sSL https://getconzent.com/install | sh -s -- --domain consent.example.com

# 2. Kopieer het archief over
scp backups/conzent-20260722-030000.tar.gz newhost:/root/conzent/

# 3. Herstel gegevens en configuratie
cd /root/conzent
bash scripts/restore.sh conzent-20260722-030000.tar.gz --yes --restore-env

# 4. Als het domein is veranderd, stel het in en genereer opnieuw
sed -i 's|^APP_URL=.*|APP_URL=https://consent.example.com|' .env
docker compose up -d
docker compose exec app php bin/oci scripts:regenerate

Voer een herstel-oefening uit

Een ongeteste back-up is een gok. Doe dit één keer, voordat je het nodig hebt:

  1. Noteer een sitenaam, de bannerinstellingen en het aantal toestemmingslogs van vandaag.
  2. Maak een back-up.
  3. Installeer op een aparte machine of VM vers en herstel het archief.
  4. Log in en bevestig dat de site, bannerconfiguratie en toestemmingslogs allemaal aanwezig zijn.
  5. Laad een pagina met de embed van die site en controleer of de banner nog steeds wordt weergegeven.

Tien minuten nu, in plaats van het gat tijdens een incident te ontdekken.

Voor elke upgrade

Updates behouden je database, maar maak toch eerst een back-up — een migratie is het enige dat een herstel niet kan ongedaan maken:

bash scripts/backup.sh --keep 14 && bash scripts/install.sh --update

De volledige referentie staat bij de code: docs/backup-restore.md op GitHub.

Terug naar Documentatie