Correzione automatica del filesystem su Debian: fsck fatto bene con systemd nel 2026
Un filesystem che non monta più al riavvio blocca tutto. Le vecchie guide per forzare il controllo del filesystem su Debian si basavano su un reboot giornaliero: oggi quel metodo è obsoleto, perché poggia su file di init che non esistono più e sul riavvio quotidiano, un anti-pattern in produzione. Questo articolo rifà la guida nel modo corretto del 2026: forzare un fsck con systemd, pianificare un controllo periodico senza riavvii, e recuperare un disco già corrotto. Continua a leggere
Ultima modifica:
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. 
Il tuo server Debian 12 "Bookworm" è stabile, ma il supporto di sicurezza standard è già scaduto e il sistema è entrato nel ciclo LTS. Debian 13 "Trixie" porta un kernel più recente, nuove versioni dei pacchetti e altri tre anni di patch piene. Affrontare un major upgrade su un sistema di produzione può sembrare un salto nel buio, ma con un piano e una rete di sicurezza diventa un'operazione controllata. Questa guida ti mostra come pianificarlo ed eseguirlo passo dopo passo, senza sorprese. 
Un VPS con 4 GB di RAM e zero swap: MySQL killato dall'OOM killer ogni notte durante l'import listini, con perdita di transazioni InnoDB. Come ho configurato uno swap file da 2 GB con swappiness a 10, perché ZRAM è spesso l'alternativa migliore su NVMe, e come proteggere i processi critici in modo permanente con systemd. 
Un VPS Hetzner che non inviava più notifiche email da quattro mesi: backup falliti senza alert, disco al 92% senza avviso, Fail2ban che bannava IP senza che nessuno lo sapesse. La causa: IP del server in blacklist RBL. Fix con relay SMTP via SendGrid, SPF/DKIM e monitoring della coda Postfix. 
Un VPS Hetzner che non bootava più dopo un kernel panic: filesystem ext4 con journal corrotto, errori I/O nei log, e un gestionale Laravel con il database dell'intero anno in produzione. Dalla disk image con ddrescue al recovery con fsck, xfs_repair e btrfs check, fino al monitoring SMART che ti avvisa prima del disastro: la procedura completa che applico su Debian e Ubuntu. 
Un portale Laravel con 200 utenti simultanei che diventava inutilizzabile nelle ore di punta: AJAX bloccati per 8-12 secondi, logout casuali, errori CSRF. La causa era il session locking su file. Migrazione a Redis con locking esplicito, TTL calibrato e garbage collection zero. Response time da 8s a 90ms. 
Un VPS Hetzner da 80GB al 100%: MySQL fermo, Laravel in errore 500, e dopo aver cancellato 30GB di log lo spazio non si liberava. La causa: file aperti da processi attivi. Diagnosi con ncdu, lsof e df -i, fix e configurazione logrotate per impedire che si ripeta. 
Un gestionale Laravel su Hetzner con MySQL che impiegava 3-4 secondi per ogni query di ricerca prodotti. La causa: InnoDB buffer pool a 128MB su un database da 6GB, reverse DNS lookup attivo e 47 query senza indice per ogni pagina catalogo. Diagnosi con slow query log, EXPLAIN e MySQLTuner, fix in due ore. 
Un VPS con MySQL esposto su porta 3306 a tutto internet e nessun firewall attivo: 23.000 tentativi di connessione in 48 ore. Configuro nftables da zero con policy default-deny, anti SYN flood, egress filtering, rate limiting SSH e ban dinamici via Fail2ban. La configurazione operativa che applico a ogni VPS LEMP, identica su Debian 12, Debian 13 e Ubuntu.