Opzioni di backup su cloud per database MySQL e MariaDB

L'obiettivo principale del backup dei dati è, ovviamente, la possibilità di eseguire il rollback e di accedere ai propri archivi in ​​caso di guasto dell'hardware. Per fare affari oggi, hai bisogno della certezza di sapere che in caso di disastro i tuoi dati saranno protetti e accessibili. Dovresti archiviare i tuoi backup fuori sede, nel caso in cui il tuo data center vada in fiamme.

La protezione dei dati resta una sfida per le piccole e medie imprese. Le aziende di piccole e medie dimensioni preferiscono archiviare i dati della propria azienda utilizzando l'archiviazione con collegamento diretto, con la maggior parte delle aziende che prevede di eseguire copie di backup fuori sede. L'approccio allo storage locale può portare a uno dei dilemmi più gravi che l'azienda moderna può affrontare:la perdita di dati in caso di disastro.

Molti fattori vengono presi in considerazione quando si giudica se consentire il trasferimento fuori sede di un database critico per l'azienda e quando si sceglie un fornitore adatto a farlo. I metodi tradizionali come la scrittura su nastro e la spedizione a una posizione remota possono essere un processo complicato che richiede hardware speciale, personale adeguatamente formato e procedure per garantire che i backup siano regolarmente prodotti, protetti e che le informazioni in essi contenute siano verificate per l'integrità. Le piccole imprese di solito hanno budget IT ridotti. Spesso non possono permettersi di avere un datacenter secondario, anche se dispongono di un datacenter dedicato. Tuttavia, è comunque importante conservare una copia dei file di backup fuori sede. Disastri come uragani, inondazioni, incendi o furti possono distruggere i tuoi server e storage. La conservazione dei dati di backup in un data center separato garantisce la sicurezza dei dati, indipendentemente da ciò che sta accadendo nel data center principale. L'archiviazione su cloud è un ottimo modo per risolvere questo problema.
Con l'approccio del backup su cloud, è necessario considerare una serie di fattori. Alcune delle domande che hai sono:

• I dati di backup sono protetti quando sono inattivi nel data center esterno?
• Il trasferimento da o verso il data center esterno tramite la rete Internet pubblica è sicuro?
• Ci sono effetti sull'RTO (Recovery Time Objective)?
• Il processo di backup e ripristino è abbastanza semplice per il nostro personale IT?
• Sono necessarie modifiche ai processi esistenti?
• Sono necessari strumenti di backup di terze parti?
• Quali sono i costi aggiuntivi in ​​termini di software o trasferimento dati richiesti?
• Quali sono i costi di archiviazione?

Funzionalità di backup quando si esegue un backup nel cloud

Se il tuo server MySQL o la destinazione di backup si trova in un'infrastruttura esposta come un cloud pubblico, un provider di hosting o è connesso tramite una rete WAN non affidabile, devi pensare ad azioni aggiuntive nella tua policy di backup. Esistono diversi modi per eseguire i backup del database per MySQL e, a seconda del tipo di backup, il tempo di ripristino, le dimensioni e le opzioni dell'infrastruttura variano. Poiché molte delle soluzioni di archiviazione cloud sono semplicemente archiviazione con front-end API diversi, qualsiasi soluzione di backup può essere eseguita con un po' di scripting. Quindi quali sono le opzioni che abbiamo per rendere il processo semplice e sicuro?

Crittografia

È sempre una buona idea applicare la crittografia per migliorare la sicurezza dei dati di backup. Un semplice caso d'uso per implementare la crittografia è dove vuoi inviare il backup a un archivio di backup fuori sede situato nel cloud pubblico.

Quando si crea un backup crittografato, una cosa da tenere a mente è che di solito ci vuole più tempo per il ripristino. Il backup deve essere decrittografato prima di qualsiasi attività di ripristino. Con un grande set di dati, questo potrebbe introdurre alcuni ritardi nell'RTO.

