Backup e Disaster Recovery PrestaShop — Guida Completa alla Protezione

Perché i backup sono più importanti di quanto pensiate

Ogni proprietario di un negozio PrestaShop pensa “a me non succederà” — finché non succede. I backup sono la rete di sicurezza più importante che la vostra attività online possieda. Ecco scenari reali che si verificano regolarmente nella comunità PrestaShop:

L’aggiornamento fallito: Aggiornate da PS 1.7 a 8.x. Il processo si blocca a metà delle migrazioni del database. Il vostro catalogo è parzialmente convertito, gli ordini hanno colonne non corrispondenti e il back office non si carica. Senza un backup pre-aggiornamento, il vostro negozio è in un limbo
Il negozio hackerato: Un attaccante sfrutta un modulo non aggiornato, inietta backdoor e modifica il vostro .htaccess. Lo scoprite giorni dopo. Poiché anche i file core sono stati modificati, non potete distinguere quali file siano puliti. Solo un backup precedente alla violazione può ripristinare la fiducia
Il disastro dell’hosting: L’array RAID del vostro host si guasta. Il loro backup più recente risale a 9 giorni fa. Il vostro backup era sullo stesso server. Nove giorni di ordini, clienti e modifiche — persi
La cancellazione accidentale: Qualcuno elimina /img/p/ pensando che sia una directory temporanea. Migliaia di foto prodotto, cancellate in pochi secondi

La domanda non è se avrete bisogno di un backup — è quando. Ogni settimana in cui operate senza backup testati è una scommessa con l’intera vostra attività.

Cosa salvare nel backup

Il database (il più critico)

Il vostro database MySQL/MariaDB contiene tutto ciò che rende il vostro negozio un’attività: ordini, account clienti, prodotti, configurazione, regole carrello, dati SEO e account dipendenti. Se perdete i file ma conservate il database, potete ricostruire. Se perdete il database, avete perso i dati della vostra attività.

File essenziali

/modules/ — moduli installati, le loro configurazioni, template e risorse caricate
/themes/ — il vostro tema attivo e i temi child con tutte le personalizzazioni
/img/ — immagini prodotto, immagini categorie, immagini CMS (spesso la directory più grande — 10GB+)
/upload/ — allegati e file di prodotti virtuali
/override/ — override personalizzati delle classi core
/app/config/parameters.php (PS 1.7+) o /config/settings.inc.php (PS 1.6) — credenziali del database e chiavi di crittografia
/mails/ e /translations/ — se personalizzati
.htaccess, configurazioni virtual host, override di php.ini, definizioni cron
Certificati SSL — se gestiti autonomamente (non tramite Cloudflare o il vostro host)

Cosa NON serve salvare

/var/cache/ — rigenerata automaticamente
/var/logs/ — utile per il debug, non per il ripristino
/vendor/ — reinstallabile tramite composer install
/node_modules/ — non fate mai il backup di questa directory
/var/sessions/ — dati temporanei

Metodi di backup del database

mysqldump (consigliato)

Lo standard di riferimento per i backup MySQL/MariaDB:

mysqldump \
  --single-transaction \
  --quick \
  --lock-tables=false \
  --routines \
  --triggers \
  --events \
  -u YOUR_DB_USER \
  -p'YOUR_DB_PASSWORD' \
  YOUR_DB_NAME > prestashop_$(date +%Y%m%d_%H%M%S).sql

Perché ogni flag è importante:

--single-transaction — snapshot InnoDB consistente senza bloccare le tabelle. Il vostro negozio resta operativo con zero downtime
--quick — recupera le righe una alla volta invece di caricare intere tabelle in memoria
--lock-tables=false — impedisce il blocco delle tabelle MyISAM che alcune installazioni PS più vecchie utilizzano ancora
--routines, --triggers, --events — include stored procedure, trigger ed eventi programmati che i moduli possono creare

Non saltate mai --single-transaction su un negozio in produzione. Senza di esso, mysqldump blocca le tabelle durante il backup, potenzialmente bloccando il checkout per secondi o minuti.

Esportazione phpMyAdmin

Per hosting condivisi senza SSH: selezionate il vostro database, cliccate su Export, scegliete il metodo Custom, abilitate la compressione gzip, spuntate “Add DROP TABLE” ed esportate. Limitazione: può andare in timeout su database superiori a 100MB.

Backup integrato di PrestaShop

