backup e rsync

Avere una politica di backup che ci permetta di limitare i danni in caso di errori o problemi è una necessità che risale all’origine dell’informatica.

UNIX e Linux hanno ovviamente diversi tool che vengono in aiuto per questa necessità, e, almeno nel caso di una macchina singola, si possono implementare delle politiche asolutamente soddisfacenti con soli tool interni come cron ed rsync.

Come molti comandi della shell UNIX rsync è estremamente versatile. Il comando di base è:

rsync /path/to/source/file /path/to/destination

Come suggerisce il nome rsync non è un semplice tool per la copia dei file ma si occupa di sincronizzare due directory effettuando la copia dei soli file che lo richiedono.

Tendenzialmente rsync è utile soprattutto se si ha la necessità di copiare molti file e quindi sarà necessario utilizzare l’opzione -r

rsync -r /path/to/source/ /path/to/destination
rsync -r /path/to/source /path/to/destination

Ho riportato due comandi per sottolineare una particolarità di rsync. Se si copia una directory e si specifica / nel path della sorgente il contenuto della directory verrà copiato nella destinazione; se invece il path viene scritto senza / è la directory che viene copiata nella destinazione.

Rsync generalmente non ha quasi nessun output a video, il che è ottimo per script in crontab, se però si sta eseguendo il backup in real time si vorrà probabilmente un’indicazione di come sta procedendo l’attività. PEr questo si hanno due opzioni -v e –progress.

rsync generalmente controlla le dimensioni e la data di ultima modifica per capire se devono essere copiate. Sono però disponibili specifiche opzioni per fare controlli differenti. Ad esempio –size-only se si vole considerare solo le dimensioni del file o –checksum se si vuole un conformto più affidabile anche se più oneroso.

Le opzioni di questo comando sono svarite ma generalmente se si stanno effettuando dei backup -a farà si che vengano attivate le opzioni che più comunemente vengono utilizzate per questa attività.

Una mensione particolare merita l’opzione -b; in questa modalità rsync effettuerà un backup incrementale spostando i file rimossi dalla sorgente in un appositp path e scrivendo su un file tutte le operazioni effettuate. Si otterrà quindi una directory allineata a quella sorgente e si manterranno i file e le informazioni necessari per ricostruire la situazione al momento del backup precedente.

Un esempio di comando reale potrebbe quindi essere

rsync -avb --size-only --delete --log-file=/path/to/file_log/file.log --backup-dir=/path/to/directory_file_incrementali/ --progress /directory/source/ /directory/destination/

mysql e binlog

Una delle caratteristiche più interessanti di MySQL è il suo sistema di replica. Questo lo rende possibili molte configurazioni che rendon il prodotto estremamente flessibile.

Si può abilitare MySQL per replicare tutte le query che comportano delle modifiche alla base dati su degli appositi file di log detti binlog. Questo, con le nuove versioni di MySQL può avvenire in due modi: riportando le query o riportando le modifiche ai file. Non approfondiremo oltre, in questo post, le differenze tra queste due modalità e faremo riferimento al caso in cui vengano riportate le query. Gran parte delle considerazioni rimangono valide in entrambi i casi.

I binlog servono almeno in 3 situazioni molto critiche:

  • assieme ai backup per la Point in Time Recovery: se al momento del backup si sono salvati valori riportati da “show master status\G”, è possibile riapplicare tutte le modifiche effettuate al database e riporatte sui binary log fino ad un preciso istante. Idealmente ricosytruendo lo sato del database subito prima del problema.
  • sistemi in replica: i binlog solo lo strumento attraverso il quale i vari nodi in replica si comunicano le rispettive modifiche alla base dati.
  • analisi a posteriori di bug o attacchi

Si noti, avendone la possibilità, è opprtuno valutare se farli scrivere su dischi e attraverso un controller diverso da quelli utilizzati per i file di dati, trattandosi di una scrittura potenzialmente pesante.

La generazione dei bynary log su MySQL non è abilitata di default ma bisogna aggiungere un gruppo di statement di configurazione come il seguente prima delle configurazione dei vari Engine :

server-id = 1
log_bin = /data/log/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 500M
log_slave_updates = 1
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name

la lista dei parametri sopra non è esaustiva.

  • server-id: questo valore è fondamentale nei sistemi in replica in quanto permette al server di capire quale nodo ha ricevuto la query per primo. Bisogna quindi assegnare un numero univoco per ogni server coinvolto
  • log_bin: è il template del nome del file che viene generato. Questa linea abilita anche i binlog.
  • expire_log_days: definisce per quanti giorni i binlog vengono mantenuti da MySQL sul disco
  • max_binlog_size: definisce le dimensioni massime del file. Al raggiungimento di questo limite il file viene chiuso e ne viene aperto un’altro. Nello scegliere le dimensioni di questi file bisogna fare un compromesso tra le loro dimensioni e il loro numero per trovare la situazione più facilmente gestibile.
  • log_slave_updates: nei sistemi in replica permette di specificare se il nodo deve salvare sul binlog anche le query che ha ricevuto dal proprio master o solo eventuali query ricevute direttamente
  • binlog_do_db: se presente specifica la lista dei database le cui modifiche devono essere riportate sui binary log
  • binlog_ignore_db: se presente specifica la lista dei database le cui modifiche non devono essere riportate sui binary log

Attenzione a statement come gli ultimi due:

  • hanno comportamenti differenti nel caso si abbiano nei binary log le query o le modifiche
  • il db a cui si riferische è quello della connessione che non è necessariamente quello della query (es. select * from agenda.telefono)

E’ assolutamente opportuno un approfondimento sui manuali ufficiale prima di procedere con sistemi di produzione.

Come si può dedurre dal nome indipendentemente dal formato scelto i binlog sono file binary non facilmente gestibili con gli strumenti standard di UNIX. Viene in aiuto un tool specifico mysqlbinlog. Questo comando applicato ad una serie di file manda in standard output i comandi sql nella giusta sequenza temporale. Ha molte opzioni e, ovviamente, bisogna far riferimento al suo manuale prima di usarlo su sistemi di produzione.