D'altra parte, se stai utilizzando la chiave privata per la crittografia, assicurati di archiviare la chiave in un luogo sicuro. Se manca la chiave privata, il backup sarà inutile e irrecuperabile. Se la chiave viene rubata, tutti i backup creati che utilizzano la stessa chiave verrebbero compromessi poiché non sono più protetti. Puoi utilizzare il popolare GnuPG o OpenSSL per generare le chiavi private o pubbliche.
Per eseguire la crittografia mysqldump utilizzando GnuPG, genera una chiave privata e segui la procedura guidata di conseguenza:

$ gpg --gen-key

Crea un semplice backup di mysqldump come al solito:

$ mysqldump --routines --events --triggers --single-transaction db1 | gzip > db1.tar.gz

Crittografa il file di dump e rimuovi il backup semplice precedente:

$ gpg --encrypt -r ‘[email protected]’ db1.tar.gz
$ rm -f db1.tar.gz

GnuPG aggiungerà automaticamente l'estensione .gpg al file crittografato. Per decrittografare,
esegui semplicemente il comando gpg con --decrypt flag:

$ gpg --output db1.tar.gz --decrypt db1.tar.gz.gpg

Per creare un mysqldump crittografato utilizzando OpenSSL, è necessario generare una chiave privata e una chiave pubblica:
OpenSSL req -x509 -nodes -newkey rsa:2048 -keyout dump.priv.pem -out dump.pub.pem

Questa chiave privata (dump.priv.pem) deve essere conservata in un luogo sicuro per future decrittazioni. Per mysqldump, è possibile creare un backup crittografato collegando il contenuto a openssl, ad esempio

mysqldump --routines --events --triggers --single-transaction database | openssl smime -encrypt -binary -text -aes256
-out database.sql.enc -outform DER dump.pub.pem

Per decifrare, usa semplicemente la chiave privata (dump.priv.pem) insieme al flag -decrypt:
openssl smime -decrypt -in database.sql.enc -binary -inform

DEM -inkey dump.priv.pem -out database.sql

Percona XtraBackup può essere utilizzato per crittografare o decrittografare backup locali o in streaming con l'opzione xbstream per aggiungere un altro livello di protezione ai backup. La crittografia viene eseguita con la libreria libgcrypt. Sia l'opzione --encrypt-key che l'opzione --encryptkey-file possono essere utilizzate per specificare la chiave di crittografia. Le chiavi di crittografia possono essere generate con comandi come

$ openssl rand -base64 24
$ bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1

Questo valore può quindi essere utilizzato come chiave di crittografia. Esempio del comando innobackupex che utilizza --encrypt-key:

$ innobackupex --encrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1” /storage/backups/encrypted

L'output del comando OpenSSL sopra può anche essere reindirizzato a un file e può essere trattato come un file chiave:

openssl rand -base64 24 > /etc/keys/pxb.key

Usalo invece con l'opzione --encrypt-key-file:

innobackupex --encrypt=AES256 --encrypt-key-file=/etc/keys/pxb.key /storage/backups/encrypted

Per decrittografare, usa semplicemente l'opzione --decrypt con --encrypt-key o --encrypt-key-file appropriato:

$ innobackupex --decrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1”
/storage/backups/encrypted/2018-11-18_11-10-09/

Per ulteriori informazioni sulla crittografia MySQL e MariaDB, consulta il nostro altro post sul blog.

Compressione

All'interno del mondo del backup su cloud di database, la compressione è uno dei tuoi migliori amici. Non solo può risparmiare spazio di archiviazione, ma può anche ridurre significativamente il tempo necessario per scaricare/caricare i dati.
Ci sono molti strumenti di compressione disponibili là fuori, vale a dire gzip, bzip2, zip, rar e 7z.
Normalmente, mysqldump può avere i migliori tassi di compressione in quanto è un file di testo piatto. A seconda dello strumento di compressione e del rapporto, un mysqldump compresso può essere fino a 6 volte più piccolo della dimensione del backup originale. Per comprimere il backup, puoi reindirizzare l'output di mysqldump a uno strumento di compressione e reindirizzarlo a un file di destinazione. Puoi anche saltare diverse cose come commenti, istruzioni di blocco delle tabelle (se InnoDB), saltare GTID eliminato e trigger:

mysqldump --single-transaction --skip-comments --skip-triggers --skip-lock-tables --set-gtid-purged OFF --all-databases | gzip > /storage/backups/all-databases.sql.gz

