Pianificare i backup per MariaDB e MySQL

Oggi i dati sono considerati un vero e proprio valore economico per le aziende. Allo stesso tempo i database sono la componente IT più carica di lavoro, e questo rappresenta un rischio: un errore del software, dell'hardware o semplicemente degli esseri umani può provocare una perdita di dati. Occorre quindi mettersi al riparo, effettuando backup regolari e affidabili. Ma bisogna anche considerare che un backup è un'operazione onerosa, che può provocare un rallentamento o un blocco temporaneo delle applicazioni. Esistono diversi modi di effettuare il backup dei database. Ognuno presenta diverse caratteristiche, e non esiste una scelta giusta per tutti i casi. Occorre pianificare i backup in base ai bisogni dell'organizzazione, al workload del database server e al valore dei dati. I fattori principali che dovrebbero influenzare la pianificazione di un backup sono i seguenti, ma è comunque consigliabile avvalersi della consulenza di un esperto. Tipi di backup: pro e contro Un primo modo di catalogare i backup sono gli effetti sulla disponibilità del server: • Backup a caldo: sono effettuati mentre il server è attivo. Si evita così il downtime, ma le operazioni saranno rallentate per tutta la durata del backup. • Backup a freddo: il server viene arrestato prima del backup. Utile se si considera accettabile il downtime, a patto che il backup sia più rapido. Possiamo anche catalogare i backup in base al modo in cui i dati sono scritti: • Backup fisico: si copiano i file delle tabelle. Può essere effettuato a caldo o a freddo, ma occorre almeno un lock sulle tabelle per ottenere un backup integro. • Backup logico o dump: si salvano i comandi SQL necessari a ricreare il database. Il backup logico occupa molto più spazio e il restore sarà molto più lento. Permette però di spostare i dati su versioni diverse di MariaDB/MySQL o, in alcuni casi, esportarli verso altri database relazionali. Il backup logico può essere effettuato solo a caldo. • CSV: le dimensioni e i tempi del backup sono una via di mezzo tra le soluzioni precedenti. I tempi di ripristino però si allungano. Il backup deve essere effettuato a caldo. Il formato CSV è universale e i dati potranno essere utilizzati da altri software (DBMS, NoSQL, ETL...). Infine, possiamo catalogare i backup in base a quali dati vengono salvati: • Backup completo: tutti i dati e i metadati vengono copiati. Ripristinare un backup completo significa ricreare esattamente un database nello stato in cui si trovava al momento del backup. • Backup parziale: vengono copiati solo i dati più recenti, cioè le modifiche apportate dopo l'ultimo backup completo. Questo tipo di backup normalmente è molto più veloce e può essere eseguito a caldo copiando il binary log. Il ripristino però è più lento e complesso. • Backup selettivo: si copiano solo i dati più caldi, o si escludono le tabelle che possono essere ricreate senza servirsi di un backup (dati aggregati, business intelligence). Se il backup è logico, la selezione dei dati può essere più granulare. Uno strumento da segnalare è Percona Xtrabackup. Questo tool effettua una copia fisica dei file senza arrestare il server e senza acquisire un lock sulle tabelle. In questo modo la copia avrà un impatto minimo sulle attività del server. Questo procedimento è possibile perché Xtrabackup incorpora una versione semplificata di InnoDB, che gli consente di effettuare un backup inconsistente dei tablespace e dei log delle transazioni, per poi ripararlo. Si ricorda inoltre che un buon backup (se non è parziale) deve includere tutti gli elementi utili a ripristinare non solo il database, ma l'istanza di MariaDB o MySQL: • file di log; • file di configurazione; • script di manutenzione (cron job, etc). Replica e cluster In presenza della replica nativa (asincrona), il backup può essere effettuato su uno slave o sul master. Normalmente la scelta degli slave è più efficiente, ma occorre chiedersi: • I dati sugli slave sono sufficientemente aggiornati? • Se gli slave sono utilizzati dalle applicazioni per alleggerire il workload del master, possono sopportare l'onere del backup? Si ricorda che uno slave non dovrebbe mai essere considerato un backup di per sé. I motivi sono molti, ma si pensi a un errore del DBA o un bug di un'applicazione che cancella dati molto importanti: i dati verranno cancellati anche sugli slave. In presenza di un cluster Galera (replica sincrona, active-active) è possibile effettuare il backup da qualsiasi nodo. Può essere consigliabile, o necessario, sceglierne un nodo poco utilizzato dalle applicazioni, o particolarmente efficiente. Pianificare i backup Un piano di backup per un database medio-grande, di solito, comprende sia backup completi che parziali. Entrambi i tipi di backup dovrebbero essere schedulati nei momenti di attività più ridotta: tipicamente la notte, magari quella di sabato o domenica; oppure, se si tratta di un database aziendale e non collegato a internet, un qualsiasi momento in cui gli uffici sono chiusi. I backup completi possono essere effettuati più raramente. Quindi si sceglie il momento del giorno, della settimana o del mese in cui il database è meno busy. La frequenza dipende soprattutto dall'importanza dei dati. Normalmente si preferirà il backup a caldo, ma in qualche caso un breve downtime può essere preferibile a un rallentamento. I backup parziali si eseguono più frequentemente, approfittando del fatto che sono meno impegnativi per il server. In questo modo, in caso di disastro, non si perderanno tutte le modifiche effettuate dall'ultimo backup completo. I dati sensibili dovranno essere criptati, se non sono criptati alla fonte. La crittografia può avvenire durante il backup o subito dopo. E' importante conservare la chiave in modo sicuro. Se i dati sensibili verranno copiati attraverso la rete, occorrerà utilizzare una connessione sicura. L'ultimo backup completo deve essere immediatamente disponibile in caso di disastro, ma non dovrebbe trovarsi (solo) sul server o nel luogo fisico in cui si trova il database originale. Lo stesso vale per i backup parziali recenti. I vecchi backup completi possono essere conservati per un certo periodo di tempo per ragioni storiche, o nel caso in cui l'ultimo backup sia danneggiato. La creazione di una procedura di backup deve comunque terminare con una fase di test. Occorre verificare non solo che il backup venga creato, ma anche che la procedura di ripristino funzioni e generi dati corretti. Inoltre la procedura di backup dovrebbe verificare l'integrità del backup, ad esempio servendosi dell'hash MD5.