Ripristinare un backup: se non l'hai provato, non ce l'hai

«Facciamo backup giornalieri.» Lo dicono quasi tutti, e di solito è vero. Quello che di solito non si sa è se quei backup si possono ripristinare, quanto tempo ci vuole e cosa si perde per strada. Lo si scopre solo in due modi: con una simulazione fatta con calma o il giorno in cui il negozio è fermo. Il secondo è quello abituale.

Questo articolo non parla di quanti backup fare né di dove conservarli, ma del passaggio che quasi nessuno fa: verificare che tornino indietro.

Cosa va storto quando si ripristina un negozio

Questi sono i problemi più frequenti quando un backup viene usato per la prima volta:

• Il backup contiene solo i file, o solo il database. L'hosting copia la cartella web, ma il database è su un altro server e resta fuori. O al contrario: ci sono dump SQL giornalieri, ma le immagini dei prodotti non vengono copiate.
• Il dump è troncato. È stato generato con un limite di tempo o di dimensione e mancano le ultime tabelle. Il file esiste, pesa parecchio e nessuno l'ha mai aperto.
• Il backup è del negozio già infetto. Se il problema è un attacco, i backup delle ultime settimane possono contenere la stessa backdoor.
• Si conservano solo pochi giorni. Quando scopri il problema, l'ultimo backup buono è già stato cancellato.
• Nessuno ha accesso. I backup sono nel pannello di un hosting la cui password ce l'aveva qualcuno che non c'è più, o in un account di archiviazione intestato all'agenzia precedente.
• Il ripristino richiede ore. Un negozio con un catalogo grande può avere decine di giga di immagini. Scaricarle e caricarle richiede tempo, e nessuno l'aveva calcolato.
• Il negozio ripristinato non parte. Per differenze di versione di PHP o di MySQL tra il server originale e quello nuovo, per cache che puntano a percorsi vecchi o per una configurazione con il dominio sbagliato.

Cosa deve includere un backup di PrestaShop

1. Il database completo, con un dump coerente (non copiando a caldo i file di MySQL).
2. Tutti i file: core, moduli, tema, img/ con le immagini dei prodotti, download/ se vendi prodotti scaricabili, upload/ con i file dei clienti e le fatture se vengono salvate su disco.
3. La configurazione: il file dei parametri con le chiavi dell'installazione. Senza la chiave dei cookie originale, le vecchie password dei clienti non si potranno verificare.
4. Ciò che sta fuori dalla cartella web: attività pianificate, configurazione del server, regole di reindirizzamento, certificati.

Come fare una simulazione senza toccare la produzione

Una simulazione consiste nel ripristinare un backup reale in un posto diverso dal negozio, come se il negozio fosse sparito. Non serve fermare niente.

1. Scegli un backup a caso, non quello di stanotte. Se provi solo l'ultimo, non sai se quelli di una settimana fa sono validi.
2. Ripristinalo in un ambiente separato: un sottodominio di prova protetto da password, un server locale o un hosting temporaneo.
3. Isola la copia prima di aprirla. Disattiva l'invio delle email, metti i gateway di pagamento in modalità test, blocca l'indicizzazione e togli le attività pianificate. Un negozio ripristinato con tutto acceso può scrivere ai tuoi clienti o addebitare loro dei pagamenti.
4. Cronometra ogni passaggio: scaricare, caricare i file, importare il database, adattare il dominio, svuotare la cache.
5. Verifica che funzioni davvero: home page, una categoria, una scheda prodotto con immagini, il back-office, un ordine di prova fino in fondo, le fatture di un ordine vecchio, la ricerca.
6. Confronta con la produzione: numero di prodotti, di clienti e di ordini, e la data dell'ultimo ordine del backup.
7. Annota cosa non ha funzionato e correggilo nel sistema di backup, non nel backup.

Due numeri che devi conoscere

Dalla simulazione escono le due risposte che contano il giorno del problema:

• Quanto puoi perdere: il tempo tra l'ultimo backup e il momento del guasto. Con backup giornalieri, fino a un giorno di ordini, clienti e modifiche al catalogo. Se è troppo, ti servono backup del database più frequenti.
• Quanto ci metti a tornare online: il tempo reale della simulazione, più il margine di farlo di fretta e sotto pressione. Se sono sei ore, il negozio resterà fermo sei ore.

Con questi due numeri puoi decidere con dati alla mano se il tuo sistema di backup basta o se te ne serve un altro.

Ripristinare dopo un attacco

È il caso più delicato. Non basta tornare all'ultimo backup:

• Cerca quando è iniziato il problema e ripristina un backup precedente, oppure ripristina il più recente e puliscilo confrontandolo con il core e i moduli originali.
• Recupera gli ordini e i clienti successivi al backup dal database attuale, facendo attenzione a non portarti dietro anche ciò che ha inserito l'attaccante.
• Chiudi la via d'ingresso prima di riaprire. Altrimenti il negozio ripristinato sarà esposto come prima.
• Cambia tutte le credenziali dopo il ripristino.

Mettilo per iscritto

La procedura di ripristino deve essere scritta: dove sono i backup, con quale account si accede, quali passaggi si seguono, chi lo fa e chi si chiama se quella persona non c'è. Il giorno in cui ti servirà non sarà un giorno tranquillo, e ciò che non è scritto verrà dimenticato. Ripeti la simulazione ogni pochi mesi e sempre dopo aver cambiato hosting, versione di PrestaShop o di PHP: un backup che si ripristinava bene sul server precedente può non farlo sul nuovo.

Come risolverlo in PrestaShop

L'Hosting plan profesional di Rekire è pensato per ospitare negozi PrestaShop. Se preferisci restare con il tuo hosting attuale, con un pacchetto di ore di supporto tecnico di Rekire controlliamo quali backup hai, facciamo la simulazione di ripristino in un ambiente isolato (senza email in uscita, con i gateway in modalità test e senza indicizzazione), misuriamo quanto tempo ci vuole e cosa si perde, e ti lasciamo per iscritto la procedura per il giorno in cui servirà.