Säkerhetskopiera & Återställ

Vad som håller din data i en självhostad Conzent OCI-installation, hur du säkerhetskopierar den enligt schema och hur du återställer den på en ny server.

Säkerhetskopiera & Återställ

Allt som Conzent lagrar finns i Docker-volymer och en konfigurationsfil. Denna sida täcker vad som är värt att säkerhetskopiera, hur man automatiserar det och hur man får tillbaka allt.

Vad som faktiskt håller din data

Docker Compose skapar fem namngivna volymer. Endast två innehåller något som du inte kan återskapa.

Volym / fil Innehåll Säkerhetskopiera?
oci-db-data MariaDB: webbplatser, banners, samtyckesloggar, cookie-kategorier, policyer, användare, skanningsresultat Ja — detta är allt
app-sites-data Genererade samtyckesskript Ja, även om de kan regenereras
.env Databaslösenord, skannernyckel, tredjepartsuppgifter Ja — oersättlig
app-public Byggda CSS/JS-tillgångar Nej — återskapas från bilden
app-var Cache och loggar Nej
oci-redis-data Sessioner, jobbkö, beacon-buffer Nej — tillfällig av design

scripts/backup.sh fångar exakt de första tre, plus .conzent-credentials om den fortfarande finns.

Samtyckesskript ingår eftersom återställning av dem håller aktiva banners fungerande under minuterna mellan en återställning och en regenerering — men de är inte källan till sanningen. Om de skulle gå förlorade helt, php bin/oci scripts:regenerate återskapar var och en från databasen.

Ta en säkerhetskopiering

bash scripts/backup.sh

Det skriver backups/conzent-YYYYmmdd-HHMMSS.tar.gz som innehåller hela databasdumpen, de genererade samtyckesskripten, din .env, och en manifest som registrerar när den togs och från vilken APP_URL.

bash scripts/backup.sh --output /mnt/backups     # skriv någon annanstans
bash scripts/backup.sh --keep 14                 # behåll endast de 14 nyaste arkiven

Dumpen använder --single-transaction, så InnoDB-tabeller fångas konsekvent utan att blockera skrivningar. Det är inte nödvändigt att stoppa applikationen först.

Arkivet innehåller din databas och dina hemligheter. Det skrivs i läge 600. Behandla det som en lösenordsfil: lagra det utanför servern, och kryptera det om det hamnar någonstans delat.

Automatisera det

En nattlig säkerhetskopiering klockan 03:00, som behåller två veckor:

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

Använd den absoluta sökvägen till din installationskatalog — cron ärver inte din skals arbetskatalog.

En säkerhetskopiering på samma disk som databasen är ingen säkerhetskopiering. Lägg till ett offsite-steg:

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

Kryptera innan det lämnar om destinationen inte är din: gpg --symmetric --cipher-algo AES256 backups/conzent-....tar.gz.

Återställning

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

--yes är obligatoriskt — återställningen ersätter den nuvarande databasen helt. Vad den gör, i ordning:

  1. Packar upp och validerar arkivet, skriver ut dess manifest.
  2. Stoppar applikationscontainrarna, medan MariaDB fortsätter att köra.
  3. Importerar dumpen till databasen som anges i din nuvarande .env.
  4. Återställer samtyckesskripten volym.
  5. Startar allt igen.
  6. Kör migrations:migrate, så ett äldre arkiv uppdateras till det schema som denna version förväntar sig.
  7. Kör scripts:regenerate, så skripten återskapas mot din nuvarande APP_URL, inte den i arkivet.
  8. Flushar Redis.

Steg 6 och 7 är varför en säkerhetskopiering som togs på old-domain.com återställer rent på en installation som nu serverar consent.example.com.

Som standard lämnas din befintliga .env orörd. För att ta arkivets version också, lägg till --restore-env; din tidigare fil sparas som .env.before-restore-<timestamp>. Använd den när du återskapar en förlorad server, inte när du återställer data på en fungerande — den arkiverade DB_PASSWORD kommer inte att matcha en nyinitierad databas.

Återskapa en server från grunden

# 1. Ny installation på den nya maskinen
curl -sSL https://getconzent.com/install | sh -s -- --domain consent.example.com

# 2. Kopiera arkivet
scp backups/conzent-20260722-030000.tar.gz newhost:/root/conzent/

# 3. Återställ data och konfiguration
cd /root/conzent
bash scripts/restore.sh conzent-20260722-030000.tar.gz --yes --restore-env

# 4. Om domänen har ändrats, ställ in den och regenerera
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

Kör en återställningsövning

En otestad säkerhetskopiering är en gissning. Gör detta en gång, innan du behöver det:

  1. Notera ett webbplatsnamn, dess bannerinställningar och dagens samtyckesloggantal.
  2. Ta en säkerhetskopiering.
  3. På en separat maskin eller VM, installera nytt och återställ arkivet.
  4. Logga in och bekräfta att webbplatsen, bannerkonfigurationen och samtyckesloggarna alla finns där.
  5. Ladda en sida som bär den webbplatsens inbäddning och kontrollera att bannern fortfarande visas.

Tio minuter nu, jämfört med att upptäcka gapet under en incident.

Innan varje uppgradering

Uppdateringar bevarar din databas, men ta en säkerhetskopiering först ändå — en migrering är den enda sak som en återställning inte kan ångra:

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

Den fullständiga referensen finns med koden: docs/backup-restore.md på GitHub.

Tillbaka till Dokumentation