Riepilogo post nella categoria Backup

Probabilmente non ci hai mai pensato seriamente, ma posso garantirti da esperienza diretta che una perdita di dati può letteralmente distruggere la tua azienda. Non devi dimenticare che i dati sono il patrimonio più importante della tua azienda, e non è solo riferito ai dati di fatturazione e dei Clienti, ma di know how aziendale. Nel corso della mia carriera, ho visto imprese fallire letteralmente dalla sera alla mattina per colpa di un incidente informatico o per una gestione negligente dei backup aziendali. La vera domanda è: sei assolutamente certo che la tua azienda sia al sicuro da simili rischi?

Il falso mito del "backup manuale"

Molte aziende con cui ho avuto a che fare negli ultimi vent'anni si affidano ancora al cosiddetto "backup manuale": un processo approssimativo e casuale, dove qualcuno periodicamente salva dati importanti su chiavette USB o hard disk esterni senza una vera strategia. Questo approccia nasconde rischi enormi, come ho potuto constatare personalmente in molti interventi di emergenza.

Ad esempio, in un caso specifico, un'azienda ha perso l’intero archivio delle proprie fatture a causa di un ransomware che ha cifrato sia i dati attuali, sia quelli sui backup "manuali", collegati costantemente ai PC. Situazioni del genere causano danni economici e legali che possono mettere in ginocchio qualunque impresa.

Backup automatici: perché sono imprescindibili?

Una strategia corretta e professionale prevede l'utilizzo di backup automatici e incrementali. Questi sistemi, basati su tecnologie come rsync o su servizi cloud specializzati, garantiscono che ogni modifica ai tuoi dati aziendali sia salvata in modo sicuro, automatico e verificabile, minimizzando così il rischio di perdita.

Nella mia attività consulenziale mi occupo personalmente di impostare soluzioni su misura, che siano aderenti alle reali esigenze di ogni singola azienda. Non solo tecnologie cloud (AWS, Google Cloud o Azure), ma anche soluzioni locali come NAS con sincronizzazione automatica e rotazione periodica dei supporti di backup, per garantire una protezione completa.

Gli errori più frequenti che puoi facilmente evitare

Nella mia esperienza diretta, ho visto ripetersi spesso gli stessi errori elementari nella gestione dei backup aziendali:

  • Mancanza di test regolari dei backup: avere un backup non verificato è come non averlo affatto.
  • Backup su dispositivi fisici collegati costantemente: così facendo, un attacco ransomware colpisce contemporaneamente dati originali e copie di sicurezza.
  • Assenza di una politica chiara e condivisa: il personale non qualificato tende a improvvisare, causando confusione e dimenticanze.
  • Scarsa frequenza dei backup: backup sporadici sono inutili per recuperare dati freschi, come ordini recenti, email importanti o documenti critici.

Il ruolo centrale di un piano di Disaster Recovery

Implementare un piano di Disaster Recovery (DR) efficace non è un'opzione facoltativa: oggi è una necessità imprescindibile per qualsiasi impresa che voglia sopravvivere e prosperare nel mondo digitale.

Un piano di DR ben fatto definisce in maniera chiara procedure operative, ruoli e responsabilità precise. Non si limita a stabilire come recuperare i dati, ma descrive dettagliatamente le operazioni per ripristinare completamente l’operatività aziendale. Si tratta di un'attività complessa che richiede competenze tecniche e strategiche avanzate: la stessa complessità che affronto quotidianamente con i miei clienti, affiancandoli nella definizione e nell’implementazione di soluzioni realmente sicure.

Se vuoi approfondire come posso aiutarti concretamente a migliorare la sicurezza dei tuoi backup e definire un piano di Disaster Recovery personalizzato per la tua realtà aziendale, puoi consultare il mio background professionale oppure contattarmi direttamente.

Backup e compliance normativa: hai considerato questo aspetto?

Non dimenticare che un'efficace politica di backup non è solo una questione tecnica, ma anche normativa. Il GDPR prevede infatti l’obbligo esplicito di tutelare i dati personali con strategie tecniche e organizzative adeguate, e la direttiva NIS2 impone alle aziende operanti in settori critici di garantire elevati standard di sicurezza e resilienza.

Trascurare questi aspetti significa esporre la tua azienda a multe pesanti e danni reputazionali gravissimi. Una gestione approssimativa dei backup rappresenta quindi non solo un problema operativo, ma anche legale.

