Configurare swap file per risolvere saturazioni RAM su VPS gestite senza supporto tecnico: guida pratica per Debian e Ubuntu
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. Continua a leggere
Ultima modifica:
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. 
Un e-commerce Laravel su Hetzner fermo da 3 ore: schermata bianca, nessun log visibile, PHP-FPM che si riavvia in loop. La causa era un segfault in OPcache innescato dall'aggiornamento a PHP 8.2.21. Diagnosi con dmesg e strace, fix con disabilitazione JIT, e il protocollo che uso per ogni emergenza PHP su VPS unmanaged. 
Un VPS Hetzner con Laravel e 23 cron job tutti schedulati alle 02:00: load average a 47, MySQL in lock wait, import listini che si sovrappongono a sé stessi per tre ore. Ho ristrutturato l'intero scheduling con flock, nice/ionice, staggering e systemd timer. Il protocollo che applico a ogni VPS con più di 5 cron job. 
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.