Disponibile in Advanced Parameters → DB Backup. Comodo per un rapido snapshot prima di una modifica, ma con serie limitazioni: salta trigger/routine, può andare in timeout su database di grandi dimensioni, salva il backup sullo stesso server, e alcune versioni di PS producono dump incompleti. Usatelo solo come supplemento.

Compressione e automazione

I dump SQL si comprimono dell’80-90%. Passate sempre attraverso gzip:

# Backup + compress in one step
mysqldump --single-transaction --quick --lock-tables=false \
  -u USER -p'PASS' prestashop | gzip > backup_$(date +%Y%m%d).sql.gz

# Restore from compressed backup
gunzip < backup_20260228.sql.gz | mysql -u USER -p'PASS' prestashop

Backup giornaliero automatizzato con rotazione

Questo script mantiene 7 backup giornalieri, 4 settimanali e 12 mensili:

#!/bin/bash
# /home/user/scripts/backup-db.sh

DB_USER="your_db_user"
DB_PASS="your_db_password"
DB_NAME="prestashop"
BACKUP_DIR="/home/user/backups/database"
DATE=$(date +%Y%m%d_%H%M%S)
DAY_OF_WEEK=$(date +%u)
DAY_OF_MONTH=$(date +%d)

mkdir -p "$BACKUP_DIR"/{daily,weekly,monthly}

# Take the backup
mysqldump --single-transaction --quick --lock-tables=false \
  --routines --triggers \
  -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" \
  | gzip > "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz"

if [ $? -ne 0 ]; then
    echo "BACKUP FAILED at $(date)" | mail -s "BACKUP FAILED" your@email.com
    exit 1
fi

# Weekly snapshot (Sunday)
[ "$DAY_OF_WEEK" -eq 7 ] && cp "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz" \
  "$BACKUP_DIR/weekly/prestashop_weekly_${DATE}.sql.gz"

# Monthly snapshot (1st of month)
[ "$DAY_OF_MONTH" -eq "01" ] && cp "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz" \
  "$BACKUP_DIR/monthly/prestashop_monthly_${DATE}.sql.gz"

# Rotation
find "$BACKUP_DIR/daily/"   -name "*.sql.gz" -mtime +7   -delete
find "$BACKUP_DIR/weekly/"  -name "*.sql.gz" -mtime +28  -delete
find "$BACKUP_DIR/monthly/" -name "*.sql.gz" -mtime +365 -delete

# Add to crontab — runs daily at 3:00 AM
0 3 * * * /home/user/scripts/backup-db.sh >> /home/user/logs/backup.log 2>&1

Metodi di backup dei file

Backup completo con tar

# Full backup excluding unnecessary directories
tar -czf prestashop_files_$(date +%Y%m%d).tar.gz \
  --exclude='var/cache/*' --exclude='var/logs/*' \
  --exclude='var/sessions/*' --exclude='node_modules' \
  /var/www/html/

# Critical files only (faster, smaller)
tar -czf prestashop_critical_$(date +%Y%m%d).tar.gz \
  /var/www/html/{modules,themes,img,upload,override,mails,.htaccess} \
  /var/www/html/app/config/parameters.php

Backup incrementale con rsync

Per negozi di grandi dimensioni, rsync copia solo i file modificati — ideale per l’enorme directory /img/:

# Local incremental sync
rsync -avz --delete \
  --exclude='var/cache/' --exclude='var/logs/' --exclude='var/sessions/' \
  /var/www/html/ /home/user/backups/files/current/

# Remote sync (off-site — much safer)
rsync -avz --delete \
  --exclude='var/cache/' --exclude='var/logs/' \
  -e "ssh -p 22" \
  /var/www/html/ backupuser@remote-server:/backups/prestashop/

Le immagini prodotto in /img/p/ cambiano raramente dopo il caricamento, rendendo rsync estremamente efficiente — dopo la copia completa iniziale, le sincronizzazioni giornaliere trasferiscono solo le immagini appena aggiunte.

Dove conservare i backup

NON sullo stesso server

Questo è l’errore numero uno nei backup. Se i vostri backup sono sullo stesso server, un guasto al disco, un ransomware o un fallimento dell’hosting cancellano tutto simultaneamente. I backup devono esistere in almeno una posizione fisica separata.

Opzioni di storage remoto

# Amazon S3
aws s3 sync /home/user/backups/ s3://your-bucket/prestashop/ --storage-class STANDARD_IA