Riguardo la Compliance NIS2, ho redatto una campagna divulgativa molto dettagliata nominata NIS2 Awareness - Dettagli tecnico/operativi sulla Direttiva UE 2022/2555. Dedica un pò del tuo tempo a prendere consapevolezza sull'argomento: è vitale per il tuo business, anche se la tua azienda non dovesse rientrare nel campo d'applicazione normativo.

Il prossimo passo: cosa fare concretamente?

Se dopo aver letto queste informazioni senti di avere dubbi sulla qualità o l’affidabilità della tua politica di backup, la scelta migliore è intervenire subito.

Un audit approfondito da parte di un esperto può evidenziare eventuali vulnerabilità, fornendo soluzioni chiare e attuabili per mettere subito in sicurezza la tua azienda. Nella mia attività, questa è esattamente la tipologia di consulenza strategica e tecnica che offro ai miei clienti: un servizio personalizzato, orientato a garantire sicurezza, conformità normativa e tranquillità operativa.

Non aspettare un incidente informatico per agire. Se desideri proteggere seriamente il futuro della tua azienda, contattami ora: affronteremo insieme le tue esigenze, trasformando la gestione del rischio in un’opportunità di crescita.

Guida Backup dei propri dati su Google

Attenzione! Questo contenuto è vecchioQuesto articolo risale al 2016, quindi i contenuti e le operazioni qui consigliate potrebbero essere diventate obsolete nel corso del tempo.

Bisogna dirlo, Google e tutti i suoi servizi connessi, come Gmail, Google Drive, il Play Store, Google Play Music, sono diventati parte integrante delle nostre vite digitali, e della nostra produttività sia personale, sia lavorativa.

C'è da chiedersi, però, dove vengano salvati tutti i nostri dati, e se esiste la possibilità di scaricare una copia dei propri dati su Google.

Ovviamente, trattandosi di Google, non poteva non essere possibile: ci hanno già pensato, e il sistema per il takeout dei propri dati, così lo definisce Google, esiste ed è molto semplice da usare.

Per prima cosa, avete bisogno di un browser ( anche via smartphone ): cliccate su questo link: Strumenti Dati di Google - Takeout. In questa pagina troverete una lista completa di tutti i servizi connessi al vostro account Google, e dei selettori per selezionare / deselezionare i dati che volete scaricare. Ecco un esempio della pagina "Takeout":

Una volta selezionati tutti i servizi Google che volete scaricare, la pagina seguente chiederà il metodo di esportazione. Consiglio di utilizzare il metodo Invia tramite email il link per il download in formato .zip. Questo metodo è comodo, perchè Google, dopo qualche ora, vi manderà una email con un comodissimo link per accedere alle copie di backup. Ecco come si presenta la pagina di esportazione

A questo punto avete finito, e potete aspettare l'email che conterrà il link per il download. Ecco un esempio di email.

Cliccando su Gestisci Archivi nell'email in arrivo da Google, finirete nella pagina Strumenti Dati - Download dei Dati Google dove vi verrà mostrato un elenco di tutte le esportazioni richieste. Attenzione: le esportazioni richieste "valgono" solo per 7 giorni, dopodichè vengono automaticamente cancellate da Google, quindi assicuratevi di scaricare tutto per tempo. Ecco un esempio di lista di archivi scaricabili.

Google ha reso il backup dei propri dati una cosa davvero semplice. Tra l'altro, usando Google in maniera massiva come nel mio caso ( 78GB di archivio! ), con Google Drive con un piano da 100GB e Gmail per lavoro, più l'archiviazione automatica di foto e video dallo smartphone, l'archivio raggiunge in fretta dimensioni considerevoli.

Buon lavoro e buona archiviazione!

Attenzione! Questo contenuto è vecchioQuesto articolo risale al 2016, quindi i contenuti e le operazioni qui consigliate potrebbero essere diventate obsolete nel corso del tempo.

Stamattina mi è capitato un errore insolito, durante l'importazione di un file di dump di mysql da un server verso un altro server.

Inspiegabilmente, il conteggio delle righe di una tabella sul "server sorgente" era molto più alto rispetto al conteggio delle stesse righe sulla stessa tabella, ma del server di backup.

Quindi, per tentare di capire la ragione del problema, ho creato dapprima un dump della sola tabella "incriminata" dal server sorgente, con

