Backup e Ripristino
Tutto ciò che Conzent memorizza vive in volumi Docker e in un file di configurazione. Questa pagina tratta ciò che vale la pena di eseguire il backup, come automatizzarlo e come recuperarlo tutto.
Cosa contiene effettivamente i tuoi dati
Docker Compose crea cinque volumi nominati. Solo due contengono qualcosa che non puoi ricostruire.
| Volume / file | Contenuti | Eseguire il backup? |
|---|---|---|
oci-db-data | MariaDB: siti, banner, registri di consenso, categorie di cookie, politiche, utenti, risultati della scansione | Sì — questo è tutto |
app-sites-data | Script di consenso generati | Sì, anche se rigenerabili |
.env | Password del database, chiave dello scanner, credenziali di terze parti | Sì — insostituibile |
app-public | Asset CSS/JS costruiti | No — ricostruiti dall'immagine |
app-var | Cache e registri | No |
oci-redis-data | Sessioni, coda di lavoro, buffer del beacon | No — transitorio per design |
scripts/backup.sh cattura esattamente i primi tre, più .conzent-credentials se esiste ancora.
Gli script di consenso sono inclusi perché ripristinarli mantiene i banner attivi durante i minuti tra un ripristino e una rigenerazione — ma non sono la fonte della verità. Se venissero completamente persi, php bin/oci scripts:regenerate ricostruisce ognuno di essi dal database.
Eseguire un backup
bash scripts/backup.sh
Questo scrive backups/conzent-YYYYmmdd-HHMMSS.tar.gz contenente il dump completo del database, gli script di consenso generati, il tuo .env, e un manifesto che registra quando è stato eseguito e da quale APP_URL.
bash scripts/backup.sh --output /mnt/backups # scrivi da un'altra parte
bash scripts/backup.sh --keep 14 # mantieni solo i 14 archivi più recenti
Il dump utilizza --single-transaction, quindi le tabelle InnoDB vengono catturate in modo coerente senza bloccare le scritture. Non è necessario fermare prima l'applicazione.
L'archivio contiene il tuo database e i tuoi segreti. È scritto in modalità 600. Trattalo come un file di password: conservalo al di fuori del server e criptalo se finisce in un luogo condiviso.
Automatizzarlo
Un backup notturno alle 03:00, mantenendo due settimane:
0 3 * * * cd /path/to/conzent && /bin/bash scripts/backup.sh --keep 14 >> /var/log/conzent-backup.log 2>&1
Usa il percorso assoluto della tua directory di installazione — cron non eredita la directory di lavoro della tua shell.
Un backup sullo stesso disco del database non è un backup. Aggiungi un passaggio offsite:
15 3 * * * rsync -az /path/to/conzent/backups/ backup-host:/srv/conzent-backups/
Cripta prima che esca se la destinazione non è tua: gpg --symmetric --cipher-algo AES256 backups/conzent-....tar.gz.
Ripristino
bash scripts/restore.sh backups/conzent-20260722-030000.tar.gz --yes
--yes è obbligatorio — il ripristino sostituisce completamente il database attuale. Cosa fa, in ordine:
- Estrae e convalida l'archivio, stampando il suo manifesto.
- Ferma i contenitori dell'applicazione, lasciando MariaDB in esecuzione.
- Importa il dump nel database nominato nel tuo attuale
.env. - Ripristina il volume degli script di consenso.
- Riavvia tutto.
- Esegue
migrations:migrate, quindi un archivio più vecchio viene aggiornato allo schema che questa versione si aspetta. - Esegue
scripts:regenerate, quindi gli script vengono ricostruiti contro il tuo attualeAPP_URL, non quello nell'archivio. - Flusha Redis.
I passaggi 6 e 7 sono il motivo per cui un backup eseguito su old-domain.com si ripristina correttamente su un'installazione che ora serve consent.example.com.
Per impostazione predefinita, il tuo .env esistente viene lasciato intatto. Per prendere anche la versione dell'archivio, aggiungi --restore-env; il tuo file precedente viene mantenuto come .env.before-restore-<timestamp>. Usalo quando ricostruisci un server perso, non quando ripristini i dati su uno funzionante — la DB_PASSWORD archiviata non corrisponderà a un database appena inizializzato.
Ricostruire un server da zero
# 1. Installazione fresca sulla nuova macchina
curl -sSL https://getconzent.com/install | sh -s -- --domain consent.example.com
# 2. Copia l'archivio
scp backups/conzent-20260722-030000.tar.gz newhost:/root/conzent/
# 3. Ripristina dati e configurazione
cd /root/conzent
bash scripts/restore.sh conzent-20260722-030000.tar.gz --yes --restore-env
# 4. Se il dominio è cambiato, impostalo e rigenera
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
Eseguire un drill di ripristino
Un backup non testato è una supposizione. Fai questo una volta, prima di averne bisogno:
- Annota un nome di sito, le sue impostazioni banner e il conteggio dei registri di consenso di oggi.
- Esegui un backup.
- Su una macchina o VM separata, installa fresco e ripristina l'archivio.
- Accedi e conferma che il sito, la configurazione del banner e i registri di consenso siano tutti presenti.
- Carica una pagina che porta l'incorporamento di quel sito e controlla che il banner venga ancora visualizzato.
Dieci minuti ora, rispetto a scoprire il gap durante un incidente.
Prima di ogni aggiornamento
Gli aggiornamenti preservano il tuo database, ma esegui comunque un backup prima — una migrazione è l'unica cosa che un ripristino non può annullare:
bash scripts/backup.sh --keep 14 && bash scripts/install.sh --update
Il riferimento completo vive con il codice: docs/backup-restore.md su GitHub.