# Backblaze B2 (cheaper than S3, excellent for backups)
b2 sync /home/user/backups/ b2://your-bucket/prestashop/

# Google Cloud Storage
gsutil cp backup.sql.gz gs://your-bucket/prestashop/database/

# SCP/rsync to another server
rsync -avz -e ssh /home/user/backups/ backupuser@backup-server:/backups/prestashop/

La regola 3-2-1

Conservate 3 copie dei vostri dati su 2 tipi di storage diversi con 1 copia off-site. Per PrestaShop: il vostro negozio live + un backup locale su un disco separato + un backup cloud in una regione diversa.

Crittografia dei backup (GDPR)

I backup del database contengono dati personali dei clienti. In base al GDPR, dovete proteggere questi dati anche nei backup:

# Encrypt with GPG
mysqldump --single-transaction --quick --lock-tables=false \
  -u USER -p'PASS' prestashop | gzip \
  | gpg --symmetric --cipher-algo AES256 --batch --passphrase "STRONG_PASSPHRASE" \
  > backup_$(date +%Y%m%d).sql.gz.gpg

# Decrypt and restore
gpg --decrypt --batch --passphrase "STRONG_PASSPHRASE" backup.sql.gz.gpg \
  | gunzip | mysql -u USER -p'PASS' prestashop

Conservate la passphrase di crittografia in un password manager — separatamente dai backup. Se perdete la passphrase, i backup crittografati saranno permanentemente irrecuperabili.

Testare i backup

Un backup che non avete testato non è un backup. Problemi comuni che emergono solo durante un ripristino reale: dump SQL troncati (limite di spazio su disco), file da 0 byte (password DB scaduta), incompatibilità di versione MySQL, permessi file mancanti, directory critiche escluse o chiavi di crittografia modificate.

Come testare

# Create a test database and restore
mysql -u root -p -e "CREATE DATABASE prestashop_test;"
gunzip < backup.sql.gz | mysql -u root -p prestashop_test

# Verify data completeness
mysql -u root -p prestashop_test -e "
  SELECT COUNT(*) AS products FROM ps_product;
  SELECT COUNT(*) AS orders FROM ps_orders;
  SELECT COUNT(*) AS customers FROM ps_customer;
  SELECT MAX(date_add) AS latest_order FROM ps_orders;
"

Per un test completo: estraete il backup dei file, aggiornate parameters.php, caricate il sito, verificate che la homepage si carichi con le immagini, che il login al Back Office funzioni, che i prodotti vengano visualizzati correttamente e che il checkout funzioni. Programmate questo test ogni trimestre.

Piano di disaster recovery

Scrivete queste procedure e conservatele in un luogo accessibile anche quando il vostro server non è raggiungibile.

Scenario 1: negozio completamente offline (guasto del server)

Confermate la portata del problema — il vostro server, la rete dell’host o il DNS?
Contattate il provider di hosting; ottenete un ETA e confermate lo stato dei dati
Se irrecuperabile: provisionate un nuovo server con versioni OS/PHP/MySQL corrispondenti
Ripristinate i file dal vostro backup remoto (non quello sul server guasto)
Ripristinate il database dal backup off-site più recente
Aggiornate il DNS se l’IP è cambiato
Verificate front office, back office, checkout ed email

Scenario 2: database corrotto

Fermate il web server: systemctl stop apache2
Provate prima la riparazione: mysqlcheck -u root -p --auto-repair prestashop

Se la riparazione fallisce, ripristinate dal backup:

mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
gunzip < latest_backup.sql.gz | mysql -u root -p prestashop

Riavviate il web server, svuotate la cache di PrestaShop
Valutate la perdita di dati — controllate gli ID degli ordini e i timestamp per identificare il gap

Scenario 3: hackerato — file modificati

Mettete il sito offline immediatamente
Preservate le prove: tar -czf hacked_site.tar.gz /var/www/html/

Identificate il vettore di attacco:

find /var/www/html/ -name "*.php" -mtime -7 -ls
grep -rl "eval(base64_decode" /var/www/html/
grep -rl "shell_exec" /var/www/html/modules/

Ripristinate i file da un backup datato prima della violazione
Controllate il database per account admin sospetti e modifiche di configurazione anomale
Cambiate TUTTE le credenziali: password DB, password admin, FTP, chiavi SSH, chiavi API
Aggiornate il core di PrestaShop e tutti i moduli
Monitorate attentamente per 2-4 settimane — gli attaccanti spesso lasciano backdoor multiple

