Opções de backup em nuvem para bancos de dados MySQL e MariaDB

O principal objetivo do backup de seus dados é, obviamente, a capacidade de reverter e acessar seus arquivos em caso de falha de hardware. Para fazer negócios hoje, você precisa da certeza de saber que, em caso de desastre, seus dados estarão protegidos e acessíveis. Você precisaria armazenar seus backups fora do local, caso seu datacenter seja destruído.

A proteção de dados continua a ser um desafio para as pequenas e médias empresas. Empresas de pequeno a médio porte preferem arquivar os dados de sua empresa usando armazenamento de conexão direta, com a maioria das empresas planejando fazer cópias de backup fora do local. A abordagem de armazenamento local pode levar a um dos dilemas mais graves que a empresa moderna pode enfrentar - perda de dados em caso de desastre.

Muitos fatores entram em deliberação ao julgar se deve permitir que um banco de dados crítico de negócios seja transferido para fora do local e ao escolher um fornecedor adequado para fazê-lo. Os métodos tradicionais, como gravar em fita e enviar para um local remoto, podem ser um processo complicado que requer hardware especial, equipe adequadamente treinada e procedimentos para garantir que os backups sejam produzidos, protegidos regularmente e que as informações neles contidas sejam verificadas quanto à integridade. As pequenas empresas geralmente têm pequenos orçamentos de TI. Muitas vezes, eles não podem se dar ao luxo de ter um datacenter secundário, mesmo que tenham um datacenter dedicado. Mas, no entanto, ainda é importante manter uma cópia de seus arquivos de backup fora do local. Desastres como furacão, inundação, incêndio ou roubo podem destruir seus servidores e armazenamento. Manter os dados de backup no datacenter separado garante que os dados estejam seguros, não importa o que esteja acontecendo em seu datacenter principal. O armazenamento em nuvem é uma ótima maneira de resolver esse problema.
Com a abordagem de backup em nuvem, há vários fatores a serem considerados. Algumas das perguntas que você tem são:

Os dados de backup estão protegidos em repouso no data center externo?
A transferência de ou para o data center externo por meio da rede pública de Internet é segura?
Existe um efeito no RTO (objetivo de tempo de recuperação)?
O processo de backup e recuperação é fácil o suficiente para nossa equipe de TI?
Há alguma alteração necessária nos processos existentes?
As ferramentas de backup de terceiros são necessárias?
Quais são os custos adicionais em termos de software necessário ou transferência de dados?
Quais são os custos de armazenamento?

Recursos de backup ao fazer backup na nuvem

Se o seu servidor MySQL ou destino de backup estiver localizado em uma infraestrutura exposta como uma nuvem pública, provedor de hospedagem ou conectado por meio de uma rede WAN não confiável, você precisa pensar em ações adicionais em sua política de backup. Existem algumas maneiras diferentes de realizar backups de banco de dados para MySQL e, dependendo do tipo de backup, o tempo de recuperação, o tamanho e as opções de infraestrutura variam. Como muitas das soluções de armazenamento em nuvem são simplesmente armazenamento com diferentes front-ends de API, qualquer solução de backup pode ser executada com um pouco de script. Então, quais são as opções que temos para tornar o processo tranquilo e seguro?

Criptografia

É sempre uma boa ideia aplicar a criptografia para aumentar a segurança dos dados de backup. Um caso de uso simples para implementar a criptografia é quando você deseja enviar o backup para um armazenamento de backup externo localizado na nuvem pública.

Ao criar um backup criptografado, uma coisa a ter em mente é que geralmente leva mais tempo para recuperar. O backup deve ser descriptografado antes de qualquer atividade de recuperação. Com um grande conjunto de dados, isso pode introduzir alguns atrasos no RTO.

Por outro lado, se você estiver usando a chave privada para criptografia, certifique-se de armazenar a chave em um local seguro. Se a chave privada estiver ausente, o backup será inútil e irrecuperável. Se a chave for roubada, todos os backups criados que usam a mesma chave serão comprometidos, pois não são mais seguros. Você pode usar o popular GnuPG ou OpenSSL para gerar as chaves privadas ou públicas.
Para executar a criptografia mysqldump usando o GnuPG, gere uma chave privada e siga o assistente de acordo:

$ gpg --gen-key

Crie um backup mysqldump simples como de costume:

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

Criptografe o arquivo de despejo e remova o backup simples mais antigo:

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

O GnuPG anexará automaticamente a extensão .gpg no arquivo criptografado. Para descriptografar,
simplesmente execute o comando gpg com o sinalizador --decrypt:

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

Para criar um mysqldump criptografado usando OpenSSL, é preciso gerar uma chave privada e uma chave pública:
OpenSSL req -x509 -nodes -newkey rsa:2048 -keyout dump.priv.pem -out dump.pub.pem

