La maggior parte degli e-commerciante pensa di avere backup. La maggior parte non li ha davvero. Sugli audit che conduciamo, 6 negozi PrestaShop su 10 non hanno un backup ripristinabile in meno di 4 ore, 3 su 10 hanno backup corrotti o incompleti, e circa 1 su 10 non ha alcun backup utilizzabile da più di un mese — spesso senza saperlo.
Il costo di un incidente senza backup funzionante è tra 24 ore e diverse settimane di fermo, dati clienti perduti e a volte la cessazione dell’attività. Questo articolo descrive la strategia di backup che dovresti avere nel 2026 su un negozio PrestaShop: la regola 3-2-1, la cifratura, la rotazione e, soprattutto, il ripristino testato.
Perché i backup di default non bastano
“Il mio hosting fa i backup” è la frase che torna più spesso. È vero in generale, e insufficiente in pratica:
- I backup dell’hosting sono nello stesso datacenter. Un incendio importante (OVH Strasburgo 2021), un attacco ransomware, o una compromissione del pannello di amministrazione dell’hosting, e i backup bruciano insieme ai dati.
- La retention è breve. 7-14 giorni per le offerte standard. Se scopri un defacement o una corruzione 3 settimane dopo, il backup infetto ha già rimpiazzato quello sano.
- Il backup include davvero tutto? Molti hosting fanno il backup del database ma non dei file, o viceversa. E gli upload (immagini prodotti, fatture PDF, export) vengono a volte dimenticati.
- Il ripristino non viene mai testato. Il giorno X, si scopre che la procedura di ripristino non funziona, o impiega 36 ore, o richiede l’accesso a un pannello che si è perso.
- Nessuna cifratura. Un backup non cifrato ospitato presso un terzo significa l’intero database clienti esposto in caso di fuga di dati dal fornitore.
La regola 3-2-1: riferimento industriale da 30 anni
Formulata dal fotografo Peter Krogh nel 2005 per i backup digitali, adottata dall’ANSSI, dal CISA americano e dalla quasi totalità dei framework di sicurezza IT:
3 copie dei dati, su 2 supporti differenti, di cui 1 off-site.
Concretamente per un negozio PrestaShop:
- Copia 1: la produzione (il tuo server di prod).
- Copia 2: backup locale o sullo stesso hosting (veloce da ripristinare per incidenti minori).
- Copia 3: backup off-site, presso un fornitore di storage terzo (S3, Backblaze B2, Wasabi, Dropbox).
La copia off-site è l’ultima linea di difesa contro i sinistri maggiori (incendio, ransomware, fallimento dell’hosting).
Cosa bisogna salvare in un negozio PrestaShop
1. Il database completo
Tutte le tabelle, non solo quelle di business. Un dump mysqldump con le opzioni --single-transaction --quick --routines --triggers per la coerenza e l’inclusione delle stored procedure e dei trigger.
2. I file caricati
La cartella /img/ (immagini prodotti, categorie, produttori), /upload/ (file allegati ai prodotti), /download/ (prodotti virtuali e i loro deliverable), e tutte le directory di moduli di terze parti che memorizzano file (fatture PDF, export contabili, log).
3. Il codice e i moduli
Anche se hai Git, salvare il codice in produzione permette di catturare le modifiche hotfix non versionate e lo stato esatto dei moduli installati. Include /modules/, /themes/, /override/ e la root PrestaShop esclusa /var/cache/.
4. La configurazione di sistema
File app/config/parameters.php, .htaccess, configurazioni Nginx/Apache, certificati SSL, crontab. Spesso dimenticati, sono critici per rigiocare un’installazione da zero.
5. Le email in uscita e i log recenti
Per gli obblighi legali (GDPR, contabilità), conservare una copia dei log recenti e delle email transazionali. Non sistematico, ma utile.
La cifratura non è più opzionale
Un backup non cifrato memorizzato presso un fornitore terzo è un rischio GDPR maggiore: se il fornitore viene compromesso, tutto il tuo database clienti fa fuga in chiaro. Articolo 32 GDPR: obbligo di mettere in atto “misure tecniche adeguate”, che include la cifratura at-rest per i backup contenenti dati personali.
Lo standard nel 2026: AES-256 con una chiave memorizzata separatamente dai backup. Non memorizzare mai la chiave di cifratura con i backup — altrimenti la cifratura non serve a nulla.
La rotazione: quante versioni conservare
Più si conserva, meglio è — ma costa. Strategia GFS (Grandfather-Father-Son) collaudata:
- Backup giornalieri conservati 7 giorni.
- Backup settimanali conservati 4 settimane.
- Backup mensili conservati 12 mesi.
- Backup annuali conservati 5-7 anni (secondo gli obblighi contabili locali).
Con questa strategia, puoi ripristinare a qualsiasi giorno degli ultimi 7 giorni, qualsiasi settimana dell’ultimo mese, qualsiasi mese dell’ultimo anno. Copre il 99% degli scenari di recupero.
Il ripristino testato: l’unico backup che conta
Un backup non testato è una superstizione, non un backup. La regola assoluta:
Testa il ripristino su un ambiente di staging almeno una volta al trimestre.
Questo test deve verificare:
- Il backup è completo (tutte le tabelle, tutti i file)?
- Il dump è ripristinabile senza errori?
- Il sito funziona dopo il ripristino (pagine categoria, carrello, checkout, BO)?
- Quanto tempo richiede il ripristino completo (RTO: Recovery Time Objective)?
- Qual è la perdita massima di dati (RPO: Recovery Point Objective)?
Sui negozi che fanno questo test trimestrale, il tempo di ripristino scende da 6-8 ore a 1-2 ore in alcune iterazioni. E le anomalie (tabella mancante, permesso errato, file corrotto) vengono individuate prima dell’incidente, non durante.
Il nostro modulo dfbackup: backup chiavi in mano
Implementare questa strategia a mano richiede la manutenzione di uno script di dump, un sistema di cifratura, una rotazione e un upload verso storage S3. Il nostro modulo dfbackup per PrestaShop 8 e 9 ha pacchettizzato l’intero stack:
- Backup pianificato DB + file via cron, intervallo configurabile (giornaliero, settimanale).
- Cifratura AES-256 con chiave separata, conservabile fuori dal server.
- Destinazioni multiple: S3 (e compatibili: Wasabi, Backblaze B2, Scaleway), FTP/SFTP, Dropbox.
- Rotazione GFS automatizzata: conservazione parametrabile per strato.
- Ripristino 1-click dal back-office, con staging opzionale.
- Notifiche via email o webhook in caso di errore o successo.
- Log dettagliati di ogni backup (volume, durata, hash di verifica).
- Compatibile multi-shop, multilingue, e con retention differenziata per perimetro.
A 129 €, installi una strategia di backup conforme al GDPR e industrializzata, senza dipendere dal tuo hosting.
Quanto costa non avere backup
Su un negozio che genera 100 k€ di fatturato mensile, un fermo di 48 ore costa direttamente 6.700 € di fatturato non realizzato. Aggiungi i costi indiretti: riconquista dei clienti persi, recensioni negative sull’assistenza, impatto SEO se il fermo dura (Google può deindicizzare se il sito resta 404 più di qualche giorno), perdita di fiducia dei partner. Totale realistico: 15-30 k€ per un fermo di 48 ore. Per un mese di fermo, si parla della sopravvivenza dell’azienda.
Il costo di una strategia di backup robusta: 130 € di modulo + 5-20 €/mese di storage S3. Il rapporto costo/rischio non si discute.
FAQ
I backup incrementali sono sufficienti?
Non da soli. Un backup incrementale dipende dal backup completo precedente. Se il backup completo è corrotto, tutta la catena incrementale è inutilizzabile. La regola: un backup completo settimanale o mensile, integrato da incrementali giornalieri. Non il contrario.
Quanto tempo deve impiegare un ripristino?
L’RTO accettabile dipende dalla criticità. Per un negozio e-commerce attivo: meno di 4 ore per un ripristino completo è l’obiettivo. Sotto le 2 ore con una procedura rodata e uno storage vicino. Oltre le 8 ore, c’è un problema di strategia o di strumenti.
File e database vanno salvati insieme o separatamente?
Insieme, idealmente in una finestra temporale ristretta (10-15 minuti). Un database e dei file desincronizzati (ad esempio, database salvato la mattina, file la sera) creano incoerenze al ripristino: prodotti nel database senza immagine, fatture referenziate che non esistono come file.
Lo storage cloud (S3) è conforme al GDPR?
Sì, se il fornitore è nell’UE o propone le Clausole Contrattuali Tipo (CCT) per i trasferimenti fuori UE. AWS, Scaleway, OVH Object Storage, Backblaze sono conformi con configurazione appropriata. La cifratura prima dell’upload garantisce che anche un fornitore compromesso non dia accesso a nulla di utilizzabile.
Che differenza c’è con una replica in tempo reale?
La replica (master-slave MySQL, ad esempio) protegge da un guasto hardware, non da errori umani o corruzioni logiche. Se uno script elimina 10.000 prodotti per errore, la replica applica l’eliminazione istantaneamente. Il backup versionato conserva una versione sana precedente. I due sono complementari, non sostituibili.
Per approfondire
Il backup è un anello di una catena più ampia: sicurezza, monitoring, gestione degli incidenti. Un sito ben backuppato ma mal monitorato perde comunque dati tra l’incidente e la sua rilevazione. Vedi anche la nostra guida all’installazione dei moduli PrestaShop per capire dove dfbackup si inserisce nello stack, e il dossier sulla pulizia del database PrestaShop: alleggerire il database prima del backup divide per 5 il tempo di backup e il costo di storage.