Con Percona Xtrabackup è possibile utilizzare la modalità streaming (innobackupex), che invia il backup a STDOUT in uno speciale formato tar o xbstream invece di copiare i file nella directory di backup. Avere un backup compresso potrebbe farti risparmiare fino al 50% della dimensione del backup originale, a seconda del set di dati. Aggiungi l'opzione --compress nel comando di backup. Utilizzando xbstream nei backup in streaming, puoi accelerare il processo di compressione utilizzando l'opzione --compress-threads. Questa opzione specifica il numero di thread creati da xtrabackup per la compressione parallela dei dati. Il valore predefinito per questa opzione è 1. Per utilizzare questa funzione, aggiungere l'opzione a un backup locale. Un esempio di backup con compressione:

innobackupex --stream=xbstream --compress --compress-threads=4 > /storage/backups/backup.xbstream

Prima di applicare i log durante la fase di preparazione, i file compressi dovranno essere
decompressi utilizzando xbstream:
Quindi, utilizzare qpress per estrarre ogni file che termina con .qp nella rispettiva directory prima di
eseguire -- comando apply-log per preparare i dati MySQL.

$ xbstream -x < /storage/backups/backup.xbstream

Limita la velocità effettiva della rete

Un'ottima opzione per i backup su cloud è limitare la larghezza di banda dello streaming di rete (Mb/s) quando si esegue un backup. Puoi ottenerlo con lo strumento pv. L'utilità pv viene fornita con l'opzione di modifica dei dati -L RATE, --rate-limit RATE che limita il trasferimento a un massimo di byte RATE al secondo. L'esempio seguente lo limiterà a 2 MB/s.

$ pv -q -L 2m

Nell'esempio seguente, puoi vedere xtrabackup con gzip parallelo, crittografia

 /usr/bin/innobackupex --defaults-file=/etc/mysql/my.cnf --galera-info --parallel 4 --stream=xbstream --no-timestamp . | pv -q -L 2m | pigz -9 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-008688-19992-72450efc3b6e9e4f.tmp > /home/ubuntu/backups/BACKUP-3445/backup-full-2018-11-28_213540.xbstream.gz.aes256 ) 2>&1.

Trasferisci backup su Cloud

Ora, quando il backup è compresso e crittografato, è pronto per il trasferimento.

Google cloud

Lo strumento da riga di comando gsutil viene utilizzato per gestire, monitorare e utilizzare i tuoi bucket di archiviazione su Google Cloud Storage. Se hai già installato l'utility gcloud, hai già installato gsutil. Altrimenti, segui le istruzioni per la tua distribuzione Linux da qui.

Per installare la CLI gcloud puoi seguire la procedura seguente:

curl https://sdk.cloud.google.com | bash

Riavvia la shell:

exec -l $SHELL

Esegui gcloud init per inizializzare l'ambiente gcloud:

gcloud init

Con lo strumento da riga di comando gsutil installato e autenticato, crea un bucket di archiviazione regionale denominato mysql-backups-storage nel progetto corrente.

gsutil mb -c regional -l europe-west1 gs://severalnines-storage/
Creating gs://mysql-backups-storage/

Amazon S3

Se non stai utilizzando RDS per ospitare i tuoi database, è molto probabile che tu stia facendo i tuoi backup. La piattaforma AWS di Amazon, S3 (Amazon Simple Storage Service) è un servizio di archiviazione dati che può essere utilizzato per archiviare backup di database o altri file aziendali critici. Sia che si tratti dell'istanza Amazon EC2 o del tuo ambiente on-premise puoi utilizzare il servizio per proteggere i tuoi dati.

Mentre i backup possono essere caricati tramite l'interfaccia web, l'interfaccia della riga di comando s3 dedicata può essere utilizzata per farlo dalla riga di comando e tramite script di automazione del backup. Se i backup devono essere conservati per un tempo molto lungo e il tempo di ripristino non è un problema, i backup possono essere trasferiti al servizio Amazon Glacier, fornendo uno storage a lungo termine molto più economico. I file (oggetti amazon) sono logicamente archiviati in un enorme contenitore piatto chiamato bucket. S3 presenta un'interfaccia REST ai suoi interni. Puoi utilizzare questa API per eseguire operazioni CRUD su bucket e oggetti, nonché per modificare autorizzazioni e configurazioni su entrambi.