Esta chave privada (dump.priv.pem) deve ser mantida em um local seguro para futura descriptografia. Para mysqldump, um backup criptografado pode ser criado canalizando o conteúdo para openssl, por exemplo

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

Para descriptografar, basta usar a chave privada (dump.priv.pem) junto com o sinalizador -decrypt:
openssl smime -decrypt -in database.sql.enc -binary -inform

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

O Percona XtraBackup pode ser usado para criptografar ou descriptografar backups locais ou de streaming com a opção xbstream para adicionar outra camada de proteção aos backups. A criptografia é feita com a biblioteca libgcrypt. Tanto a opção --encrypt-key quanto a opção --encryptkey-file podem ser usadas para especificar a chave de criptografia. As chaves de criptografia podem ser geradas com comandos como

$ openssl rand -base64 24
$ bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1

Esse valor pode ser usado como a chave de criptografia. Exemplo do comando innobackupex usando a --encrypt-key:

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

A saída do comando OpenSSL acima também pode ser redirecionada para um arquivo e pode ser tratada como um arquivo de chave:

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

Use-o com a opção --encrypt-key-file:

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

Para descriptografar, basta usar a opção --decrypt com --encrypt-key ou --encrypt-key-file apropriado:

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

Para obter mais informações sobre a criptografia MySQL e MariaDB, consulte nossa outra postagem no blog.

Compressão

No mundo do backup em nuvem de banco de dados, a compactação é uma de suas melhores amigas. Ele pode não apenas economizar espaço de armazenamento, mas também reduzir significativamente o tempo necessário para fazer download/upload de dados.
Existem muitas ferramentas de compactação disponíveis, como gzip, bzip2, zip, rar e 7z.
Normalmente, o mysqldump pode ter melhores taxas de compactação, pois é um arquivo de texto simples. Dependendo da ferramenta de compactação e da proporção, um mysqldump compactado pode ser até 6 vezes menor que o tamanho do backup original. Para compactar o backup, você pode canalizar a saída do mysqldump para uma ferramenta de compactação e redirecioná-la para um arquivo de destino. Você também pode pular várias coisas como comentários, declaração de tabelas de bloqueio (se InnoDB), pular GTID purgado e acionadores:

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

Com o Percona Xtrabackup, você pode usar o modo streaming (innobackupex), que envia o backup para o STDOUT em formato especial tar ou xbstream em vez de copiar os arquivos para o diretório de backup. Ter um backup compactado pode economizar até 50% do tamanho do backup original, dependendo do conjunto de dados. Acrescente a opção --compress no comando backup. Ao usar o xbstream em backups de streaming, você pode acelerar o processo de compactação usando a opção --compress-threads. Esta opção especifica o número de encadeamentos criados pelo xtrabackup para compactação de dados paralela. O valor padrão para essa opção é 1. Para usar esse recurso, adicione a opção a um backup local. Um exemplo de backup com compactação:

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

Antes de aplicar os logs durante o estágio de preparação, os arquivos compactados precisarão ser
descompactados usando xbstream:
Em seguida, use qpress para extrair cada arquivo que termina com .qp em seu respectivo diretório
antes de executar -- comando apply-log para preparar os dados do MySQL.

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

Limitar a taxa de transferência da rede

Uma ótima opção para backups em nuvem é limitar a largura de banda de streaming de rede (Mb/s) ao fazer um backup. Você pode conseguir isso com a ferramenta pv. O utilitário pv vem com a opção de modificadores de dados -L RATE, --rate-limit RATE que limita a transferência a um máximo de RATE bytes por segundo. O exemplo abaixo irá restringi-lo a 2 MB/s.

$ pv -q -L 2m

No exemplo abaixo, você pode ver o xtrabackup com gzip paralelo, criptografia

 /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.

Transferir backup para a nuvem

Agora, quando seu backup estiver compactado e criptografado, ele estará pronto para transferência.

Google nuvem

A ferramenta de linha de comando gsutil é usada para gerenciar, monitorar e usar seus intervalos de armazenamento no Google Cloud Storage. Se você já instalou o gcloud util, já tem o gsutil instalado. Caso contrário, siga as instruções para sua distribuição Linux aqui.

Para instalar a CLI do gcloud, você pode seguir o procedimento abaixo:

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

Reinicie seu shell:

exec -l $SHELL

Execute gcloud init para inicializar o ambiente gcloud:

gcloud init

Com a ferramenta de linha de comando gsutil instalada e autenticada, crie um bucket de armazenamento regional chamado mysql-backups-storage em seu projeto atual.

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

Amazon S3

