“Oh, nenhum abrigo pode resistir ao impacto de um meteoro. Mas você, como todo mundo, tem uma reserva, então não se preocupe.
Stanislav Lem, "The Star Diaries of Iyon the Tikhoi"
Fazer backup se refere a manter uma cópia de seus dados em algum lugar fora do local de armazenamento principal.

O principal objetivo do backup é recuperar os dados após sua perda. A esse respeito, ouvimos com frequência que, se você tiver uma réplica de um banco de dados, poderá sempre restaurar os dados dele e não precisará de um backup. Na verdade, o backup permite que você resolva pelo menos três tarefas que não podem ser resolvidas usando uma réplica, e uma réplica não pode ser inicializada sem um backup.
Primeiro, um backup permite que você recupere os dados após um erro lógico. Por exemplo, um contador excluiu um grupo de transações ou um DBA destruiu um espaço de tabela. Ambas as operações são absolutamente legítimas do ponto de vista do banco de dados e o processo de replicação as reproduzirá no banco de dados de 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 o que o acesso aos dados é perdido. O que é especialmente ofensivo, essa violação geralmente ocorre em alta carga ou ao instalar algum tipo de atualização. Mas tanto a alta carga quanto as atualizações regulares indicam que o banco de dados não é um banco de dados de teste e os dados armazenados nele são valiosos.
Por fim, a terceira tarefa, cuja solução requer uma cópia de backup, é a clonagem do banco de dados, por exemplo, para fins de teste.
O backup do banco de dados é de alguma forma baseado em um de dois princípios:
- Buscar dados com salvamento subsequente em um formato arbitrário;
- Instantâneo de arquivos de banco de dados e registros de salvamento.
Vamos examinar mais de perto esses princípios e as ferramentas que os implementam.
Carregando dados
O conjunto de utilitários que vem com qualquer SGBD deve ter ferramentas para fazer upload e download de dados. Os dados são armazenados em formato de texto ou em formato binário específico para um determinado DBMS. A tabela abaixo lista essas ferramentas:
Formato binário | Formato de texto
|
|
---|---|---|
Oráculo | Exportar DataPump / Importar DataPump
Exportar / Importar |
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 | mongoexport / mongoimport |
Cassandra | snapshot / sstableloader do nodetool | cqlsh |
O bom do formato de texto é que ele pode ser editado ou mesmo criado por programas externos, e o formato binário, por sua vez, é bom porque permite o descarregamento e carregamento mais rápido dos dados devido ao carregamento paralelo e economia de recursos na conversão do formato.
Apesar da simplicidade e obviedade da ideia de descarregar 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 terminar, ele se tornará irrelevante;
- é quase impossível fazer um descarregamento consistente de todo o banco de dados sob alta carga, uma vez que o SGBD é forçado a manter um instantâneo de seu estado no momento em que o descarregamento começa. Quanto mais transações forem confirmadas desde o início do upload, maior será o volume do instantâneo (cópias irrelevantes de dados no PostgreSQL, espaço de 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 .; reconstruir índices no momento da inicialização pode levar muito tempo.
No entanto, o descarregamento tem vantagens:
- alta seletividade: você pode descarregar tabelas individuais, campos individuais e até mesmo linhas individuais;
- os dados carregados podem ser carregados em um banco de dados de outra versão e, se o upload for feito em formato de texto, em outro banco de dados.
Portanto, o descarregamento é usado principalmente para tarefas como backup de pequenas tabelas (por exemplo, livros de referência) ou distribuição de conjuntos de dados com a próxima versão do aplicativo.
O método mais comum para fazer backup de bancos de dados é copiar arquivos de banco de dados.
Salvamento "frio" de arquivos de banco de dados
A ideia óbvia é parar o banco de dados e copiar todos os seus arquivos. Isso é chamado de backup frio. O método é extremamente confiável e simples, mas tem duas desvantagens óbvias:
- de um backup frio, você pode restaurar apenas 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 no backup "frio";
- nem todo banco de dados tem uma janela tecnológica quando o banco de dados pode ser interrompido.
Se você está feliz com backups frios, lembre-se disso
- «» . , «» , . , Oracle online redo, , , . PostgreSQL , , .
- , . , «» .
«»
A maioria dos backups de banco de dados modernos são executados copiando os arquivos do banco de dados sem interrompê-lo. Vários problemas são visíveis aqui:
- No início da cópia, o conteúdo do banco de dados pode não coincidir com o conteúdo dos arquivos, uma vez que parte da informação está no cache e ainda não foi gravada no disco.
- Durante a cópia, o conteúdo do banco de dados pode mudar. Se estruturas de dados mutáveis são usadas, 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 de arquivos de banco de dados não são sincronizados 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 DBMS possui um comando que informa que o processo de backup foi iniciado. Sintaticamente, este comando pode ser diferente:
- no Oracle, é um comando separado ALTER DATABASE / TABLESPACE BEGIN BACKUP;
- no PostgreSQL, a função pg_start_backup ();
- no Microsoft SQL Server e no DB2, a preparação para um backup está implícita durante o comando BACKUP DATABASE;
- no MySQL Enterprise, Percoba Server, Cassandra e MongoDB, a preparação é implicitamente executada por um utilitário externo - mysqlbackup, Percona XtraBackup, OpsCenter e Ops Manager, respectivamente.
Apesar das diferenças sintáticas, o processo de preparação para um backup é o mesmo.
É assim que se parece a preparação para backup em um SGBD com estrutura de disco variável, ou seja, em todos os sistemas relacionais de disco tradicionais:
- O momento do início do backup é lembrado; o backup deverá conter os logs do banco de dados a partir de agora.
- É executado um checkpoint, ou seja, todas as alterações ocorridas nas páginas de dados até o momento são descarregadas no disco. Isso garante que nenhum registro seja necessário antes do início do backup durante a recuperação.
- : , , , . , . , . , , .
- , , . , , .
Depois que todos os procedimentos acima forem concluídos, você pode copiar arquivos de dados usando as ferramentas do sistema operacional - cp, rsync e outros. Ativar o modo de backup reduz o desempenho do banco de dados: em primeiro lugar, o volume de logs aumenta e, em segundo lugar, se de repente o modo de backup falhar, a recuperação demorará mais, pois 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, portanto, é apropriado usar ferramentas como um instantâneo do sistema de arquivos ou uma quebra de espelho (BCV) em uma matriz de disco. Alguns DBMS (Oracle, PostgreSQL) deixam ao administrador a oportunidade de escolher independentemente o método de cópia,outros (Microsoft SQL Server) fornecem uma interface para integração de utilitários de backup nativos com sistemas de arquivos ou mecanismos de armazenamento.
Quando o backup for concluído, você precisará trazer o banco de dados de volta 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 em outros bancos de dados por rotinas internas dos comandos correspondentes ou serviços externos.
Esta é a aparência do cronograma para o processo de backup:

- A preparação para o backup (iniciar o backup) leva tempo, às vezes considerável. Mesmo se volumes espelhados ou sistemas de arquivos de instantâneo forem usados, o processo de backup não será instantâneo.
- Juntamente com os arquivos de dados, é necessário salvar os logs desde o início da preparação para o backup até o momento em que o banco de dados voltou ao seu estado normal.
- Você pode se recuperar desse backup no momento em que o banco de dados retornar ao seu estado normal . A recuperação para um momento anterior não é possível.
Com bancos de dados usando estruturas de dados imutáveis (instantâneos, árvores LSM), a situação é mais fácil. A preparação para o backup consiste nas seguintes etapas:
- Os dados da memória são liberados para o disco.
- A lista de arquivos incluídos no backup é gravada. Até que o processo de backup termine, o banco de dados está proibido de excluir esses arquivos, mesmo que eles não sejam mais necessários.
Ao sinalizar o fim do backup, um banco de dados com estruturas imutáveis pode novamente deletar arquivos desnecessários.
Ponto de recuperação
O backup permite restaurar o estado do banco de dados até o momento em que o comando para retornar do modo de backup for concluído. No entanto, um desastre que requer recuperação pode ocorrer a qualquer momento. A tarefa de restaurar o estado do banco de dados para um momento arbitrário é chamada de recuperação point-in-time.
Para fazer isso, você deve salvar os logs do banco de dados a partir do momento em que o backup foi concluído e continuar a aplicar os logs à cópia restaurada durante o processo de restauração. Depois que o banco de dados foi restaurado a partir da cópia de backup no final da cópia, o estado do banco de dados (arquivos e páginas em cache) é garantido como correto, portanto, um modo de registro especial não é necessário. Aplicando os logs até o momento desejado, é possível obter o estado do banco de dados a qualquer momento.
Se a velocidade de restauração de um backup for limitada apenas pela largura de banda do disco, a velocidade de aplicação dos logs geralmente será limitada pelo desempenho do processador. Se ocorrerem alterações no banco de dados principal em paralelo, durante a recuperação, todas as alterações serão executadas sequencialmente - na ordem em que foram lidas no log. Portanto, o tempo de recuperação é linearmente dependente de quão longe o ponto de recuperação está do ponto final do backup. Por isso, você deve fazer backups completos com bastante frequência - pelo menos uma vez por semana para bancos de dados com baixa carga transacional e antes da cópia diária de bancos de dados altamente carregados.
Backups incrementais
Para acelerar a recuperação ponto a ponto, gostaria de poder fazer backup com a maior freqüência possível, mas ao mesmo tempo não ocupar espaço extra em disco e não sobrecarregar o banco de dados com tarefas de backup.
A solução para o problema é um backup incremental, ou seja, copiar apenas as páginas de dados que foram alteradas desde o backup anterior.
Os backups incrementais só fazem sentido para DBMSs que usam estruturas de dados mutáveis.
O incremento pode ser calculado a partir do backup completo (cópia cumulativa) e de qualquer cópia anterior (cópia diferencial).

Infelizmente, não existe uma terminologia uniforme e diferentes fabricantes usam termos diferentes:
Diferencial | Cumulativo
|
|
---|---|---|
Oráculo | Diferencial | Cumulativo |
PostgresPro | Incremental | - |
Microsoft SQL Server | - | Diferencial |
IBM DB2 | Delta | Incremental |
MySQL Enterprise | Incremental | Diferencial |
Percona Server | Incremental |
Com backups incrementais, o processo de restauração ponto a ponto se parece com este:
- o último backup completo feito antes da restauração ser restaurada;
- cópias incrementais são restauradas sobre a cópia completa;
- rola os logs do ponto em que o backup foi iniciado até o ponto de recuperação.
Ter uma cópia cumulativa acelera o processo de recuperação. Assim, por exemplo, para restaurar o estado básico para um ponto entre T3 e T4, você precisa restaurar duas cópias incrementais e restaurar para um ponto após T4 - apenas um.
Obviamente, o volume de uma cópia cumulativa é menor do que o volume de várias cópias diferenciais, porque algumas páginas foram alteradas várias vezes e cada cópia incremental contém sua própria versão da página.
Existem três maneiras de criar uma cópia incremental:
- criar uma cópia completa e calcular a diferença da 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;
- solicitação de páginas alteradas no banco de dados.
O primeiro método economiza espaço em disco, mas não resolve o problema de redução da carga no banco de dados. Além disso, se tivermos um backup completo, transformá-lo em um backup incremental não tem sentido, pois restaurar um backup completo é mais rápido do que restaurar uma cópia completa anterior e um incremento. Com essa abordagem, é melhor mudar a tarefa de economizar espaço em disco para componentes especiais com mecanismos de desduplicação integrados. Podem ser sistemas de armazenamento especiais (EMC DataDomain, HPE StorageWorks VLS, toda a linha NetApp) ou produtos de software (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).
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, além disso, você precisa conhecer a estrutura dos arquivos de log para implementá-la. É mais fácil perguntar ao próprio banco de dados quais páginas foram alteradas, mas para isso o kernel do DBMS deve ter a funcionalidade de rastreamento dos blocos alterados (rastreamento de alteração de bloco).
A funcionalidade de backup incremental foi introduzida pela primeira vez com o software Oracle Recovery Manager (RMAN), que foi introduzido com o lançamento do Oracle 8i. A Oracle implementou imediatamente o rastreamento de bloco alterado, portanto, não há necessidade de analisar os logs.
PostgreSQL não rastreia blocos alterados, então o utilitário pg_probackup, desenvolvido pela empresa russa Postgres Professional, detecta as páginas alteradas analisando o log. No entanto, a empresa também fornece PostgresPro, que inclui uma extensão ptrack que rastreia as mudanças de página. Ao usar o pg_probackup com PostgresPro, o utilitário consulta o próprio banco de dados em busca de páginas modificadas, assim como o RMAN faz.
O Microsoft SQL Server, como o Oracle, rastreia as páginas modificadas, mas o comando BACKUP só permite 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 para pg_probackup) e as ferramentas de backup baseado em arquivo é que elas consultam o banco de dados em busca de imagens de página, em vez de lerem os próprios dados do disco. A desvantagem dessa abordagem é a pequena carga adicional na base. No entanto, essa desvantagem é mais do que compensada pelo fato de que a página lida está sempre correta, portanto, não há necessidade de habilitar um modo especial de diário durante o backup.
Observe novamente que a presença de backups incrementais não substitui a necessidade de os logs serem restaurados em um momento arbitrário. Portanto, em bancos de dados industriais, os logs são constantemente reescritos em mídia externa e backups, completos e / ou incrementais, são criados em uma programação.
A melhor implementação da ideia de backup incremental hoje é o Zero Data Loss Recovery Appliance (sistema projetado na terminologia Oracle) - uma solução Oracle especializada para fazer backup de seu próprio banco de dados. O complexo é um cluster de servidores com grande volume de discos, no qual uma versão modificada do software Recovery Manager está instalada e pode funcionar tanto com outros complexos de software e hardware Oracle (Database Appliance, Exadata, SPARC Supercluster) quanto com bancos de dados Oracle em infraestrutura tradicional. Ao contrário do RMAN “regular”, o ZDLRA implementa o conceito de “incremental para sempre”. O sistema cria uma cópia completa do banco de dados apenas uma vez e, em seguida, faz apenas cópias incrementais. Módulos RMAN adicionais permitem mesclar cópias,criar novas cópias completas a partir das incrementais.
Para o crédito dos desenvolvedores russos, deve-se notar que pg_probackup também é capaz de mesclar cópias incrementais.

Ao contrário de muitas perguntas semelhantes, a pergunta "qual método de backup é o melhor" tem uma resposta inequívoca - o melhor é o utilitário nativo para o DBMS usado, que fornece a capacidade de copiar incrementalmente.
Para o DBA, as questões de escolha de uma estratégia de backup e a integração de backups de banco de dados na infraestrutura corporativa são muito mais importantes. Mas essas questões estão além do escopo deste artigo.