Scenario 4: cancellazione accidentale di modulo/tema

Estraete solo la directory eliminata dal vostro backup dei file:

tar -xzf prestashop_files_backup.tar.gz \
  --directory /var/www/html/ var/www/html/modules/your_module_name/

Se il modulo è stato disinstallato tramite Back Office (tabelle DB rimosse), ripristinate anche il database oppure reinstallate dallo ZIP originale
Svuotate la cache di PrestaShop

RTO e RPO

RTO (Recovery Time Objective) — tempo massimo di inattività accettabile. Un RTO di 4 ore significa che il vostro processo di ripristino deve completarsi in meno di 4 ore. Un RTO di 15 minuti richiede un’infrastruttura di failover automatizzata
RPO (Recovery Point Objective) — perdita massima di dati accettabile. Backup giornalieri = RPO di 24 ore. I negozi ad alto volume (centinaia di ordini al giorno) dovrebbero puntare a un RPO di 1-4 ore

Calcolate il vostro costo: 100 ordini al giorno con una media di 50 EUR = circa 200 EUR/ora in mancato fatturato durante il downtime, più danni alla fiducia e al SEO.

Ripristino point-in-time

I backup giornalieri lasciano un gap: se il problema si è verificato 2 ore fa e il vostro ultimo backup risale a 20 ore fa, perdete 20 ore di dati. I binary log di MySQL risolvono questo problema.

Abilitare il binary logging

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
log_bin = /var/log/mysql/mysql-bin
binlog_expire_logs_seconds = 604800
max_binlog_size = 100M
binlog_format = ROW

systemctl restart mysql
mysql -u root -p -e "SHOW VARIABLES LIKE 'log_bin';"  # Should show ON

Ripristino a un momento specifico

# 1. Restore the most recent full backup (from 3:00 AM)
gunzip < daily_backup.sql.gz | mysql -u root -p prestashop

# 2. Replay binlogs up to the moment BEFORE the problem (e.g., 14:29)
mysqlbinlog \
  --start-datetime="2026-02-28 03:00:00" \
  --stop-datetime="2026-02-28 14:29:00" \
  /var/log/mysql/mysql-bin.000042 /var/log/mysql/mysql-bin.000043 \
  | mysql -u root -p prestashop

Questo vi restituisce lo stato esatto del database un minuto prima dell’incidente. Casi d’uso: cancellazioni massive accidentali, importazioni fallite o recupero di ordini effettuati tra l’ultimo backup e un guasto del modulo.

I binlog aumentano l’utilizzo del disco — un negozio attivo genera centinaia di MB al giorno. Impostate binlog_expire_logs_seconds per bilanciare la capacità di ripristino con lo spazio su disco. Sette giorni è un buon valore predefinito.

Backup del provider di hosting: fidatevi ma verificate

La maggior parte degli host pubblicizza “backup giornalieri” ma la realtà è spesso diversa:

“Backup regolari” può significare settimanali, non giornalieri
Il ripristino può costare 50-200 EUR a richiesta e richiedere 24-48 ore
Di solito non potete ripristinare singoli file o tabelle — è tutto o niente
La retention è spesso limitata a 2-3 copie
Molti ToS includono clausole di “non responsabilità per la perdita di dati”

Per verificare: Chiedete al vostro host cosa viene salvato, con quale frequenza, dove vengono conservati i backup e quanti ne vengono mantenuti. Poi richiedete un ripristino di prova in una directory temporanea. Controllate il pannello di controllo per le date dei backup — se il più recente risale a 3 settimane fa, avete un problema.

L’hosting condiviso ha limitazioni aggiuntive: i backup possono escludere account superiori a 10GB, potreste non avere accesso SSH per mysqldump, e il ripristino sovrascrive sempre lo stato attuale. Integrate con esportazioni phpMyAdmin e download FTP periodici delle directory critiche.

Considerate i backup del vostro host come una rete di sicurezza aggiuntiva, mai come la vostra strategia principale. I vostri dati, la vostra responsabilità.

Checklist completa per i backup

Stampate questa lista e revisionate ogni trimestre.

Giornaliero (automatizzato)

☐ Il backup del database viene eseguito tramite cron e produce un file di dimensione non zero
☐ Il backup è compresso e copiato sullo storage remoto/off-site
☐ I vecchi backup giornalieri vengono ruotati (mantenere 7 giorni)

