Mysql
 sql >> Database >  >> RDS >> Mysql

Come eseguire il backup di un database crittografato con Percona Server per MySQL 8.0

È quasi garantito che le interruzioni di produzione avvengano prima o poi. Lo sappiamo, quindi pianifichiamo backup, creiamo database in standby di ripristino, convertiamo singole istanze in cluster.

Ammettendo la necessità di uno scenario di ripristino adeguato, dobbiamo analizzare la possibile sequenza temporale del disastro e gli scenari di errore e implementare i passaggi per ripristinare il database. L'esecuzione pianificata dell'interruzione può aiutare a prepararsi, diagnosticare e recuperare da quella successiva. Per mitigare l'impatto dei tempi di inattività, le organizzazioni hanno bisogno di un piano di ripristino appropriato, che includa tutti i fattori necessari per dare vita al servizio.

La gestione del backup non è così delicata come la semplice pianificazione di un processo di backup. Ci sono molti fattori da considerare, come conservazione, archiviazione, verifica e se i backup che stai eseguendo sono fisici o logici e cosa è facile trascurare la sicurezza.

Molte organizzazioni variano il loro approccio ai backup, cercando di avere una combinazione di backup di immagini del server (istantanee), backup logici e fisici archiviati in più posizioni. Serve per evitare qualsiasi disastro locale o regionale che cancellerebbe i nostri database e backup archiviati nello stesso data center.

Vogliamo renderlo sicuro. I dati e i backup devono essere crittografati. Ma ci sono molte implicazioni quando entrambe le opzioni sono in atto. In questo articolo, daremo un'occhiata alle procedure di backup quando ci occupiamo di database crittografati.

Crittografia a riposo per Percona Server per MySQL 8.0

A partire da MySQL 5.7.11, la versione community di MySQL ha iniziato a supportare la crittografia del tablespace InnoDB. Si chiama Transparent Tablespace Encryption o ci si riferisce come Encryption-at-Rest.

La differenza principale rispetto alla versione enterprise è il modo in cui le chiavi sono archiviate:le chiavi non si trovano in un deposito sicuro, necessario per la conformità normativa. Lo stesso vale per Percona Server, a partire dalla versione 5.7.11, è possibile crittografare il tablespace InnoDB. In Percona Server 8.0, il supporto per la crittografia dei log binari è stato notevolmente esteso. Aggiunta la versione 8.0 

(Documento di rilascio per Percona 8.0):

  • Crittografia file temporanei
  • InnoDB Annulla crittografia tablespace
  • Crittografia tablespace di sistema InnoDB (crittografia tablespace di sistema InnoDB)
  • default_table_encryption  =OFF/ON (crittografia generale tablespace)
  • table_encryption_privilege_check =OFF/ON (verifica delle impostazioni di crittografia)
  • Crittografia redo log di InnoDB (solo per crittografia con chiave master) (Redo Log Encryption)
  • Crittografia dei file di unione InnoDB (verifica delle impostazioni di crittografia)
  • Crittografia buffer Percona Parallel doublewrite (InnoDB Tablespace Encryption)

Per chi è interessato alla migrazione dalla versione MySQL Enterprise a Percona - È anche possibile integrarsi con il server Hashicorp Vault tramite un plug-in keyring_vault, corrispondente alle funzionalità disponibili nell'edizione MySQL Enterprise di Oracle.

La crittografia dei dati inattivi richiede un plug-in portachiavi. Ci sono due opzioni qui:

  • keyring_file - un file flat con una chiave di crittografia
  • Plugin Keyring Vault :un servizio

Come abilitare la crittografia tablespace

Per abilitare la crittografia avvia il tuo database con l'opzione --early-plugin-load:

sia a mano:

$ mysqld --early-plugin-load="keyring_file=keyring_file.so"

o modificando il file di configurazione:

[mysqld]

early-plugin-load=keyring_file.so

Avviando Percona Server 8.0 è possibile crittografare due tipi di tablespace. Tablespace generale e tablespace di sistema. Il tablespace Sys è controllato tramite il parametro innodb_sys_tablespace_encrypt. Per impostazione predefinita, il tablespace sys non è crittografato e, se ne hai già uno, non è possibile convertirlo in stato crittografato, è necessario creare una nuova istanza (avviare un'istanza con l'opzione --bootstrap).

Il tablespace generale supporta la crittografia di tutte le tabelle nel tablespace o di nessuna. Non è possibile eseguire la crittografia in modalità mista. Per creare un tablespace ate con la crittografia, utilizzare il flag ENCRYPTION='S/N'.

Esempio:

mysql> CREATE TABLESPACE severalnines ADD DATAFILE 'severalnines.ibd' ENCRYPTION='Y';

Backup di un database crittografato

Quando aggiungi tablespace crittografati è necessario includere il file keyring nel comando xtrabackup. Per farlo devi specificare il percorso di un file di portachiavi come valore dell'opzione --keyring-file-data.

$ xtrabackup --backup --target-dir=/u01/mysql/data/backup/ --user=root --keyring-file-data=/u01/secure_location/keyring_file

Assicurati di archiviare il file del portachiavi in ​​un luogo sicuro. Inoltre, assicurati di avere sempre un backup del file. Xtrabackup non copierà il file del portachiavi nella directory di backup. Per preparare il backup, devi creare tu stesso una copia del file del portachiavi.

Preparazione del backup

Una volta che abbiamo il nostro file di backup, dovremmo prepararlo per il ripristino. Qui devi anche specificare i dati del file del portachiavi.

$ xtrabackup --prepare --target-dir=/u01/mysql/data/backup/ --keyring-file-data=/u01/secure_location/keyring_file