mysqldump -u UTENTE -pPASSWORD --skip-add-locks --compact --quick --lock-tables=false --delayed-insert=true --no-create-info --skip-triggers DATABASE TABELLA | gzip > dump.sql.gz

Una volta effettuato il dump, ho provato ad importarlo sul server di backup, con

gunzip < dump.sql.gz | mysql -u UTENTE -pPASSWORD --force DATABASE

Risultato? Per quella tabella, durante l'importazione, venivano sollevati tantissimi errori da mysql, che recitavano:

ERROR 1265 (01000) at line 683: Data truncated for column 'column_name' at row 10

La ragione del problema? La configurazione del server mysql sul server di backup, in particolare la configurazione del parametro sql-mode su my.cnf, relativa alle impostazioni di safety dell'ambiente mysql.

Ho scoperto che quelle righe nel file di dump erano relative ad un vecchio sottoinsieme di valori che nel server principale erano stati scritti senza la modalità "NO_AUTO_VALUE_ON_ZERO", ovvero la modalità secondo la quale il server mysql non inserirà dei valori NULL di default per le colonne nullabili, se non direttamente specificato.

Per ovviare al problema, quindi, abbiamo 2 soluzioni: la prima è ricostruire la tabella "sorgente" con dei dati corretti, usando il metodo che più vi è comodo. La seconda soluzione è quella di disabilitare alcune impostazioni di safety sul server di backup.

Vi basterà quindi semplicemente rimuovere il token "NO_AUTO_VALUE_ON_ZERO" dalla configurazione di my.cnf per non ricevere più errori nell'importazione.

Ovviamente la soluzione 2 va bene sul server di backup perchè è appunto un server di backup, quindi nessuno vi verrà mai a dire nulla sulla coerenza dei dati o sulla bontà delle configurazioni di safety su quel server mysql. Ad ogni modo, la soluzione più corretta sarebbe quella di correggere le righe con errori di coerenza dei dati all'interno del server di origine e mantenere le impostazioni di safety così come sono per lavorare "allo stato dell'arte".

Nella fattispecie, per correggere la coerenza dei dati, dovrete necessariamente ciclare su tutte le righe della tabella, costruirvi una lista di insert, troncare la tabella, ed eseguire le insert calcolate prima.

Backup di Mysql con mysqldump senza lock sulle tabelle

Attenzione! Questo contenuto è vecchioQuesto articolo risale al 2016, quindi i contenuti e le operazioni qui consigliate potrebbero essere diventate obsolete nel corso del tempo.

Effettuare il backup di uno o più database Mysql è un compito facilmente eseguibile con il tool mysqldump. Basta dargli in pasto qualche parametro, e il backup è pronto. Ad esempio, per effettuare il backup di DB1, DB2 e DB3:

mysqldump -u UTENTE -pPASSWORD --databases DB1 DB2 DB3 | gzip > mysql.sql.gz

Il comando creerà un archivio .gz contenente il dump in formato .sql dei vostri database. Però, c'è un problema: se volete eseguire mysqldump mentre tutti i servizi sono operativi, quindi ad esempio, su un server di produzione attualmente in uso di un sito web, lanciare il comando mysqldump implicherà un serio rallentamento, se non uno stato di blocco, di tutti i servizi che utilizzano mysql.

Per ovviare a questo problema, c'è la soluzione: bisogna lanciare mysqldump senza lock sulle tabelle.

Il comando qui di seguito vi permetterà di lanciare un dump completo di mysql senza particolari problemi su un server di produzione attualmente attivo e in uso, anche se dovesse avere un load molto elevato.

nice -15 mysqldump -u UTENTE -pPASSWORD --skip-add-locks --compact --quick --lock-tables=false --databases DB1 DB2 DB3 | gzip > mysql.sql.gz

Ho personalmente testato il tutto su un VPS Debian da 16GB di RAM, Quad Core, con doppio SSD, lanciando mysqldump su un database di circa 30GB di dati con circa 500 milioni di righe. Il risultato è stato un dump completo in 65 minuti, che non ha assolutamente comportato il blocco dei servizi attivi.

Questo perchè, oltre alle direttive --skip-add-locks e --lock-tables=false ho anche aggiunto --compact --quick ( meno output verboso sul dump ) e soprattutto ho usato nice, che è un semplice tool che modifica la priorità del processo che segue. La priorità di nice va da -20 ( urgentissimo ) a +19 ( fallo quando riesci ). Con nice -15, quindi, andiamo a dare molta meno priorità al processo di mysqldump, che verrà eseguito proprio quando non c'è null'altro da fare a livello di risorse del sistema.

