Qual a forma correta de se fazer backup?

Posted on: January 29, 2020 12:18 PM

Posted by: Renato

SQL DUMP

Também conhecido como pg_dump, essa é a abordagem mais simples de ser executada/implementada. Sua utilização consiste na execução do programa pg_dump.

Os pré-requisitos para sua utilização são: ter acesso a partir de um host remoto, ou local, acesso liberado ao database para o usuário, e permissão de leitura nas tabelas do banco de dados.

Obs.: Normalmente se executa o pg_dump com um usuário SUPERUSER, como por exemplo o postgres, para que não haja problemas com permissão de acesso.

Vantagens:

O dump pode ser restaurado em qualquer instância contendo uma versão mais recente do PostgreSQL;
O dump pode ser restaurado em um servidor com arquitetura diferente, indo de uma máquina 32-bits para uma 64-bits, por exemplo;
É uma cópia fiel dos dados no momento em que foi iniciada sua execução;
É possível gerar dump de objetos específicos ou excluir alguns objetos do dump;
Possibilita paralelismo da execução, caso seja utilizado “directory” como archive format.

Desvantagens:

Por ser uma cópia fiel dos dados no momento em que o pg_dump começou a ser executado, talvez o tempo entre o último dump e o momento de uma possível falha, torne inviável a utilização desse dump para redisponibilização do ambiente com a menor perda de dados possível;
Caso seja utilizado o formato PLAIN TEXT, o arquivo gerado pode ser muito grande;
O ponto apresentado como “vantagem número 5”, esbarra na limitação do I/O de disco, ou seja, vários processos podem ser abertos para dump, mas não necessariamente os processos conseguirão escalar a leitura e a escrita dos dados no disco.

FILESYSTEM LEVEL BACKUP (sem PITR)

Esse método consiste em realizar uma cópia do diretório de dados do PostgreSQL. A cópia pode ser realizada de muitas formas, como por exemplo: pelo comando cp, rsync, tar, etc.

Vantagens:

Se executado via rsync, em uma segunda execução, o tempo de geração do backup será muito menor.

Desvantagens:

Para que o backup seja um backup “útil”, é necessário que a instância de banco de dados esteja off-line ou que seja sinalizado, via comando pg_start_backup(), o início da execução de um backup;
É necessário que a instância esteja off-line para restauração do backup;
Não é possível determinar quais objetos serão alvo do backup. Com isso, todos os objetos da instância de banco de dados farão parte do backup;
Em caso de crash, todas as alterações que ocorreram entre o momento em que backup foi executado e a falha, serão perdidas (Caso não esteja configurado o Point-in-Time Recovery).

CONTINUOUS ARCHIVE + POINT-IN-TIME RECOVERY

Por padrão, o PostgreSQL retém os logs de transação no diretório $PGDATA/pg_xlog. Após um determinado tempo, esses logs de transação podem ser arquivados em uma área específica a seu critério (Ex.: servidor de arquivos, TSM, fita, etc.). Dessa forma, é possível combinarmos o FILE-SYSTEM-LEVEL BACKUP com os logs de transação arquivados. Em caso de crash é possível restaurar o backup de filesystem e, posteriormente, executar os logs de transação até um momento anterior à falha.

Vantagens:

Em caso de crash, a perda de dados é mínima devido à execução dos logs de transação arquivados, sobre o filesystem level backup da instância;
É possível executar o backup com o banco de dados online;

Desvantagem:

Não é possível determinar quais objetos serão alvo do backup. Com isso, todos os objetos da instância de banco de dados farão parte do backup;
Durante a execução do backup, a quantidade de logs de transação retidos no $PGDATA/pg_xlog pode aumentar substancialmente devido ao fato de, durante o backup, o PostgreSQL reter logs de transação para que durante o processo de restauração, a base de dados esteja em um estado de consistência adequado.
A administração de desse método é uma das mais trabalhosas;

Existem outras soluções de backup para o PostgreSQL que vale à pena dar uma olhada, como por exemplo: pg_rman, barman, etc.

É muito importante que entendamos que essas metodologias não devem ser utilizadas individualmente, mas sim devemos focar na hipótese de CRIAR NOSSA PRÓPRIA SOLUÇÃO DE BACKUP. Por exemplo:

É extremamente interessante mantermos uma rotina de backup físico (filesystem level backup), aliada ao PITR (Point-in-time recovery). Estando funcional, essa rotina nos transmitirá um pouco mais de confiança em relação a possíveis desastres. O principal problema reside no fato de que esse backup só poderá ser restaurado em um servidor com as mesmas configurações do servidor de origem (Arquitetura, versão de SO, Versão do PostgreSQL, etc.).

Para complementar essa “solução de backup”, é bastante interessante manter em paralelo a execução de backups lógicos (pg_dump ou pg_dumpall). Imagine que você precise restaurar um backup de 10 anos atrás em um momento onde o PostgreSQL estava na versão 7.0, sistema operacional Red Hat 3 “x86”. Em uma situação dessas você deverá CONSTRUIR UM SERVIDOR NOVO COM ESSES MESMOS RECURSOS ou, caso tenha disponível, restaurar seu dump em qualquer versão superior do PostgreSQl, seja lá qual for a versão do sistema operacional ou a arquitetura.