Backup Laravel su VPS che falliscono da tre mesi senza che nessuno se ne accorga: diagnosi e strategia di ripristino
Su un VPS Contabo con un gestionale Laravel 10, i backup automatici con spatie/laravel-backup fallivano da tre mesi - disco pieno sullo storage S3, credenziali scadute, e il notification channel configurato su un webhook Slack che non esisteva più. Il titolare l'ha scoperto quando ha avuto bisogno di un restore. Diagnosi delle cause di fallimento, ripristino della pipeline, test di restore verificato e monitoring che avvisa davvero quando qualcosa non funziona. Continua a leggere
Ultima modifica:
Un e-commerce Laravel su Hetzner inviava 800 email transazionali al giorno tramite Postfix locale. Il 40% finiva in spam su Gmail, il 15% non arrivava affatto su Outlook. Il titolare non lo sapeva perché nessuno monitorava i bounce. Diagnosi: niente SPF, niente DKIM, niente DMARC, IP del VPS in due blacklist. La soluzione non era "aggiustare Postfix" - era ripensare come un'applicazione Laravel in produzione deve gestire le email transazionali nel 2025. 
Un VPS OVH con Debian 11 e Laravel 10 non vedeva un apt upgrade da 14 mesi. 247 pacchetti arretrati, 38 security patch mancanti, OpenSSH con regreSSHion non patchato. Il proprietario non lo sapeva - l'app funzionava. Il protocollo per aggiornare un server di produzione senza downtime: snapshot, dry run, upgrade in due fasi, needrestart, verifica applicativa e setup unattended-upgrades. 
Un VPS Contabo con un e-commerce B2B Laravel è rimasto fermo 60 ore - dal venerdì pomeriggio al lunedì mattina - perché il certificato SSL era scaduto e nessuno se n'era accorto. 80 ordini persi, circa 35.000 euro di fatturato evaporato in un weekend. Il problema non era il certificato: era l'assenza totale di monitoring. Prometheus, Grafana, Alertmanager, health check Laravel e regole di alerting concrete: ecco lo stack che installo su ogni VPS che prendo in carico. 
Quando un'applicazione Laravel cresce oltre le capacità di un hosting condiviso, la migrazione verso un VPS diventa inevitabile. Il problema è che molte PMI la affrontano come un trasloco meccanico, quando in realtà è una transizione architetturale che richiede pianificazione, hardening e verifica. In questo articolo racconto il metodo che applico nelle migrazioni reali, con le trappole più comuni e le decisioni che fanno la differenza tra un passaggio pulito e settimane di problemi. 
Quando il sito entra in maintenance mode per un deploy finito male e nessuno lo sa riportare online, il business perde fatturato per mesi in silenzio. Il caso reale di un e-commerce B2B HoReCa bolognese del giugno 2025 su Contabo VPS L, Laravel 9.52 in manutenzione da dodici settimane, il deploy abortito a metà con migration orfane e code bloccate, e i quattro giorni di lavoro con cui ho ricostruito lo stato consistente senza rifare l'applicazione. 
Quando il team di sviluppo esterno chiude senza preavviso, il codice Laravel continua a girare ma i pezzi che non vedi - scheduler, Horizon, queue workers, notifiche transazionali - smettono di funzionare in silenzio. Il caso reale di un SaaS torinese di fleet management del giugno 2025, un Hetzner AX52 con Laravel 10 e Spatie Multi-Tenancy, 47 tenant attivi e 13.000 clienti finali, e i cinque giorni di lavoro con cui ho riportato l'applicazione a regime senza rifare nulla. 
Quando lo sviluppatore freelance scompare e l'account del provider è intestato alla sua partita IVA, il server dedicato non è solo un problema tecnico: è una questione di proprietà legale, credenziali irrecuperabili e certificati in scadenza. Il caso reale di un cliente genovese del settore nautico B2B, un Hetzner AX51-NVMe con Magento 2 e gestionale custom in produzione, e i sei giorni di lavoro con cui ho restituito al titolare il controllo completo dell'infrastruttura. 
Quando lo sviluppatore originale è scomparso e il server VPS unmanaged è bloccato, il provider non risolve il problema al posto tuo: ti consegna gli strumenti - rescue mode, console KVM, log di sistema - ma sta a te (o a chi ti aiuta) usarli nel modo giusto. Il caso reale di un Hetzner AX41 lockato del cliente romano del 2025 e i comandi esatti che ho usato per recuperarlo in tre ore di lavoro. 
Migrare un database MySQL 5.7 fuori supporto fa paura ai clienti, e quasi sempre per il motivo sbagliato: pensano al rischio di perdita dati quando il vero problema è il downtime. Il piano in cinque fasi che applico su Hetzner e OVH per spostare database critici con replicazione master-slave, riducendo il fermo da otto ore a cinque minuti.