- Ah, nenhum abrigo pode resistir ao impacto de um meteorito. Mas você, como todo mundo, tem uma reserva, então não precisa se preocupar.
Stanislav Lem, “Diários Estelares de Ijon, o Silencioso”
Backup refere-se a salvar uma cópia dos dados em algum lugar fora de seu local de armazenamento principal.
O principal objetivo do backup é restaurar dados após sua perda. Nesse sentido, você costuma ouvir que, se tiver uma réplica de banco de dados, poderá sempre restaurar os dados dela e não há necessidade de backup. Na verdade, o backup permite resolver pelo menos três problemas que não podem ser resolvidos com uma réplica, e uma réplica não pode ser inicializada sem uma cópia de backup.
Primeiro, um backup permite recuperar dados após um erro lógico. Por exemplo, um contador excluiu um grupo de transações ou um administrador de banco de dados destruiu um espaço de tabela. Ambas as operações são totalmente legais do ponto de vista do banco de dados e o processo de replicação irá reproduzi-las no banco de dados réplica.
Em segundo lugar, os SGBDs modernos são sistemas de software muito confiáveis, mas ocasionalmente ocorrem danos às estruturas internas do banco de dados, após os quais o acesso aos dados é perdido. O que é especialmente ofensivo é que tal violação geralmente ocorre sob carga elevada ou durante a instalação de algum tipo de atualização. Mas tanto a alta carga quanto as atualizações regulares indicam que o banco de dados não é de forma alguma um banco de dados de teste e que os dados armazenados nele são valiosos.
Finalmente, a terceira tarefa, cuja solução requer uma cópia de segurança, é a clonagem de bases de dados, por exemplo, para fins de teste.
O backup do banco de dados é, de uma forma ou de outra, baseado em um de dois princípios:
- Amostragem de dados e posterior salvamento em formato personalizado;
- Instantâneo de arquivos de banco de dados e salvamento de logs.
Vamos examinar mais de perto esses princípios e as ferramentas que os implementam.
Fazendo upload de dados
O conjunto de utilitários incluídos em qualquer SGBD deve incluir ferramentas para upload e carregamento de dados. Os dados são armazenados em formato de texto ou em formato binário específico para um determinado SGBD. A tabela abaixo fornece uma lista dessas ferramentas:
Formato binário
Formato de texto
Oracle
Exportação/Importação de DataPump
Import / Export
SQL*Plus/SQL*Loader
PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql
Microsoft SQL Server
bcp
bcp
DB2
descarregar/carregar
descarregar/carregar
MySQL
mysqldump, mysqlpump/mysql, mysqlimport
MongoDB
mongodump/mongorestore
mongoexportação/mongoimportação
Cassandra
instantâneo do nodetool/stableloader
cqlsh
O bom do formato texto é que ele pode ser editado ou até mesmo criado por programas externos, e o formato binário, por sua vez, é bom porque permite fazer upload e download de dados mais rapidamente, economizando recursos na conversão de formatos.
Apesar da simplicidade e obviedade da ideia de download de dados, esse método raramente é usado para fazer backup de bancos de dados industriais carregados. Aqui estão os motivos pelos quais o descarregamento não é adequado para um backup completo:
- o processo de descarregamento cria uma carga significativa no sistema de origem;
- o descarregamento leva muito tempo - quando o descarregamento for concluído, ele não será mais relevante;
- É quase impossível realizar um descarregamento coordenado de todo o banco de dados sob alta carga, pois o SGBD é forçado a armazenar um instantâneo de seu estado no momento em que o descarregamento começa. Quanto mais transações forem concluídas desde o início do upload, maior será o tamanho do snapshot (cópias irrelevantes de dados no PostgreSQL, espaço para desfazer no Oracle, tempdb no Microsoft SQL Server, etc.);
- o descarregamento preserva a estrutura lógica dos dados, mas não preserva sua estrutura física - parâmetros de armazenamento físico de tabelas, índices, etc.
No entanto, o upload também tem suas vantagens:
- alta seletividade: você pode baixar tabelas individuais, campos individuais e até linhas individuais;
- os dados baixados podem ser carregados em um banco de dados de outra versão e, se o download for feito em formato de texto, em outro banco de dados.
Assim, o upload é usado principalmente para tarefas como backup de pequenas tabelas (por exemplo, diretórios) ou distribuição de conjuntos de dados com a próxima versão do aplicativo.
O método mais comum de backup de banco de dados é copiar arquivos de banco de dados.
Armazenamento frio de arquivos de banco de dados
A ideia óbvia é parar o banco de dados e copiar todos os seus arquivos. Este backup é chamado de backup “frio”. O método é extremamente confiável e simples, mas tem duas desvantagens óbvias:
- A partir de um backup “frio”, você só pode restaurar o estado do banco de dados que estava no momento do desligamento; as transações feitas após a reinicialização do banco de dados não serão incluídas na cópia de backup “fria”;
- Nem todo banco de dados possui uma janela tecnológica quando o banco de dados pode ser interrompido.
Se o backup “frio” for adequado para você, lembre-se de que
- A cópia fria às vezes deve incluir logs. Os métodos para determinar os logs que devem ir para a cópia “fria” são individuais para cada SGBD. Por exemplo, no Oracle é necessário copiar o chamado redo online, ou seja, um número fixo de arquivos de log em um diretório especial, mesmo quando o banco de dados está parado corretamente. No PostgreSQL, você deve salvar todos os logs começando pelo log que contém o último ponto de verificação, cujas informações estão contidas no arquivo de controle.
- O diretório do banco de dados pode conter arquivos de espaço de tabela temporários grandes o suficiente para que não precisem ser incluídos no backup. A propósito, esta observação também se aplica a backups dinâmicos.
Salvamento de arquivos a quente
A maioria dos backups de banco de dados modernos são executados copiando arquivos de banco de dados sem interromper o banco de dados. Existem vários problemas aqui:
- Ao iniciar a cópia, o conteúdo do banco de dados pode não coincidir com o conteúdo dos arquivos, pois algumas informações estão no cache e ainda não foram gravadas no disco.
- Durante a cópia, o conteúdo do banco de dados pode mudar. Se forem usadas estruturas de dados mutáveis, o conteúdo dos arquivos muda, e quando estruturas imutáveis são usadas, o conjunto de arquivos muda: novos arquivos aparecem e os antigos são excluídos.
- Como a gravação de dados no banco de dados e a leitura dos arquivos do banco de dados não são sincronizadas de forma alguma, o programa de backup pode ler uma página incorreta, na qual metade será da versão antiga da página e a outra metade da nova.
Para que o backup seja consistente, cada SGBD possui um comando que avisa que o processo de backup foi iniciado. Sintaticamente, este comando pode parecer diferente:
- no Oracle, este é um comando separado ALTER DATABASE/TABLESPACE BEGIN BACKUP;
- no PostgreSQL – função pg_start_backup();
- No Microsoft SQL Server e no DB2, a preparação para backup é executada implicitamente durante a execução do comando BACKUP DATABASE;
- no MySQL Enterprise, Cassandra e MongoDB, a preparação é realizada implicitamente por um utilitário externo - mysqlbackup, OpsCenter e Ops Manager, respectivamente.
Apesar das diferenças de sintaxe, o processo de preparação para um backup parece o mesmo.
Esta é a aparência da preparação para backup em um SGBD com estruturas de disco mutáveis, ou seja, em todos os sistemas relacionais de disco tradicionais:
- O momento em que o backup foi iniciado é lembrado; o backup precisará conter logs do banco de dados deste ponto em diante.
- É realizado um checkpoint, ou seja, todas as alterações ocorridas nas páginas de dados antes do momento lembrado são descarregadas para o disco. Isso garante que nenhum registro seja necessário antes do início do backup durante a recuperação.
- Um modo de registro especial é ativado: se uma página de dados for alterada pela primeira vez após ser carregada do disco, em vez de gravar as alterações da página no registro, o banco de dados gravará a página inteira lá. Ao realizar o procedimento de preparação, todas as páginas são descarregadas para o disco, portanto, na primeira vez que for feita uma alteração, o bloco inteiro sempre será gravado no log. Mas se a página for despejada novamente no disco durante o processo de backup, a próxima alteração também resultará em uma cópia completa da página aparecendo no log. Isso garante que, se a página estiver incorreta ao copiar um arquivo de dados, a aplicação de um log a corrigirá novamente.
- As alterações nos cabeçalhos dos arquivos de dados são bloqueadas, ou seja, aquela parte cujas alterações não são refletidas nos logs. Isso garante que o cabeçalho seja copiado corretamente e que os logs sejam aplicados corretamente ao arquivo de dados.
Após a conclusão de todos os procedimentos acima, você pode copiar arquivos de dados usando ferramentas do sistema operacional - cp, rsync e outros. A ativação do modo de backup reduz o desempenho do banco de dados: em primeiro lugar, o volume de logs aumenta e, em segundo lugar, se ocorrer uma falha repentina no modo de backup, a recuperação demorará mais porque os cabeçalhos dos arquivos de dados não são atualizados. Quanto mais rápido o backup for concluído, melhor para o banco de dados, por isso é apropriado usar ferramentas como instantâneo do sistema de arquivos ou quebra de espelho (BCV) na matriz de disco. Alguns SGBDs (Oracle, PostgreSQL) deixam ao administrador a oportunidade de escolher independentemente o método de cópia, outros (Microsoft SQL Server) fornecem uma interface para integrar seus próprios utilitários de backup com sistema de arquivos ou mecanismos de armazenamento.
Assim que o backup for concluído, você precisará retornar o banco de dados ao seu estado normal. No Oracle isso é feito com o comando ALTER DATABASE/TABLESPACE END BACKUP, no PostgreSQL chamando a função pg_stop_backup(), e nos demais bancos de dados por rotinas internas dos comandos correspondentes ou serviços externos.
Esta é a aparência do cronograma do processo de backup:
- A preparação para um backup leva tempo, às vezes um tempo considerável. Mesmo que sejam usados volumes espelhados ou sistemas de arquivos com capacidade de snapshot, o processo de backup não será instantâneo.
- Junto com os arquivos de dados, é necessário salvar os logs desde o momento em que você inicia a preparação para o backup até o momento em que o banco de dados retorna ao seu estado normal.
- Você pode restaurar a partir deste backup no momento em que a base retorna ao estado normal. Não é possível restaurar para um ponto anterior.
Com bancos de dados que usam estruturas de dados imutáveis (instantâneos de memória, árvores LSM), a situação é mais simples. A preparação para um backup consiste nas seguintes etapas:
- Os dados da memória são descarregados no disco.
- A lista de arquivos incluídos na cópia de backup é registrada. Até que o processo de backup seja concluído, o banco de dados está proibido de excluir esses arquivos, mesmo que eles não sejam mais necessários.
Ao sinalizar que o backup foi concluído, o banco de dados com estruturas imutáveis pode excluir novamente os arquivos desnecessários.
Recuperação para apontar
Uma cópia de backup permite restaurar o estado do banco de dados até o momento em que o comando de retorno do modo de backup foi concluído. Porém, um acidente que exija recuperação pode acontecer a qualquer momento. A tarefa de restaurar o estado de um banco de dados em um momento arbitrário é chamada de “recuperação point-in-time”.
Para garantir que isso seja possível, você deve salvar os logs do banco de dados a partir do final do backup e, durante o processo de recuperação, continuar a aplicar os logs à cópia restaurada. Depois que o banco de dados for restaurado a partir de uma cópia de backup no momento em que a cópia for concluída, é garantido que o estado do banco de dados (arquivos e páginas em cache) esteja correto, portanto, um modo de log especial não é necessário. Ao aplicar logs no momento certo, você pode obter o estado do banco de dados a qualquer momento.
Embora a velocidade na qual um backup pode ser restaurado seja limitada apenas pela largura de banda do disco, a velocidade na qual os logs podem ser aplicados geralmente é limitada pelo desempenho do processador. Se as alterações ocorrerem em paralelo no banco de dados principal, durante a recuperação, todas as alterações serão executadas sequencialmente - na ordem em que são lidas no log. Assim, o tempo de recuperação depende linearmente da distância entre o ponto de recuperação e o ponto final do backup. Por causa disso, é necessário fazer backups completos com bastante frequência - pelo menos uma vez por semana para bancos de dados com pequena carga de transações e até cópias diárias de bancos de dados altamente carregados.
Backup incremental
Para acelerar a recuperação até certo ponto, gostaria de poder realizar backups com a maior frequência possível, mas ao mesmo tempo não ocupar espaço extra em disco e não carregar o banco de dados com tarefas de backup.
A solução para o problema é o backup incremental, ou seja, copiar apenas as páginas de dados que foram alteradas desde o backup anterior.
Backups incrementais só fazem sentido para SGBDs que usam estruturas de dados mutáveis.
O incremento pode ser contado a partir de um backup completo (cópia cumulativa) ou de qualquer cópia anterior (cópia diferencial).
Infelizmente, não existe uma terminologia uniforme e diferentes fabricantes usam termos diferentes:
diferencial
Cumulativo
Oracle
Diferencial
Acumulativo
PostgreSQL
Incremental
-
Microsoft SQL Server
-
Diferencial
IBM DB2
Delta
Incremental
Se houver cópias incrementais, o processo de restauração até um ponto é o seguinte:
- o último backup completo feito antes da restauração ser restaurada;
- cópias incrementais são restauradas sobre a cópia completa;
- os logs são acumulados do ponto inicial do backup para o ponto de recuperação.
Ter uma cópia cumulativa acelera o processo de recuperação. Assim, por exemplo, para restaurar o estado do banco de dados para um ponto entre T3 e T4, é necessário restaurar duas cópias incrementais, e para restaurar para um ponto após T4, apenas uma.
Obviamente, o tamanho de uma cópia cumulativa é menor que o tamanho de várias cópias diferenciais, porque algumas páginas foram alteradas várias vezes e cada cópia incremental contém uma versão diferente da página.
Existem três maneiras de criar uma cópia incremental:
- criar uma cópia completa e calcular a diferença com a cópia completa anterior;
- análise de logs, criação de uma lista de páginas alteradas e backup de páginas incluídas na lista;
- consultando páginas alteradas no banco de dados.
O primeiro método economiza espaço em disco, mas não reduz a carga no banco de dados. Além disso, se tivermos um backup completo, convertê-lo em um incremental é inútil, já que restaurar um backup completo é mais rápido do que restaurar um backup completo anterior e um incremental. É melhor delegar a tarefa de economizar espaço em disco com essa abordagem a componentes especializados com mecanismos de deduplicação integrados. Estes podem ser sistemas de armazenamento dedicados (EMC DataDomain, HPE StorageWorks VLS, toda a linha NetApp) ou produtos de software (ZFS, Veritas NetBackup PureFile, etc.). Windows Server Desduplicação de dados).
O segundo e o terceiro métodos diferem no mecanismo para determinar a lista de páginas alteradas. A análise de logs consome mais recursos e, para implementá-la, você precisa conhecer a estrutura dos arquivos de log. A maneira mais fácil é perguntar ao próprio banco de dados quais páginas foram alteradas, mas para isso o kernel do SGBD deve ter funcionalidade de rastreamento de alterações de bloco.
A funcionalidade de backup incremental foi introduzida pela primeira vez no software Oracle Recovery Manager (RMAN), introduzido na versão Oracle 8i. A Oracle implementou imediatamente o rastreamento de blocos alterados, portanto não há necessidade de analisar logs.
O PostgreSQL não rastreia blocos modificados, portanto, o utilitário pg_probackup, desenvolvido pela empresa russa Postgres Professional, determina as páginas modificadas analisando o log. No entanto, a empresa também fornece o DBMS PostgresPro, que inclui a extensão ptrack que rastreia alterações de página. Ao usar o pg_probackup com o DBMS PostgresPro, o utilitário solicita páginas alteradas do próprio banco de dados - exatamente o mesmo que o RMAN.
O Microsoft SQL Server, assim como o Oracle, rastreia as páginas alteradas, mas o comando BACKUP só permite fazer backups completos e cumulativos.
O DB2 tem a capacidade de rastrear páginas alteradas, mas está desabilitado por padrão. Uma vez ativado, o DB2 permitirá backups completos, diferenciais e cumulativos.
Uma diferença importante entre as ferramentas descritas nesta seção (exceto pg_probackup) e as ferramentas de backup de arquivos é que elas solicitam imagens de páginas do banco de dados em vez de lerem os dados do disco elas mesmas. A desvantagem desta abordagem é uma pequena carga adicional na base. No entanto, esta desvantagem é mais do que compensada pelo fato de que a leitura da página está sempre correta, portanto não há necessidade de ativar um modo de registro especial durante o backup.
Observe novamente que a presença de cópias incrementais não elimina a necessidade de ter logs disponíveis para recuperação em um momento arbitrário. Portanto, em bancos de dados industriais, os logs são constantemente reescritos em mídias externas e backups, completos e/ou incrementais, são criados de acordo com um cronograma.
A melhor implementação da ideia de backup incremental atualmente é o Zero Data Loss Recovery Appliance, um sistema de hardware e software (na terminologia da Oracle, um sistema integrado) – uma solução especializada da Oracle para fazer backup do próprio banco de dados. O sistema é um cluster. servidores O ZDLRA possui grande capacidade de disco e executa uma versão modificada do software Recovery Manager. Ele pode funcionar com outros sistemas de hardware e software da Oracle (Database Appliance, Exadata, SPARC Supercluster), bem como com bancos de dados Oracle executados em infraestrutura tradicional. Ao contrário do RMAN "regular", o ZDLRA implementa o conceito de "incremental contínuo". O sistema cria uma cópia completa do banco de dados uma única vez e, a partir daí, só faz cópias incrementais. Módulos adicionais do RMAN permitem mesclar cópias, criando novas cópias completas a partir das incrementais.
Para crédito dos desenvolvedores russos, deve-se notar que o pg_probackup também pode mesclar cópias incrementais.
Ao contrário de muitas perguntas semelhantes, a pergunta “qual método de backup é melhor” tem uma resposta clara - a melhor opção é um utilitário nativo do SGBD em uso, que fornece a capacidade de backups incrementais.
Para o administrador de banco de dados, muito mais importantes são as questões de escolha de uma estratégia de backup e integração de ferramentas de backup de banco de dados à infraestrutura corporativa. Mas essas questões estão além do escopo deste artigo.
Fonte: habr.com