Per finire, un'ultimo consiglio. I backup, in generale, *non* dovrebbero essere mantenuti e conservati sulla macchina principale, quella dalla quale abbiamo eseguito il backup. Il senso del backup è sempre lo stesso: se si rompe tutto sulla macchina A, devo possedere una macchina B che mi faccia da disaster recovery. Quindi, prendete l'abitudine di spostare i vostri backup verso altre macchine remote, meglio se siano preposte solo a contenere backup.

Il comando per inviare un file ad un server remoto, via SSH, è molto facile e potete integrarlo all'interno dei vostri script .sh preposti ai dump e backup ( leggere la nota in fondo alla guida )

sshpass -p 'PASSWORD' scp -l 3000 /file/del/backup UTENTE@SERVER_REMOTO:/directory/destinazione/

Con questo parametro, inviamo al SERVER_REMOTO il file /file/del/backup all'interno della cartella /directory/destinazione usando UTENTE, PASSWORD per l'accesso. In più, con la direttiva -l 3000 passata a scp, impostiamo un limite in kbit/s per l'invio del dump. Molto utile sui server di produzione, dove non bisogna assolutamente saturare la banda di upload.

Attenzione: il comando qui sopra deve essere utilizzato *solo* in fase di test dei sistemi di backup. A regime, bisogna *sempre* usare un fattore di autenticazione a chiave pubblica / privata nell'utilizzo dei tool via SSH come ad esempio scp. Ripeto, è assolutamente sconsigliato usare sshpass se non per testare i sistemi usando un comando veloce e mnemonico.

Attenzione! Questo contenuto è vecchioQuesto articolo risale al 2016, quindi i contenuti e le operazioni qui consigliate potrebbero essere diventate obsolete nel corso del tempo.

Quando capita di dover fare uno spostamento completo di un sito da un server ad un altro, e non si ha accesso SSH, ma soltanto un accesso FTP, scaricare tutti i file della webroot usando un client FTP come FileZilla o WinSCP è lento e noioso, e in più la connessione può cadere durante il trasferimento, obbligando quindi di fatto a ricominciare il mirroring da zero per non avere il pericolo di tralasciare qualche file.

Quindi, se vi capita di dover effettuare un mirroring di una webroot completa, di cui avete gli accessi FTP ma non gli accessi SSH, potete comunque risolvere il problema velocemente. Basta avere sottomano una qualsiasi distribuzione Linux e operare da linea di comando. Vediamo come fare un mirror completo da bash di una webroot accessibile da FTP. I comandi riportati sono validi per Debian / Ubuntu, ma sono facilmente replicabili su qualsiasi macchina Linux.

sudo apt-get install wget
mkdir /home/nome_del_backup; cd /home/nome_del_backup
wget -r -nc -l inf ftp://username_ftp:password_ftp@nome_host

Attenzione: se lo username dovesse contenere un @ ( come ad esempio, il tanto amato e tanto odiato Aruba ) la sintassi del comando qui sopra non andrebbe bene, perchè wget non riuscirebbe ad interpretare correttamente il nome dell'host, quindi, per ovviare al problema, basta eseguire

wget -r -nc -l inf --ftp-user=user_ftp@example --ftp-password=password_ftp ftp://nome_host

Prendendo proprio ad esempio Aruba, la sintassi sarebbe:

wget -r -nc -l inf [email protected] --ftp-password=password_ftp ftp://ftp.nome_del_dominio.it

Ovviamente, modificare "/home/nome_del_backup" con la propria cartella desiderata di destinazione del mirror, e cambiare "username_ftp", "password_ftp" e "dominio_da_dumpare.it" con i vostri dati di accesso e il dominio da dumpare.

Se il dump dovesse interrompersi prima del tempo, o se dovesse capitare qualsiasi altro problema che implichi lo stallo del dump via WGET, l'opzione -nc permette di riavviare lo stesso identico comando dicendo a wget di non riscaricare di nuovo le risorse già acquisite nel run precedente.

Una volta completato il tutto, si può creare un archivio .tar.gz del mirror con il comando

tar -zcvf nome-archivio-backup.tar.gz /home/nome_del_backup

Anche in questo caso, cambiare il nome dell'archivio e della directory sorgente con i vostri parametri. Per il resto, avete finito il lavoro!