Il backup è ora preparato e può essere ripristinato con l'opzione --copy-back. Nel caso in cui il portachiavi sia stato ruotato, dovrai ripristinare il portachiavi (che è stato utilizzato per prendere e preparare il backup).

Per preparare il backup xtrabackup, avremo bisogno dell'accesso al portachiavi. Xtrabackup non parla direttamente al server MySQL e non legge il file di configurazione my.cnf predefinito durante la preparazione, specifica le impostazioni del portachiavi tramite la riga di comando:

$ xtrabackup --prepare --target-dir=/data/backup --keyring-vault-config=/etc/vault.cnf

Il backup è ora preparato e può essere ripristinato con l'opzione --copy-back:

$ xtrabackup --copy-back --target-dir=/u01/backup/ --datadir=/u01/mysql/data/

Esecuzione di backup incrementali

Il processo di acquisizione di backup incrementali con la crittografia del tablespace InnoDB è simile all'esecuzione degli stessi backup incrementali con un tablespace non crittografato.

Per eseguire un backup incrementale, inizia con un backup completo. Il binario xtrabackup scrive un file chiamato xtrabackup_checkpoints nella directory di destinazione del backup. Questo file contiene una riga che mostra to_lsn, che è l'LSN del database alla fine del backup.

Per prima cosa, devi creare un backup completo con il seguente comando:

$ xtrabackup --backup --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

Ora che hai un backup completo, puoi fare un backup incrementale basato su di esso. Utilizzare un comando come il seguente:

$ xtrabackup --backup --target-dir=/data/backups/inc1 \

--incremental-basedir=/data/backups/base \

--keyring-file-data=/var/lib/mysql-keyring/keyring

La directory /data/backups/inc1/ ora dovrebbe contenere file delta, come ibdata1.delta e test/table1.ibd.delta.

Il significato dovrebbe essere evidente. È ora possibile utilizzare questa directory come base per un altro backup incrementale:

$ xtrabackup --backup --target-dir=/data/backups/inc2 \

--incremental-basedir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Preparazione di backup incrementali

Finora il processo di backup del database è simile a un backup normale, ad eccezione del flag in cui è stata specificata la posizione del file keyring.

Purtroppo, il passaggio --prepare per i backup incrementali non è lo stesso dei backup normali.

Nei backup normali, vengono eseguiti due tipi di operazioni per rendere coerente il database:le transazioni salvate vengono riprodotte dal file di registro rispetto ai file di dati e viene eseguito il rollback delle transazioni non vincolate. È necessario ignorare il rollback delle transazioni non vincolate durante la preparazione di un backup, poiché le transazioni non vincolate al momento del backup potrebbero essere in corso ed è probabile che verranno salvate nel successivo backup incrementale. Dovresti usare l'opzione --apply-log-only per evitare la fase di rollback.

Se non utilizzi l'opzione --apply-log-only per impedire la fase di rollback, i tuoi backup incrementali saranno inutili. Dopo il rollback delle transazioni, non è possibile applicare ulteriori backup incrementali.

A partire dal backup completo che hai creato, puoi prepararlo e quindi applicarvi le differenze incrementali. Ricorda che hai i seguenti backup:

/data/backups/base

/data/backups/inc1

/data/backups/inc2

Per preparare il backup di base, è necessario eseguire --prepare come al solito, ma evitare la fase di rollback:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

Per applicare il primo backup incrementale al backup completo, dovresti usare il seguente comando:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

se il portachiavi è stato ruotato tra il backup di base e quello incrementale, dovrai utilizzare il portachiavi che era in uso quando è stato eseguito il primo backup incrementale.

La preparazione del secondo backup incrementale è un processo simile

$ xtrabackup --prepare --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc2 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Nota; --apply-log-only dovrebbe essere usato quando si uniscono tutti gli incrementali tranne l'ultimo. Ecco perché la riga precedente non contiene l'opzione --apply-log-only. Anche se --apply-log-only fosse stato utilizzato nell'ultimo passaggio, il backup sarebbe comunque coerente ma in tal caso il server eseguirebbe la fase di rollback.
L'ultimo passaggio consiste nel ripristinarlo con --copy-back opzione. Nel caso in cui il portachiavi sia stato ruotato, dovrai ripristinare il portachiavi che è stato utilizzato per prendere e preparare il backup.

Sebbene il metodo di ripristino descritto funzioni, richiede l'accesso allo stesso portachiavi utilizzato dal server. Potrebbe non essere possibile se il backup viene preparato su un server diverso o in un momento molto successivo, quando le chiavi nel portachiavi vengono eliminate o, in caso di malfunzionamento, quando il server del vault del portachiavi non è affatto disponibile.

L'opzione --transition-key= dovrebbe essere utilizzata per consentire a xtrabackup di elaborare il backup senza accedere al server del deposito di chiavi. In questo caso, xtrabackup ricava la chiave di crittografia AES dalla passphrase specificata e la utilizzerà per crittografare le chiavi del tablespace dei tablespace di cui viene eseguito il backup.

Creazione di un backup con una passphrase

L'esempio seguente illustra come creare il backup in questo caso:

$ xtrabackup --backup --user=root -p --target-dir=/data/backup \

--transition-key=MySecetKey

Ripristino del backup con una chiave generata

Quando si ripristina un backup sarà necessario generare una nuova chiave principale. Ecco l'esempio per keyring_file:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-file-data=/var/lib/mysql-keyring/keyring

In caso di keyring_vault, apparirà così:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-vault-config=/etc/vault.cnf