Il metodo di distribuzione principale per l'AWS CLI su Linux, Windows e macOS è pip, un gestore di pacchetti per Python. Le istruzioni possono essere trovate qui.

aws s3 cp severalnines.sql s3://severalnine-sbucket/mysql_backups

Per impostazione predefinita, S3 fornisce una durata dell'oggetto di undici 9 secondi. Significa che se immagazzini 1.000.000.000 (1 miliardo) di oggetti al suo interno, puoi aspettarti di perdere in media 1 oggetto ogni 10 anni. Il modo in cui S3 ottiene quell'impressionante numero di 9 è replicando automaticamente l'oggetto in più zone di disponibilità, di cui parleremo in un altro post. Amazon ha data center regionali in tutto il mondo.

Archiviazione Microsoft Azure

La piattaforma cloud pubblica di Microsoft, Azure, ha opzioni di archiviazione con la loro interfaccia della linea di controllo. Le informazioni possono essere trovate qui. L'interfaccia della riga di comando di Azure multipiattaforma open source fornisce un set di comandi per l'utilizzo della piattaforma Azure. Offre gran parte delle funzionalità viste nel portale di Azure, incluso l'accesso ai dati avanzati.

L'installazione dell'interfaccia della riga di comando di Azure è abbastanza semplice, puoi trovare le istruzioni qui. Di seguito puoi scoprire come trasferire il backup nello spazio di archiviazione Microsoft.

az storage blob upload --container-name severalnines --file severalnines.sql --name severalnines_backup

Archiviazione ibrida per backup MySQL e MariaDB

Con la crescita del settore dello storage su cloud pubblico e privato, abbiamo una nuova categoria chiamata storage ibrido. Questa tecnologia consente di archiviare i file in locale, con le modifiche sincronizzate automaticamente in remoto nel cloud. Tale approccio deriva dalla necessità di disporre di backup recenti archiviati in locale per un ripristino rapido (RTO inferiore), nonché per obiettivi di continuità aziendale.
L'aspetto importante di un utilizzo efficiente delle risorse è la conservazione dei backup separata. I dati archiviati localmente su unità disco ridondanti verrebbero conservati per un periodo più breve mentre l'archiviazione di backup nel cloud verrebbe conservata per un tempo più lungo. Molte volte il requisito per una conservazione del backup più lunga deriva da obblighi legali per diversi settori (come le telecomunicazioni che devono archiviare i metadati di connessione). I provider cloud come Google Cloud Services, Microsoft Azure e Amazon S3 offrono ciascuno spazio di archiviazione praticamente illimitato, riducendo le esigenze di spazio locale. Ti consente di conservare i tuoi file di backup più a lungo, per tutto il tempo che desideri e non hai problemi di spazio su disco locale.

Quando si pianifica il backup con ClusterControl, ciascuno dei metodi di backup è configurabile con una serie di opzioni su come si desidera eseguire il backup. Il più importante per l'archiviazione su cloud ibrido sarebbe:

• Limitazione della rete
• Crittografia con la gestione delle chiavi integrata
• Compressione
• Periodo di conservazione per i backup locali
• Periodo di conservazione per i backup su cloud

Conclusione

Il cloud ha cambiato il settore del backup dei dati. Grazie al suo prezzo accessibile, le piccole imprese hanno una soluzione fuori sede che esegue il backup di tutti i loro dati.

La tua azienda può trarre vantaggio dalla scalabilità del cloud e dai prezzi con pagamento in base al consumo per le crescenti esigenze di archiviazione. Puoi progettare una strategia di backup per fornire sia copie locali nel data center per il ripristino immediato, sia un gateway senza interruzioni per i servizi di archiviazione cloud da AWS, Google e Azure.

Le funzionalità avanzate di crittografia e compressione TLS e AES a 256 bit supportano backup sicuri che occupano molto meno spazio nel cloud.