Il backup è l’unica cosa del sito di cui si scopre lo stato reale nel momento peggiore possibile: quando serve. Fino ad allora resta una convinzione — «sì, il backup c’è, lo fa l’hosting» oppure «c’è quel plugin, l’aveva messo l’agenzia» — e le convinzioni, nel giorno del disastro, valgono zero.
Vediamo come passare dalla convinzione alla verifica, in una domanda, e cosa controllare oltre alla semplice esistenza del file.
Le tre bugie tipiche del backup
«C’è il plugin, quindi ci sono i backup.» Il plugin è installato e attivo, ma la pianificazione non è mai stata impostata, oppure è stata sospesa e nessuno se n’è accorto. Ultimo backup: quattordici mesi fa.
«Gira ogni notte.» Gira, e fallisce. I backup si interrompono in silenzio per i motivi più banali — spazio esaurito sulla destinazione remota, credenziali scadute, tempo massimo di esecuzione superato su un sito diventato più grande. L’esito negativo finisce in un registro che nessuno apre.
«È tutto sul server.» Il backup c’è, è recente, è completo, ed è nella stessa cartella del sito. Nel caso di un server compromesso o di un guasto dell’hosting sparisce insieme a ciò che doveva proteggere.
La domanda che chiude la questione
Con il plugin Abilità IA installato, l’assistente riconosce gli strumenti di backup presenti sul sito e ne legge lo stato:
«Quali plugin di backup sono attivi su questo sito? Dimmi quando è stato eseguito l’ultimo backup, se è andato a buon fine, quanti backup sono conservati e quando è previsto il prossimo.»
Sono quattro informazioni e insieme danno la risposta vera. La più importante è la seconda: «esiste un backup di ieri» e «esiste un backup di ieri riuscito» sono due frasi diverse, ed è esattamente sulla differenza tra le due che si consumano le brutte sorprese.
[SCREENSHOT: stato dei backup con data dell’ultimo, esito e prossima esecuzione pianificata]
Il backup prima delle operazioni rischiose
Ogni volta che stai per fare qualcosa di massivo — un cambio prezzi su tutto il catalogo, una pulizia del database, un aggiornamento importante — il backup viene prima. Dove lo strumento installato lo consente, l’assistente può avviarlo su richiesta, e in genere basta quello del solo database: è veloce e copre la stragrande maggioranza dei danni da modifica.
Un dettaglio che vale la pena pretendere da qualsiasi strumento: «avviato» non significa «completato». Il backup parte in sottofondo e ci mette il tempo che ci mette; chiedere lo stato dopo qualche minuto, e vedere l’esito riuscito con l’orario giusto, è il passaggio che trasforma un’intenzione in una rete di sicurezza. Uno strumento onesto ti dice che ha avviato la procedura, non che è andata a buon fine prima di saperlo.
La prova che quasi nessuno fa
Un backup mai ripristinato è un backup di cui non sai niente. Una volta all’anno — o dopo ogni cambio di hosting — vale la pena provare a ripristinarlo da qualche altra parte: un sito di prova, un sottodominio, un ambiente locale. Mai sul sito vivo, ovviamente. È l’unico modo per scoprire prima, e non durante l’emergenza, che manca la cartella dei caricamenti o che il file del database si interrompe a metà.
La regola minima, senza fanatismi
Per un sito normale bastano tre condizioni: due copie in posti diversi (una sul server e una fuori, che sia uno spazio cloud o un disco), una frequenza coerente con quanto perderesti (un negozio che riceve ordini ogni giorno non può permettersi backup settimanali, un sito vetrina sì), e una verifica periodica che non sia guardare il pannello ma leggere l’esito. Dieci minuti al mese, ed è la polizza più economica che esista.
Per iniziare
Servono WordPress, il plugin Abilità IA e un assistente compatibile con MCP. Fai la domanda oggi, prima di qualsiasi altra manutenzione: la risposta è immediata e, statisticamente, in un sito su tre non è quella che ti aspetti. Se poi il sospetto è più grave di un backup dimenticato, i controlli da fare sono altri quattro.

0 Commenti