Como fazer backup de um banco de dados criptografado com o Percona Server para MySQL 8.0

As interrupções de produção são quase garantidas em algum momento. Sabemos disso, por isso planejamos backups, criamos bancos de dados de espera de recuperação, convertemos instâncias únicas em clusters.

Admitindo a necessidade de um cenário de recuperação adequado, devemos analisar o possível cronograma de desastres e cenários de falha e implementar etapas para ativar seu banco de dados. A execução de interrupção planejada pode ajudar a preparar, diagnosticar e recuperar-se da próxima. Para mitigar o impacto do tempo de inatividade, as organizações precisam de um plano de recuperação adequado, que inclua todos os fatores necessários para dar vida ao serviço.

O gerenciamento de backup não é tão suave quanto apenas agendar um trabalho de backup. Há muitos fatores a serem considerados, como retenção, armazenamento, verificação e se os backups que você está fazendo são físicos ou lógicos e o que é fácil ignorar a segurança.

Muitas organizações variam sua abordagem de backups, tentando ter uma combinação de backups de imagem de servidor (snapshots), backups lógicos e físicos armazenados em vários locais. É para evitar quaisquer desastres locais ou regionais que apaguem nossos bancos de dados e backups armazenados no mesmo data center.

Queremos torná-lo seguro. Dados e backups devem ser criptografados. Mas há muitas implicações quando ambas as opções estão em vigor. Neste artigo, veremos os procedimentos de backup quando lidamos com bancos de dados criptografados.

Criptografia em repouso para servidor Percona para MySQL 8.0

A partir do MySQL 5.7.11, a versão da comunidade do MySQL começou a oferecer suporte para criptografia de tablespace InnoDB. É chamado de Criptografia de Tablespace Transparente ou conhecido como Criptografia em Repouso.

A principal diferença em relação à versão corporativa é a forma como as chaves são armazenadas - as chaves não estão localizadas em um cofre seguro, o que é necessário para conformidade regulatória. O mesmo se aplica ao Percona Server, a partir da versão 5.7.11, é possível criptografar o tablespace InnoDB. No Percona Server 8.0, o suporte para criptografia de logs binários foi bastante estendido. Versão 8.0 adicionada

(De acordo com o documento de versão do Percona 8.0):

• Criptografia de arquivo temporário
• InnoDB Undo Tablespace Encryption
• Criptografia de espaço de tabela do sistema InnoDB (criptografia de espaço de tabela do sistema InnoDB)
• default_table_encryption  =OFF/ON (criptografia geral de tablespace)
• table_encryption_privilege_check =OFF/ON (verificação das configurações de criptografia)
• Criptografia de redo log do InnoDB (somente para criptografia de chave mestra) (Criptografia de redo log)
• Criptografia de arquivo de mesclagem InnoDB (verificando a configuração de criptografia)
• Criptografia de buffer de gravação dupla paralela Percona (Criptografia de espaço de tabela InnoDB)

Para os interessados ​​na migração da versão MySQL Enterprise para Percona -  Também é possível integrar com o servidor Hashicorp Vault por meio de um plugin keyring_vault, combinando com os recursos disponíveis na edição MySQL Enterprise da Oracle.

A criptografia de dados em repouso requer um plug-in de chaveiro. Há duas opções aqui:

• keyring_file - um arquivo simples com uma chave de criptografia
• Plugin do Keyring Vault  - um serviço

Como habilitar a criptografia de tablespace

Para habilitar a criptografia, inicie seu banco de dados com a opção --early-plugin-load:

quer à mão:

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

ou modificando o arquivo de configuração:

[mysqld]

early-plugin-load=keyring_file.so

Ao iniciar o Percona Server 8.0, dois tipos de tablespaces podem ser criptografados. Espaço de tabela geral e espaço de tabela do sistema. O tablespace Sys é controlado por meio do parâmetro innodb_sys_tablespace_encrypt. Por padrão, o tablespace sys não é criptografado e, se você já tiver um, não é possível convertê-lo para o estado criptografado, uma nova instância deve ser criada (inicie uma instância com a opção --bootstrap).

O tablespace geral suporta criptografia de todas as tabelas no tablespace ou nenhuma. Não é possível executar a criptografia no modo misto. Para criar um tablespace com criptografia, use o sinalizador ENCRYPTION='Y/N'.

Exemplo:

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

Fazendo backup de um banco de dados criptografado

Ao adicionar tablespaces criptografados é necessário incluir o arquivo keyring no comando xtrabackup. Para fazer isso, você deve especificar o caminho para um arquivo de chaveiro como o valor da opção --keyring-file-data.

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

Certifique-se de armazenar o arquivo do chaveiro em um local seguro. Além disso, certifique-se de sempre ter um backup do arquivo. O Xtrabackup não copiará o arquivo de chaveiro no diretório de backup. Para preparar o backup, você mesmo precisa fazer uma cópia do arquivo do chaveiro.

