Olá, pessoal!
Hoje vamos falar sobre os diferentes tipos de backup no PostgreSQL, entenderemos a razão pela qual devemos sempre ter um backup de segurança ou um plano de backup de um ou mais bancos de dados para garantir que não haja perda em caso de desastres.
Esses desastres podem ocorrer de diferentes formas e por diversas razões:
- Corrupção dos dados;
- Problema de hardware;
- Erro humano;
- Erros de software ou aplicações;
- Políticas de retenção de backup.
Existem apenas três formas fundamentais de se fazer um backup de um banco de dados no PostgreSQL, são elas:
- SQL dump;
- File system level backup;
- Continuous archiving.
Cada uma dessas formas possui prós e contras, os quais explicaremos a seguir.
1- SQL Dump:
Apesar do dump não ser considerado conceitualmente como uma forma de backup, a ideia por trás desse método é gerar um arquivo lógico com comandos SQL, no qual feito o restore do banco em um determinado servidor, irá recriar o banco de dados no mesmo estado do momento que foi feito o dump, fazendo uma espécie de snapshot sem ocasionar bloqueio de operações executados no banco.
O PostgreSQL fornece o utilitário pg_dump para este propósito, o qual pode ser utilizado via linha de comando com a seguinte sintaxe:
pg_dump dbname > dumpfile
É necessário ter permissão de leitura em todas as tabelas do banco para proceder com o processo de backup, porém tal método não opera com permissões especiais. Portanto, deve ser executado por um usuário do banco que tenha permissão superuser.
A vantagem desse método é permitir migrar o banco de dados para uma versão mais recente do PostgreSQL, ou até mesmo transferir o banco entre diferentes servidores com diferentes arquiteturas.
A desvantagem desse processo é que não garante o Point-in-Time Recovery (PITR) do ambiente de produção em caso de desastre e não permite fazer replicação a partir dos logs de transação. Recomendamos fazer um backup full do cluster sempre que executar o comando pg_dump em cada banco de dados.
2- File System Level Backup:
Essa abordagem consiste em fazer uma cópia dos arquivos (Backup Full) do PostgreSQL, obtendo duas formas: backup offline ou backup online (com o serviço do PostgreSQL em execução).
Existem duas restrições que podem tornar esse método impraticável:
- O serviço do Postgres deve estar offline;
- Não permite fazer restore de tabelas individuais ou de bancos a partir dos seus respectivos arquivos ou diretórios. Portanto, deve-se fazer backup full do cluster e, posteriormente, restore do mesmo.
Uma alternativa seria fazer um “snapshot consistente” do diretório de dados, desde que o sistema de arquivos suportasse tal funcionalidade. Esse método é executado normalmente enquanto o servidor de banco está executando.
Contudo, o backup gerado contém arquivos de base em um estado onde o servidor de origem não foi desligado apropriadamente. Isso significa que, quando iniciar um novo cluster a partir do arquivo de backup, pode ocorrer de o serviço do PostgreSQL não iniciar corretamente, sendo necessário fazer validação ou restore a partir dos arquivos de log denominado WAL.
3- Continuous archiving:
Esse método consiste em fazer backup dos logs de transação. É recomendado configurá-lo em paralelo ao backup a nível de sistema de arquivos visto anteriormente, permitindo fazer um Point-In-Time Recovery do banco de dados um pouco antes do momento do desastre ou da perda de dados. Mas lembre-se, isso só seria possível se combinarmos essa prática com file-system-level backup.
Por padrão os arquivos de log (WAL) estão localizados no subdiretório pg_wal/ do Postgres. E ao configurar rotinas de backup, é interessante gravar os arquivos de backup full e log em um storage separado do servidor.
Conclui-se que, os dados são valiosos então é sempre bom mantermos backups adicionais em locais diferentes como forma de garantir a recuperação dos dados em caso de desastre.
Embora sejam simples, é importante ter um entendimento claro das técnicas subjacentes e suas premissas. Relembrando que, tão importante quanto fazer ou ter uma rotina de backup é testar esses mesmos restaurando-os em um servidor de teste.
Esperamos que este post tenha ajudado de alguma forma. Caso você tenha alguma dúvida, não deixe de nos contatar!
Até o próximo post ?