Se você não estiver usando o RDS para hospedar seus bancos de dados, é muito provável que esteja fazendo seus próprios backups. A plataforma AWS da Amazon, S3 (Amazon Simple Storage Service) é um serviço de armazenamento de dados que pode ser usado para armazenar backups de banco de dados ou outros arquivos críticos para os negócios. Seja na instância do Amazon EC2 ou no seu ambiente local, você pode usar o serviço para proteger seus dados.

Embora os backups possam ser carregados por meio da interface da Web, a interface de linha de comando s3 dedicada pode ser usada para fazer isso a partir da linha de comando e por meio de scripts de automação de backup. Se os backups forem mantidos por muito tempo e o tempo de recuperação não for uma preocupação, os backups podem ser transferidos para o serviço Amazon Glacier, fornecendo armazenamento de longo prazo muito mais barato. Os arquivos (objetos da Amazon) são armazenados logicamente em um enorme contêiner plano chamado bucket. O S3 apresenta uma interface REST para seus internos. Você pode usar essa API para realizar operações CRUD em buckets e objetos, bem como alterar permissões e configurações em ambos.

O principal método de distribuição da AWS CLI no Linux, Windows e macOS é pip, um gerenciador de pacotes para Python. A instrução pode ser encontrada aqui.

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

Por padrão, o S3 fornece durabilidade de objeto de onze 9s. Isso significa que se você armazenar 1.000.000.000 (1 bilhão) de objetos nele, você pode esperar perder 1 objeto a cada 10 anos em média. A maneira como o S3 atinge esse número impressionante de 9s é replicando o objeto automaticamente em várias zonas de disponibilidade, sobre as quais falaremos em outro post. A Amazon possui datacenters regionais em todo o mundo.

Armazenamento do Microsoft Azure

A plataforma de nuvem pública da Microsoft, Azure, tem opções de armazenamento com sua interface de linha de controle. Informações podem ser encontradas aqui. A CLI do Azure de plataforma cruzada de código aberto fornece um conjunto de comandos para trabalhar com a plataforma do Azure. Ele oferece grande parte da funcionalidade vista no portal do Azure, incluindo acesso avançado a dados.

A instalação da CLI do Azure é bastante simples, você pode encontrar instruções aqui. Abaixo, você pode encontrar como transferir seu backup para o armazenamento da Microsoft.

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

Armazenamento híbrido para backups MySQL e MariaDB

Com a crescente indústria de armazenamento em nuvem pública e privada, temos uma nova categoria chamada armazenamento híbrido. Essa tecnologia permite que os arquivos sejam armazenados localmente, com as alterações sincronizadas automaticamente ao remoto na nuvem. Essa abordagem vem da necessidade de ter backups recentes armazenados localmente para restauração rápida (RTO menor), bem como objetivos de continuidade de negócios.
O aspecto importante do uso eficiente de recursos é ter retenções de backup separadas. Os dados armazenados localmente em unidades de disco redundantes seriam mantidos por um período mais curto, enquanto o armazenamento de backup em nuvem seria mantido por mais tempo. Muitas vezes, o requisito de retenção de backup mais longa vem de obrigações legais para diferentes setores (como telecomunicações que precisam armazenar metadados de conexão). Provedores de nuvem como Google Cloud Services, Microsoft Azure e Amazon S3 oferecem armazenamento praticamente ilimitado, diminuindo as necessidades de espaço local. Ele permite que você retenha seus arquivos de backup por mais tempo, pelo tempo que desejar e não tenha preocupações com o espaço em disco local.

Gerenciamento de backup do ClusterControl - armazenamento híbrido
Ao agendar o backup com o ClusterControl, cada um dos métodos de backup é configurável com um conjunto de opções sobre como você deseja que o backup seja executado. O mais importante para o armazenamento em nuvem híbrida seria:

Limitação de rede
Criptografia com o gerenciamento de chaves integrado
Compressão
Período de retenção para os backups locais
Período de retenção para os backups na nuvem

Retenção de backup duplo do ClusterControl

Recursos avançados de backup do ClusterControl para nuvem, compactação paralela, limite de banda de rede, criptografia etc ...

Conclusão

A nuvem mudou a indústria de backup de dados. Devido ao seu preço acessível, as empresas menores têm uma solução externa que faz backup de todos os seus dados.

Sua empresa pode aproveitar a escalabilidade da nuvem e os preços pagos conforme o uso para necessidades crescentes de armazenamento. Você pode criar uma estratégia de backup para fornecer cópias locais no datacenter para restauração imediata e um gateway perfeito para serviços de armazenamento em nuvem da AWS, Google e Azure.

Os recursos avançados de criptografia e compactação TLS e AES de 256 bits oferecem suporte a backups seguros que ocupam significativamente menos espaço na nuvem.