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!

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.

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.

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 --ftp-user=utente@aruba.it --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!