Settimanale (automatizzato)

☐ Il backup completo o incrementale dei file viene eseguito
☐ Lo snapshot settimanale del database viene conservato (mantenere 4 settimane)
☐ La copia sullo storage remoto è sincronizzata

Mensile (automatizzato + controllo manuale)

☐ Lo snapshot mensile del database viene conservato (mantenere 12 mesi)
☐ Verificate che i cron job siano ancora in esecuzione (controllate i log)
☐ Verificate che lo storage remoto contenga file recenti
☐ Controllate lo spazio su disco dello storage di backup

Trimestrale (manuale)

☐ Ripristino di prova completo in un ambiente di staging
☐ Verificate che il conteggio dei record corrisponda alla produzione (prodotti, ordini, clienti)
☐ Confermate che il login al Back Office, la visualizzazione prodotti e il checkout funzionino
☐ Documentate il tempo di ripristino
☐ Revisionate e aggiornate il vostro piano di disaster recovery

Prima di qualsiasi modifica importante

☐ Backup manuale prima degli aggiornamenti del core di PrestaShop
☐ Backup manuale prima dell’installazione/aggiornamento dei moduli
☐ Backup manuale prima di migrazioni del database o importazioni massive
☐ Backup manuale prima di modifiche alla configurazione del server

Sicurezza

☐ I backup contenenti dati dei clienti sono crittografati
☐ La passphrase di crittografia è conservata in un password manager (non sul server)
☐ Lo storage remoto utilizza autenticazione forte (chiavi SSH o token API)
☐ Gli script di backup utilizzano ~/.my.cnf invece di password inline
☐ I file di backup hanno permessi chmod 600 (leggibili solo dal proprietario)

Suggerimento: archiviazione sicura delle credenziali

# Create ~/.my.cnf so backup scripts don't contain plaintext passwords
cat > ~/.my.cnf << 'EOF'
[mysqldump]
user=your_db_user
password=your_db_password
[mysql]
user=your_db_user
password=your_db_password
EOF
chmod 600 ~/.my.cnf

# Now mysqldump works without -u and -p flags
mysqldump --single-transaction --quick --lock-tables=false prestashop | gzip > backup.sql.gz

Considerazioni finali

Come minimo, ogni negozio PrestaShop ha bisogno di: backup automatizzati giornalieri del database con retention di 7 giorni, backup settimanali dei file, almeno una copia off-site, test di ripristino trimestrali e un piano di disaster recovery scritto. Tutto il resto — ripristino point-in-time, backup crittografati, storage multi-regione — si scala in base al valore del vostro negozio.

Il momento giusto per configurare i backup è oggi. Un’ora di configurazione adesso può salvare la vostra intera attività in futuro.

Cookie	Provider	Purpose	Duration
PrestaShop-*	PrestaShop	Gestione della sessione e funzionalità del carrello	Session
PHPSESSID	PHP	Identificativo sessione PHP	Session
mprcr_consent	MPR Cookies Revolution	Memorizza le preferenze di consenso dei cookie	365 day(s)
mprcr_version	MPR Cookies Revolution	Traccia la versione della configurazione del consenso	365 day(s)

Cookie	Provider	Purpose	Duration
_ga	Google Analytics	Distingue utenti unici assegnando un numero generato casualmente	2 year(s)
_ga_*	Google Analytics	Utilizzato per mantenere lo stato della sessione tra le richieste di pagina	2 year(s)
_gid	Google Analytics	Distingue utenti unici per 24 ore	24 hour(s)
_gat	Google Analytics	Limita la frequenza delle richieste di analisi	1 minute(s)

Cookie	Provider	Purpose	Duration
_gcl_au	Google AdSense	Misura l'efficienza delle campagne memorizzando i dati di conversione	3 month(s)
_fbp	Facebook	Fornisce prodotti pubblicitari come le offerte in tempo reale	3 month(s)
_fbc	Facebook	Memorizza le informazioni dell'ultimo clic dalla pubblicità Facebook	2 year(s)
IDE	Google DoubleClick	Pubblicità mirata, misura le prestazioni degli annunci su diversi siti	1 year(s)
_uetsid	Microsoft Bing	Misura le prestazioni delle campagne per Microsoft Bing	1 day(s)
_uetvid	Microsoft Bing	Traccia il comportamento dei visitatori su più visite per Bing Ads	13 month(s)

Backup e Disaster Recovery PrestaShop: Guida completa