Ho perso tutto una volta: da quel giorno backup ogni sera
Una mattina di novembre il database non c'era più. Quello che ho imparato quel giorno mi ha cambiato il modo di lavorare per sempre. E probabilmente ha salvato l'attività di diversi miei clienti.
Era novembre 2008. Mi sveglio, accendo il Mac, apro il terminale per controllare un deploy di routine. Il server risponde, tutto ok. Apro il browser, carico il sito di un cliente. Schermata bianca. Ricarico. Niente. Mi collego via SSH, controllo i log. E lì vedo la frase che ti gela il sangue: "Database connection failed".
Provo a connettermi direttamente a MySQL. Niente. Il database non c'era più. Letteralmente sparito. Un errore hardware del provider, un controller RAID andato a puttane, e con lui tre mesi di contenuti, ordini, tutto. Il backup? Sì, certo, ce l'avevo. Di tre settimane prima.
Quando capisci sulla tua pelle cosa significa perdere dati
Quel cliente era un e-commerce di prodotti tipici trentini. Piccolo, ma in crescita. Stavano iniziando a vendere bene, avevano appena fatto una campagna Facebook che aveva portato un sacco di ordini. Ordini che adesso non c'erano più. Clienti che avevano pagato e di cui non avevamo più traccia. Un casino.
Ho passato due giorni a recuperare quello che potevo dai log del server, dalle email, dalle cache di Google. Ho ricostruito a mano parte del database. Ma una fetta di dati l'abbiamo persa per sempre. Il cliente è stato comprensivo, ma io mi sono sentito una merda. E ho capito che non poteva più succedere.
Da quel giorno, ogni singolo progetto che seguo ha un sistema di backup automatico. Non importa se è un sito vetrina di tre pagine o un gestionale complesso. Ogni sera, alle 3 di notte, parte uno script che fa il dump del database e copia i file. Sempre. Senza eccezioni.
Come funziona il mio sistema di backup
Niente di fantascientifico, eh. Uso un approccio semplice ma solido. Uno script bash che gira come cronjob, fa il dump di MySQL con mysqldump, comprime tutto con gzip, e manda una copia su tre destinazioni diverse: server remoto, Dropbox aziendale, e un hard disk esterno che tengo in studio.
La regola del 3-2-1: tre copie, su due supporti diversi, una delle quali offsite. È roba vecchia come il cucco, ma funziona. E ogni lunedì mattina, quando accendo il computer, controllo i log di backup della settimana. Quattro minuti che mi risparmiano potenziali notti insonni.
#!/bin/bash
# Backup script - runs at 3am daily
DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/backup/$DATE"
mkdir -p $BACKUP_DIR
mysqldump -u user -p'password' database | gzip > $BACKUP_DIR/db.sql.gz
tar -czf $BACKUP_DIR/files.tar.gz /var/www/html
# Sync to remote
rsync -avz $BACKUP_DIR user@remote:/backups/
# Keep only last 30 days
find /backup -type d -mtime +30 -exec rm -rf {} \;Questo è lo scheletro base. Ovviamente ogni progetto ha le sue specificità: alcuni clienti vogliono backup più frequenti, altri hanno database enormi e serve un approccio incrementale. Per un ristorante qui a Trento con sistema di prenotazioni, per esempio, faccio backup ogni 6 ore perché perdere anche mezza giornata di prenotazioni sarebbe un problema serio.
Quello che non ti dicono sui backup
Il backup non è solo fare la copia. È testarla. Quante volte ho visto colleghi con backup perfetti che poi, al momento del bisogno, scoprono che il file è corrotto o manca un pezzo? Io, una volta al mese, prendo un backup a caso e lo ripristino su un server di test. Solo per essere sicuro che funzioni davvero.
E poi c'è il discorso GDPR. Se fai backup di dati personali (e se lavori con e-commerce o gestionali, li fai per forza), devi cifrarli. Io uso GPG per criptare i dump prima di mandarli in giro. Sembra una rottura, ma è l'unico modo per dormire tranquillo.
Un altro aspetto: i backup costano. Spazio su server, servizi cloud, tempo macchina. Quando faccio un preventivo, includo sempre una voce per i backup. Qualche cliente storce il naso, vuole risparmiare. Allora racconto la storia del 2008. Di solito capiscono.
Gli errori che ho visto (e fatto)
Prima di beccare il sistema giusto, ne ho provate di tutti i colori. Ho fatto backup solo in locale (e quando è morto il disco, beh, capite). Ho usato plugin WordPress che promettevano miracoli e poi si bloccavano a metà. Ho fatto backup manuali "quando mi ricordavo" (spoiler: non mi ricordavo mai).
Il peggior errore? Fidarmi del backup automatico del provider. "Tranquillo, facciamo noi backup giornalieri." Finché un giorno un cliente ha cancellato per sbaglio mezza tabella, chiedo il ripristino, e mi dicono che il loro ultimo backup funzionante era di 10 giorni prima. Da quel momento: backup sempre in casa, sempre sotto il mio controllo.
Un artigiano di Civezzano per cui ho fatto un gestionale mi ha insegnato una cosa: lui ogni sera, prima di chiudere bottega, fa un backup del suo lavoro del giorno su una chiavetta USB che porta a casa. Vecchia scuola, ma efficace. Ho applicato lo stesso principio ai dati digitali: ridondanza e semplicità.
Non è solo questione di tecnologia
Alla fine, i backup sono una forma di rispetto. Rispetto per il lavoro tuo e dei tuoi clienti. Quel e-commerce del 2008 si è ripreso, ha continuato a crescere. Ma io quella lezione non l'ho dimenticata. Ogni volta che vedo un cliente nuovo con un sito fatto da altri e scopro che non ha backup, è la prima cosa che sistemo.
Certo, non è sexy come parlare di AI o di nuove tecnologie. Ma quando alle 2 di notte ti chiama un cliente in panico perché "ho cancellato tutto", e tu in 20 minuti ripristini tutto dalla copia di 6 ore prima, capisci che quei quattro minuti al lunedì mattina per controllare i log sono il miglior investimento che puoi fare.
Se hai un sito, un gestionale, qualsiasi cosa che contenga dati importanti, e non hai un sistema di backup automatico, fermati un attimo. Non aspettare di perdere tutto per capire che ne vale la pena. Io l'ho imparato sulla mia pelle, tu puoi risparmiarti quella brutta esperienza.
Se vuoi una mano a mettere in piedi un sistema di backup solido per il tuo progetto, o semplicemente verificare che quello che hai funzioni davvero, scrivimi. Magari davanti a un caffè qui a Trento ti racconto anche il resto della storia del 2008. C'è una parte con il cliente che mi offre da bere dopo che abbiamo recuperato tutto che è abbastanza esilarante.
Ti serve aiuto con questo argomento?
Sono disponibile per consulenze, sviluppo e supporto tecnico. Contattami per discutere il tuo progetto.
Servizi correlati
Articoli correlati
Cache e CDN: velocizzare senza impazzire
Ti spiego con parole semplici come funzionano cache e CDN, quando servono davver...
Alle 3 di notte: quando un cliente mi chiama per un hack
La telefonata che nessun sviluppatore vuole ricevere. Storia vera di un sito com...
Cache e CDN: come velocizzare un sito senza impazzire
Ti spiego cache e CDN come li spiego ai miei clienti: niente paroloni, solo quel...