Un disastro di solito provoca un'interruzione, il che significa tempi di inattività del sistema e potenziale perdita di dati. Una volta rilevato il blackout, attiviamo il nostro piano di ripristino di emergenza per riprenderlo. Ma sarebbe una sorpresa, se non c'è il backup, o dopo lunghe ore di ripristino, vedi che non è quello che ti serve.
Sebbene le interruzioni possano essere costose, spesso c'è un impatto finanziario che può essere dannoso per l'azienda e la perdita di dati può essere un motivo per chiudere l'azienda.
Per ridurre al minimo la perdita di dati, è necessario disporre di più copie di dati in vari luoghi. Possiamo progettare la nostra infrastruttura in diversi livelli e astrarre ogni livello da quello sottostante. Ad esempio, creiamo un livello per i cluster di istanze di database per la protezione da guasti hardware. Replichiamo i database tra i data center in modo da poterci difendere da un guasto del data center. Ogni livello aggiuntivo aggiunge complessità, che può diventare un incubo da gestire. Tuttavia, in sostanza, un backup assumerà il ruolo centrale nel ripristino di emergenza.
Ecco perché è fondamentale essere sicuri che sia qualcosa su cui possiamo fare affidamento. Ma come raggiungere questo obiettivo? Bene, una delle opzioni è verificare se i backup sono stati eseguiti in base alle ultime righe dello script di backup.
Un semplice esempio:
#!/bin/sh
mysqldump -h 192.168.1.1 -u user -ppassword dbname > filename.sql
if [ "$?" -eq 0 ]; then
echo "Success."
else
echo "Error."
fiE se lo script di backup non si avviasse affatto? Google offre un bel po' di risultati di ricerca per "Linux cron, non in esecuzione".
Purtroppo, i database open source spesso non offrono repository di backup.
Un altro test di backup. Potresti aver sentito parlare del gatto di Schrödinger. Una nota teoria del backup di Schrödinger è . "La condizione di qualsiasi backup è sconosciuta fino a quando non viene tentato un ripristino." Sembra un approccio semplice, ma un tale tentativo significherebbe che devi configurare un ambiente di test, copiare i file e eseguire il ripristino ... dopo ogni backup.
In questo articolo, vedremo come utilizzare ClusterControl per assicurarti che il backup venga eseguito per ottenere database di livello aziendale con database Open Source.
Rapporti di backup
ClusterControl è stato mirato ai rapporti operativi. Il reporting operativo fornisce supporto per il monitoraggio e il controllo quotidiani delle attività aziendali. Il rapporto di backup è uno dei tanti. Puoi trovare rapporti come:
- Rapporto di sistema giornaliero
- Rapporto sull'aggiornamento del pacchetto
- Rapporto sul cambio di schema
- Disponibilità
- Backup
Ma perché avresti bisogno di questo?
Potresti già disporre di un eccellente strumento di monitoraggio con tutte le possibili metriche/grafici e probabilmente hai anche impostato avvisi basati su metriche e soglie (alcuni avranno anche consulenti automatici che forniscono loro consigli o correggono le cose automaticamente). Va bene, avere visibilità sul tuo il sistema è importante; tuttavia, devi essere in grado di elaborare molte informazioni.
Come funziona? ClusterControl raccoglie informazioni sul processo di backup, sui sistemi, sulle piattaforme e sui dispositivi nell'infrastruttura di backup quando viene attivato il processo di backup. Tutte queste informazioni vengono aggregate e archiviate in un CMON (database interno), quindi non è necessario eseguire ulteriori query su database particolari. Inoltre, quando scopre che hai un cluster in esecuzione, ma non c'era alcun backup, verrà segnalato anche questo.
Nei dettagli del rapporto, puoi tenere traccia di un ID di backup con dati dettagliati su posizione, dimensione, ora e metodo di backup. I modelli funzionano con dati per diversi tipi di database, quindi quando gestisci il tuo ambiente misto, otterrai la stessa sensazione e aspetto. Aiuta a gestire meglio i diversi backup di database.
Rapporti CLI
Per coloro che preferiscono l'interfaccia a riga di comando, una buona opzione per tenere traccia dei backup ClusterControl Command Line Interface (CLI).
CLI consente di eseguire la maggior parte delle funzioni disponibili in ClusterControl utilizzando semplici comandi. L'esecuzione del backup e i rapporti di backup sono uno di questi.
Utilizzato insieme alla potente GUI, offre agli utenti di ClusterControl modi alternativi per gestire i propri ambienti di database open source utilizzando il motore che preferiscono.
$ s9s backup --list --cluster-id=1 --long --human-readable
ID CID STATE OWNER HOSTNAME CREATED SIZE FILENAME
1 1 COMPLETED dba 10.0.0.5 07:21:39 252K mysqldump_2017-05-09_072135_mysqldb.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:21:43 1014 mysqldump_2017-05-09_072135_schema.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:03 109M mysqldump_2017-05-09_072135_data.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:07 679 mysqldump_2017-05-09_072135_triggerseventsroutines.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:20 252K mysqldump_2017-05-09_073016_mysqldb.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:24 1014 mysqldump_2017-05-09_073016_schema.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:44 109M mysqldump_2017-05-09_073016_data.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:49 679 mysqldump_2017-05-09_073016_triggerseventsroutines.sql.gzA partire dalla versione 1.4.1, lo script di installazione installerà automaticamente questo pacchetto sul nodo ClusterControl. La CLI fa parte del pacchetto s9s-tools. Puoi anche installarlo separatamente su una macchina diversa per gestire il cluster di database in remoto. Simile a ClusterControl, utilizza la comunicazione SSH sicura.
Verifica automatica del backup
Un backup non è un backup se non siamo in grado di recuperare i dati. La verifica dei backup è qualcosa che di solito viene trascurato da molte aziende. Vediamo come ClusterControl può automatizzare la verifica dei backup e aiutare a evitare sorprese.
In ClusterControl, seleziona il tuo cluster e vai alla sezione "Backup", quindi seleziona "Crea backup".
La funzione di verifica automatica del backup è disponibile per i backup pianificati, quindi scegliamo l'opzione "Programma backup".
Quando si pianifica un backup, oltre a selezionare le opzioni comuni come il metodo o l'archiviazione, è necessario specificare anche la pianificazione/frequenza. In questo esempio, imposteremo la verifica del backup MySQL. Tuttavia, lo stesso può essere ottenuto per i database PostgreSQL e Timescale.
Quando la verifica del backup è selezionata, verrà visualizzata un'altra scheda.
Qui possiamo impostare tutti i passaggi necessari per preparare l'ambiente. Quando viene fornito l'IP, possiamo procedere e pianificare tale backup. Al termine del backup, verrà copiato in un ambiente di verifica del backup temporaneo (opzione "ripristina backup attivo"). Dopo un aggiornamento riuscito, vedrai lo stato della verifica nella scheda del repository di backup.
Esecuzioni di backup e servizi di integrazione non riusciti
Un'altra opzione interessante per ottenere maggiori indizi sull'esecuzione del backup consiste nell'utilizzare i servizi di integrazione ClusterControl. Puoi controllare lo stato di esecuzione del backup con servizi di terze parti.
L'integrazione di strumenti di terze parti consente di automatizzare gli avvisi con altri sistemi popolari. Attualmente ClusterControl supporta ServiceNow, PagerDuty, VictorOps, OpsGenie, Slack, Telegram e Webhooks.
Di seguito possiamo vedere un esempio di integrazione del canale Slack. Ogni volta che si verifica un evento di backup, apparirà nel canale slack.
Conclusione
I backup sono obbligatori in qualsiasi ambiente. Ti aiutano a proteggere i tuoi dati e sono al centro di qualsiasi scenario di ripristino di emergenza. ClusterControl può aiutare ad automatizzare il processo di backup dei database e, in caso di errore, ripristinarlo con pochi clic. Inoltre, puoi essere certo che vengano eseguiti con successo e affidabilità, quindi in caso di disastro non perderai i tuoi dati.