Preparando o backup

Uma vez que tenhamos nosso arquivo de backup, devemos prepará-lo para a recuperação. Aqui você também precisa especificar o arquivo keyring-data.

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

O backup agora está preparado e pode ser restaurado com a opção --copy-back. Caso o chaveiro tenha sido girado, você precisará restaurar o chaveiro (que foi usado para fazer e preparar o backup).

Para preparar o backup xtrabackup, precisaremos acessar o chaveiro. O Xtrabackup não fala diretamente com o servidor MySQL e não lê o arquivo de configuração padrão my.cnf durante a preparação, especifique as configurações do keyring através da linha de comando:

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

O backup agora está preparado e pode ser restaurado com a opção --copy-back:

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

Executando backups incrementais

O processo de fazer backups incrementais com a criptografia de tablespace InnoDB é semelhante a fazer os mesmos backups incrementais com um tablespace não criptografado.

Para fazer um backup incremental, comece com um backup completo. O binário xtrabackup grava um arquivo chamado xtrabackup_checkpoints no diretório de destino do backup. Este arquivo contém uma linha mostrando o to_lsn, que é o LSN do banco de dados ao final do backup.

Primeiro, você precisa criar um backup completo com o seguinte comando:

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

Agora que você tem um backup completo, pode fazer um backup incremental com base nele. Use um comando como o seguinte:

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

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

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

O diretório /data/backups/inc1/ agora deve conter arquivos delta, como ibdata1.delta e test/table1.ibd.delta.

O significado deve ser evidente. Agora é possível usar este diretório como base para mais um backup incremental:

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

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

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

Preparando backups incrementais

Até agora, o processo de backup do banco de dados é semelhante a um backup regular, exceto pelo sinalizador em que especificamos a localização do arquivo do chaveiro.

Infelizmente, a etapa --prepare para backups incrementais não é a mesma para backups normais.

Nos backups normais, dois tipos de operações são executados para tornar o banco de dados consistente:as transações confirmadas são reproduzidas do arquivo de log em relação aos arquivos de dados e as transações não confirmadas são revertidas. Você deve ignorar a reversão de transações não confirmadas ao preparar um backup, porque as transações que não foram confirmadas no momento do backup podem estar em andamento e é provável que sejam confirmadas no próximo backup incremental. Você deve usar a opção --apply-log-only para evitar a fase de reversão.

Se você não usar a opção --apply-log-only para evitar a fase de reversão, seus backups incrementais serão inúteis. Depois que as transações forem revertidas, backups incrementais adicionais não poderão ser aplicados.

Começando com o backup completo que você criou, você pode prepará-lo e depois aplicar as diferenças incrementais a ele. Lembre-se de que você tem os seguintes backups:

/data/backups/base

/data/backups/inc1

/data/backups/inc2

Para preparar o backup básico, você precisa executar --prepare como de costume, mas evitar a fase de rollback:

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

Para aplicar o primeiro backup incremental ao backup completo, você deve usar o seguinte 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 o chaveiro foi alternado entre o backup básico e o incremental, você precisará usar o chaveiro que estava em uso quando o primeiro backup incremental foi feito.

Preparar o segundo backup incremental é um processo semelhante

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

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

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

Observação; --apply-log-only deve ser usado ao mesclar todos os incrementais, exceto o último. É por isso que a linha anterior não contém a opção --apply-log-only. Mesmo que o --apply-log-only fosse usado na última etapa, o backup ainda seria consistente, mas nesse caso o servidor executaria a fase de reversão.
A última etapa é restaurá-lo com --copy-back opção. Caso o chaveiro tenha sido girado, você precisará restaurar o chaveiro que foi usado para fazer e preparar o backup.

Embora o método de restauração descrito funcione, ele requer acesso ao mesmo chaveiro que o servidor está usando. Pode não ser possível se o backup for preparado em um servidor diferente ou em um momento muito posterior, quando as chaves do chaveiro forem removidas ou, em caso de mau funcionamento, quando o servidor do cofre do chaveiro não estiver disponível.

A opção --transition-key= deve ser usada para possibilitar ao xtrabackup processar o backup sem acesso ao servidor do cofre do chaveiro. Nesse caso, o xtrabackup deriva a chave de criptografia AES da frase secreta especificada e a usará para criptografar as chaves de tablespace dos tablespaces cujo backup está sendo feito.

Criando um backup com uma senha

O exemplo a seguir ilustra como o backup pode ser criado neste caso:

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

--transition-key=MySecetKey

Restaurando o backup com uma chave gerada

Ao restaurar um backup, você precisará gerar uma nova chave mestra. Aqui está o exemplo para 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

No caso de keyring_vault, ficará assim:

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

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

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