Pagina 1 di 3
Un piano di continuità che non è mai stato provato non è un piano, è una speranza. I backup che non hai mai ripristinato non esistono finché non ne hai bisogno, e a quel punto è tardi per scoprirlo. La continuità operativa si misura nel giorno peggiore, non nella documentazione, ed è per il giorno peggiore che questa categoria prepara.
Il primo tema è il backup che esiste solo se testato: strategie che vanno oltre il mysqldump notturno sullo stesso disco (che non ha mai salvato nessuno da un ransomware), la regola 3-2-1-1-0, il backup incrementale e off-site, e la verifica periodica del ripristino. Un backup non testato è un paracadute che non hai mai aperto.
Il secondo tema è il disaster recovery vero: la differenza fra un backup e un piano, RPO e RTO definiti in modo realistico e verificati, l'analisi del rischio, la simulazione di uno scenario ransomware su una PMI. Un piano di DR è la definizione di quanto puoi permetterti di perdere e in quanto tempo devi tornare operativo, non una cartella di file compressi.
Il terzo tema è il recupero operativo: il subentro su una codebase non documentata anche in 48 ore, il ripristino di un server in emergenza, la gestione del momento in cui lo sviluppatore o il fornitore spariscono. La resilienza si costruisce prima, con metodo, non si improvvisa durante l'emergenza.
Se vuoi un piano di continuità che regga davvero, vedi la consulenza cybersecurity e NIS2 o la panoramica dei servizi.
Un backup non testato è come un paracadute che non hai mai aperto: scopri se funziona nell'unico momento in cui non puoi permetterti che non funzioni.
mysqldump su database da 200GB richiede 4 ore e blocca le query durante l'esecuzione. Con Percona XtraBackup ho configurato backup incrementali ogni ora senza un singolo lock: il database continua a servire richieste, il backup è verificabile, il recovery è testato settimanalmente in automatico. Vi mostro la configurazione completa. Continua a leggere
Capita di dover spostare un intero sito avendo solo l'FTP, senza SSH. Scaricare tutto con un client grafico è lento e fragile: la connessione cade e si ricomincia. La soluzione è la riga di comando, e da anni il primo strumento è wget. Funziona ancora, ma sono arrivati strumenti che lo battono, e l'FTP in chiaro va maneggiato con cura. Questo articolo aggiorna la guida: wget, le alternative moderne come lftp e rclone, e perché se hai SSH la risposta è un'altra. Continua a leggere
Lanciare mysqldump su un database in produzione senza fermare i servizi è possibile, ma il modo in cui si fa cambia tutto. La ricetta che gira da anni, basata su --lock-tables=false, evita i blocchi ma produce un dump che può essere internamente incoerente: un dettaglio che non si nota finché non provi a ripristinarlo. La soluzione corretta per le tabelle InnoDB è --single-transaction, che dà uno snapshot consistente senza lock prolungati. Continua a leggere
Ho simulato uno scenario ransomware per un cliente manifatturiero con 60 dipendenti: ho mappato tutti i sistemi critici, calcolato il costo orario del downtime e testato i backup. I risultati erano scomodi: 18 ore per ripristinare i sistemi principali, 40 ore per i secondari, backup di tre settimane fa. Ecco cosa abbiamo fatto. Continua a leggere
Il backup di un server web non è uno script da lanciare e dimenticare: è una strategia che mette insieme due cose diverse, i file e i database, ognuna con le sue regole. Il vecchio approccio "un programma che zippa tutto e te lo manda via email" è pericoloso: password in chiaro, nessuna cifratura, copia sulla stessa macchina. Vediamo come si fa davvero nel 2026, con gli strumenti giusti e la regola che conta più di tutte: un backup non è un backup finché non lo hai ripristinato. Continua a leggere
L'errore "Data truncated for column" durante l'import di un dump MySQL è uno dei più comuni e dei più fraintesi quando si spostano dati fra ambienti configurati in modo diverso. La diagnosi corretta non è quella che suggeriscono molti tutorial: la causa reale è lo strict sql_mode, che promuove a errore bloccante una troncatura che altrove sarebbe un semplice avviso. Vediamo cos'è davvero questo errore, le cinque cause che lo scatenano, e come si risolve e si previene. Continua a leggere
cPanel rende facile creare un backup completo a mano, ma in modalità utente, senza accesso WHM, non offre un modo immediato per automatizzarlo. Così molti backup esistono finché qualcuno si ricorda di cliccare il pulsante, il che equivale a non averli. Questo articolo mostra come pianificare un backup automatico di cPanel verso un remoto, con l'API e i cron job, ma soprattutto perché un backup gestito dallo stesso hosting che dovrebbe proteggere non basta, e come costruirne uno indipendente. Continua a leggere
Un piano di disaster recovery non è un backup: è la definizione di RTO e RPO realistici, l'analisi del rischio, i runbook di ripristino, le procedure di failover, i ruoli e la comunicazione di crisi. In questo articolo ti mostro come si costruisce per un'applicazione PHP su VPS, e come si verifica prima che serva sul serio. Continua a leggere
Un gestionale PHP 5.6 senza Git, senza documentazione, senza test: 147 file PHP sparsi in 23 directory, credenziali MySQL hardcodate in 9 file, deploy via FTP e lo sviluppatore sparito da sei mesi. Come ho ripreso il controllo in 30 giorni con PHPStan baseline, Rector e Git incrementale. Continua a leggere
Un mysqldump che girava ogni notte sullo stesso disco del server non ha salvato una PMI manifatturiera dal ransomware: i backup erano sul filesystem cifrato dall'attaccante. Ricostruisco qui la strategia che applico come standard a ogni VPS unmanaged: 3-2-1-1-0, BorgBackup con repository append-only, encryption AES-256 lato client, retention GFS e restore verificato. Backup veri, non speranze. Continua a leggere
