Guide Guide

Backup e Disaster Recovery PrestaShop: Guida completa

Strategia pratica di backup per PrestaShop — mysqldump, backup file, cron automatizzati, storage offsite, test di ripristino e piani di disaster recovery.

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)

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

Scenario 2: database corrotto

  1. Fermate il web server: systemctl stop apache2
  2. Provate prima la riparazione: mysqlcheck -u root -p --auto-repair prestashop
  3. 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
  4. Riavviate il web server, svuotate la cache di PrestaShop
  5. Valutate la perdita di dati — controllate gli ID degli ordini e i timestamp per identificare il gap

Scenario 3: hackerato — file modificati

  1. Mettete il sito offline immediatamente
  2. Preservate le prove: tar -czf hacked_site.tar.gz /var/www/html/
  3. 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/
  4. Ripristinate i file da un backup datato prima della violazione
  5. Controllate il database per account admin sospetti e modifiche di configurazione anomale
  6. Cambiate TUTTE le credenziali: password DB, password admin, FTP, chiavi SSH, chiavi API
  7. Aggiornate il core di PrestaShop e tutti i moduli
  8. Monitorate attentamente per 2-4 settimane — gli attaccanti spesso lasciano backdoor multiple

Scenario 4: cancellazione accidentale di modulo/tema

  1. 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/
  2. Se il modulo è stato disinstallato tramite Back Office (tabelle DB rimosse), ripristinate anche il database oppure reinstallate dallo ZIP originale
  3. 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 è 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 è 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.

Related: Cron Manager · Security Guide · Database Cleanup

Back to top