--- title: "Business Continuity" description: "Business continuity per aziende: disaster recovery con RPO e RTO, backup testati, subentro su codebase non documentate, monitoring. Piani che reggono davvero. - Business Continuity - Pagina 1 di 3" canonical: "https://www.mauriziofonte.it/blog/cat/business_continuity.html" author: "Maurizio Fonte" --- Categoria # Business Continuity Pagina 1 di 3 ## **Business Continuity**: piani che reggono la prova reale, fuori dal cassetto Un piano di continuità mai provato è poco più di una speranza. I backup che non hai mai ripristinato li scopri inutili proprio quando ti servono, e a quel punto è tardi. La continuità operativa si misura nel giorno peggiore, ed è per il giorno peggiore che questa categoria prepara. Si parte dal **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. Poi il **disaster recovery vero**: cosa separa un backup da un piano, RPO e RTO definiti in modo realistico e verificati, l'analisi del rischio, la simulazione di uno scenario ransomware su un'azienda. Un piano di DR stabilisce quanto puoi permetterti di perdere e in quanto tempo devi tornare operativo. E 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, perché durante l'emergenza non c'è tempo per improvvisarla. Se vuoi un piano di continuità che regga davvero, vedi la [consulenza cybersecurity e NIS2](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) o la [panoramica dei servizi](https://www.mauriziofonte.it/servizi.html). > 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. 1[2](https://www.mauriziofonte.it/blog/cat/business_continuity.md?page=2)[3](https://www.mauriziofonte.it/blog/cat/business_continuity.md?page=3) [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) ## [Zitadel in alta disponibilità: due nodi e upgrade a zero downtime](https://www.mauriziofonte.it/blog/post/zitadel-alta-disponibilita-upgrade-zero-downtime.html) 31/07/2026 ![Zitadel in alta disponibilità: due nodi e upgrade a zero downtime](https://www.mauriziofonte.it/image/005490200-zitadel-alta-disponibilita-upgrade-zero-downtime.jpg) Due istanze di un binario stateless dietro un bilanciatore sembrano il caso più semplice di alta disponibilità, e lo sarebbero se non ci fosse una fase che tocca lo schema del database. È quella fase a imporre un ordine fra i nodi, a rendere l'aggiornamento asimmetrico e a decidere se il rollback funziona ancora. La sequenza completa, lo script che la esegue, i codici di uscita per la pipeline, cosa monitorare davvero e le due cose che con la versione 4 sono cambiate. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-alta-disponibilita-upgrade-zero-downtime.html) Ultima modifica: Venerdì 31 Luglio 2026, alle 16:55 [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) [Database](https://www.mauriziofonte.it/blog/cat/database.html) ## [Backup incrementale di MySQL con xtrabackup: recovery point granulare senza blocchi](https://www.mauriziofonte.it/blog/post/backup-incrementale-mysql-xtrabackup-recovery-point-senza-blocchi.html) 26/03/2026 ![Backup incrementale di MySQL con xtrabackup: recovery point granulare senza blocchi](https://www.mauriziofonte.it/image/003110200-backup-incrementale-mysql-xtrabackup-recovery-point-senza-blocchi.jpg) 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](https://www.mauriziofonte.it/blog/post/backup-incrementale-mysql-xtrabackup-recovery-point-senza-blocchi.html) Ultima modifica: Giovedì 26 Marzo 2026, alle 09:57 [VPS & Hosting](https://www.mauriziofonte.it/blog/cat/vps.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) ## [Mirror completo di un sito via FTP da riga di comando: wget e le alternative moderne](https://www.mauriziofonte.it/blog/post/mirror-webroot-FTP-da-linea-comando-wget.html) 25/03/2026 ![Mirror completo di un sito via FTP da riga di comando: wget e le alternative moderne](https://www.mauriziofonte.it/image/000280200-mirror-webroot-FTP-da-linea-comando-wget.jpg) 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](https://www.mauriziofonte.it/blog/post/mirror-webroot-FTP-da-linea-comando-wget.html) Ultima modifica: Lunedì 15 Giugno 2026, alle 18:01 [Database](https://www.mauriziofonte.it/blog/cat/database.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) ## [Backup di Mysql con mysqldump senza lock sulle tabelle](https://www.mauriziofonte.it/blog/post/mysqldump-senza-lock-su-server-produzione.html) 19/03/2026 ![Backup di Mysql con mysqldump senza lock sulle tabelle](https://www.mauriziofonte.it/image/000300200-mysqldump-senza-lock-su-server-produzione.jpg) 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](https://www.mauriziofonte.it/blog/post/mysqldump-senza-lock-su-server-produzione.html) Ultima modifica: Giovedì 25 Giugno 2026, alle 13:11 [Incident Response](https://www.mauriziofonte.it/blog/cat/incident_response.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) ## [Valutare l'impatto di un attacco ransomware su una PMI: simulazione e piano di risposta](https://www.mauriziofonte.it/blog/post/impatto-attacco-ransomware-pmi-simulazione-piano-risposta.html) 11/03/2026 ![Valutare l'impatto di un attacco ransomware su una PMI: simulazione e piano di risposta](https://www.mauriziofonte.it/image/002340200-impatto-attacco-ransomware-pmi-simulazione-piano-risposta.jpg) 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](https://www.mauriziofonte.it/blog/post/impatto-attacco-ransomware-pmi-simulazione-piano-risposta.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [Database](https://www.mauriziofonte.it/blog/cat/database.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) ## [Backup del filesystem e dei database di server web](https://www.mauriziofonte.it/blog/post/backup_del_filesystem_e_dei_database_di_server_web.html) 18/02/2026 ![Backup del filesystem e dei database di server web](https://www.mauriziofonte.it/image/000070200-backup_del_filesystem_e_dei_database_di_server_web.jpg) 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](https://www.mauriziofonte.it/blog/post/backup_del_filesystem_e_dei_database_di_server_web.html) Ultima modifica: Giovedì 25 Giugno 2026, alle 13:10 [Database](https://www.mauriziofonte.it/blog/cat/database.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) ## [Soluzione errore 1256 mysql "data truncated for column"](https://www.mauriziofonte.it/blog/post/mysql-error-1256-data-truncated-for-column.html) 06/02/2026 ![Soluzione errore 1256 mysql "data truncated for column"](https://www.mauriziofonte.it/image/000320200-mysql-error-1256-data-truncated-for-column.jpg) 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](https://www.mauriziofonte.it/blog/post/mysql-error-1256-data-truncated-for-column.html) Ultima modifica: Lunedì 15 Giugno 2026, alle 18:01 [VPS & Hosting](https://www.mauriziofonte.it/blog/cat/vps.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) ## [Backup automatici su cPanel inviati via FTP: come si fa, e perché non è abbastanza](https://www.mauriziofonte.it/blog/post/backup-automatico-cpanel-ftp.html) 03/02/2026 ![Backup automatici su cPanel inviati via FTP: come si fa, e perché non è abbastanza](https://www.mauriziofonte.it/image/000450200-backup-automatico-cpanel-ftp.jpg) 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](https://www.mauriziofonte.it/blog/post/backup-automatico-cpanel-ftp.html) Ultima modifica: Lunedì 15 Giugno 2026, alle 18:01 [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) [IT aziendale](https://www.mauriziofonte.it/blog/cat/pmi.html) ## [Piano di Disaster Recovery per applicazioni PHP: guida pratica per la continuità operativa della tua PMI](https://www.mauriziofonte.it/blog/post/piano-disaster-recovery-php-continuita-operativa-pmi.html) 08/09/2025 ![Piano di Disaster Recovery per applicazioni PHP: guida pratica per la continuità operativa della tua PMI](https://www.mauriziofonte.it/image/002260200-piano-disaster-recovery-php-continuita-operativa-pmi.jpg) 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](https://www.mauriziofonte.it/blog/post/piano-disaster-recovery-php-continuita-operativa-pmi.html) Ultima modifica: Giovedì 25 Giugno 2026, alle 13:18 [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) ## [Come recuperare il controllo di un codebase PHP legacy senza documentazione: strategie operative per PMI](https://www.mauriziofonte.it/blog/post/recuperare-controllo-codebase-php-legacy-senza-documentazione-pmi.html) 01/09/2025 ![Come recuperare il controllo di un codebase PHP legacy senza documentazione: strategie operative per PMI](https://www.mauriziofonte.it/image/002210200-recuperare-controllo-codebase-php-legacy-senza-documentazione-pmi.jpg) 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](https://www.mauriziofonte.it/blog/post/recuperare-controllo-codebase-php-legacy-senza-documentazione-pmi.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 1[2](https://www.mauriziofonte.it/blog/cat/business_continuity.md?page=2)[3](https://www.mauriziofonte.it/blog/cat/business_continuity.md?page=3) ## Strumenti utili Tool gratuiti a supporto: [Validatore email e DNS](https://www.mauriziofonte.it/strumenti/validatore-email-dns), [Autovalutazione NIS2](https://www.mauriziofonte.it/strumenti/autovalutazione-nis2-pmi). --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about