Plugin Postgresql Bacula Enterprise - Guia Rápido - Bacula Brasil e América Latina

Este guia rápido apresenta várias técnicas e estratégias para backup do PostgreSQL com o Bacula Enterprise.

O plugin PostgreSQL é projetado para simplificar e automatizar o procedimento de backup e restauração do banco de dados ou cluster PostgreSQL, sem a necessidade de scripts complexos. O plugin também faz o backup de informações essenciais, como definição de usuários ou tablespaces, suportando tanto a técnica de dump quanto de Point In Time Recovery (PITR).

Este plugin está disponível para diversas plataformas Linux 32/64bit, e suporta oficialmente e suporta versões do PostgreSQL 8.4, 9.0.x, 9.1.x, 9.2.x e superior.

Instalação

O Plugin PostgreSQL é exclusivo do Bacula Enterprise e pode ser baixado pelo repositório do contratante. Para obter, fale conosco.

Para instalar o pacote avulso, na máquina que já tenha o cliente Bacula instalado na mesma versão, por exemplo:

rpm -ivh bacula-enterprise-postgresql-plugin-8.8.5-1.el7.x86_64.rpm

Reinicie o cliente do Bacula após a instalação do plugin. O comando status client deverá mostrar que o cliente carregou o plugin com sucesso.

O plugin pode ser instalado na mesma máquina ou qualquer outra com acesso de rede ao serviço PostgreSQL e também o pacote “postgresql-client”, ou equivalente. As ferramentas como pg_dump e psql devem estar disponíveis, e o plugin utiliza o usuário postgres para acesso aos bancos, sem senha.

Esta configuração (que é a padrão) pode ser feita com a seguinte entrada no seu pg_hba.conf. Esta entrada deve ser a primeira na lista.

local    all     postgres     ident

Se você estiver acessando o banco de dados remoto ou não conseguir desativar a senha método de comunicação, é possível definir a senha através de um arquivo pgpass.

Configuração

O plugin do oracle suporta dos métodos: stream de dumps customizados do Bacula e PITR. No primeiro, a restauração de bases de dados e componentes granulares como schema do banco podem ser selecionados diretamente e automaticamente pelo Bacula, e determinados bancos podem ser filtrados do backup, mas o backup diferencial e incremental depende da depuplicação em nível de blocos do Bacula. No PITR, a configuração do Archive Log do Postgresql é requerida, provendo ao DBA também opções para restaurar transações dos bancos em diversos horários do dia, não apenas quando da realização do backup. Os backups diferenciais e incrementais também são nativos na técnica PITR.

A seleção do método de backup é feita através das opções de plugin do FileSet. Graficamente, como mostrado na Figura 1.

Figura 1. Edição Opção de Plugin Postgresql na Configuração de FileSet do Bweb.

Ou no texto:

FileSet {
  Name = FS_postgresql
    Include {
      Options {
        Signature = MD5
       }
    Plugin = "postgresql: mode=pitr" # ou mode=dump
  }
}

Método Stream de Dumps

Sem especificação de mode=, o plugin Postgresql vai utilizar a técnica de Dumps especial do Bacula, que fornece maior granularidade de elementos do banco na hora do restore, como roles, configuração do postgresql, pg_hba, pg_ident, tablespaces, script de criação do banco, schema e dados do banco. Caso não seja desejado este particionamento, basta usar o mode=dump.

Os dumps do Postresql são armazenados de uma maneira não estruturada, o que pode trazer poucos ganhos com a deduplicação global. Criar rotinas sort no banco que classifiquem as linhas, pode ajuda a promover mais blocos iguais e um melhor rendimento.

Para este método, as opções de configuração do plugin estão disponíveis na Tabela 1.

Opção	Default	Descrição	Exemplo
dump_opt	-c -b	Opções adicionais para o pg_dump	dump_opt=”-c”
user	postgres	Usuário do sistema operacional utilizado pelos comandos	user=heitor
service		pg_service usado pelos comandos	service=main
use_sudo		Usar sudo para executar os comandos do postgresql (quand não é root)	use_sudo
compress	0	Habilita a compressão do dump pelo Postgresql (0-9). 0 é desligado, ideal quando se está utilizando deduplicação	compress=5
database		Irá copiar os bancos de dados que casem com essa string. Para mais de uma string, outra linha de configuração do plugin pode ser especificada	database=heitor*
bin_dir		Localização binários do Postgresql	bin_dir=/opt/pg9.1/bin

Tabela 1. Opções de Stream de Dump do Plugin Postgresql Bacula Enterprise

Stream de Dumps PostgreSQL no Windows

Também é possível usar o plugin Postgresql do Bacula no Linux para fazer backup de bancos de dados instalados no Windows. Qualquer máquina Linux com Cliente e Plugin do Bacula, além do Cliente do PostgreSQL instalado em versão similar a do no Servidor Windows pode ser utilizada.

Para isso, é necessário habilitar o acesso remoto na configuração do servidor PostgreSQL. No arquivo de configuração postgresql.conf, libere os endereços para conexão externa.

# Replace: 
# listen_addresses = 'localhost'
# for
listen_addresses = '*'

Modifique também no servidor o arquivo pg_hba.conf para aceitar (trust) conexões externas confiáveis a partir do IP do Cliente Linux, ou através de uma senha (md5). Trust is usually easier to set up Bacula later.

host    all             all              192.168.0.50/0                  trust
# or
host    all             all              192.168.0.50/0                  md5

Recarregue as configurações do PostgreSQL no Windows para aplicar as alterações.

Na máquina linux, instale o Cliente e Plugin EBacula, além do Cliente Postgresql (ex.: postgresql-client-9.6) caso não tenha feito. Utilize o comando psql -h ip_server-windowspara testar a conexão.

Crie um arquivo /etc/pg_service.conf com as configurações de conexão de cada base remota:

[remote1]
host=192.168.1.163
port=5432
user=postgres
pass=XXXXXX

[remote2]
host=192.168.1.164
port=5432
user=postgres
pass=XXXXXX

Amarre o novo Cliente Bacula ao Director e configure um FileSet (Edit Plugins) como no exemplo:

postgresql: dump_opt=-a database=mybacula service=remote1

Se você preferiu a autenticação por senha no pg_hba.conf, será necessário criar um arquivo .pgpass no HOME do usuário que roda o Cliente Bacula (normalmente root) para configurar a senha e parâmetros de acesso ao banco.

# /root/.pgpass syntax
hostname:port:database:username:password

Crie um novo Job de backup utilizando esse FileSet, faça um reload do Bacula Director para aplicar as alterações e execute um Job de teste.

Melhorando a Deduplicação dos Dumps

Para melhorar o backup con deduplicação de dados do PostgreSQL, é possível configurar um processo CLUSTER de dados, para todas as tabelas dos bancos ou pelo menos para as maiores.

Para cada tabela de banco de dados, configure o CLUSTER de acordo com a chave primária ou qualquer índice desejado:

select * from pg_indexes where tablename='table';
CLUSTER table USING table_pkey;

No bweb, adicione um script Before Job Run Script para o trabalho do PostgreSQL, para executar o comando CLUSTER para cada banco de dados:

su - postgres -c "psql -d database1 -c 'cluster verbose'"
su - postgres -c "psql -d database2 -c 'cluster verbose'"

Restauração dos Dumps

Como mostrado na Figura 2, a restauração de uma base ou de algum componente, é feita diretamente no navegador de arquivos de restauração das interfaces Bacula.

Figura 3. Seleção de Componentes dos Dumps para Restauração

Para restaurar um banco de dados em uma instância do PostgreSQL diferente da original, é necessário primeiro restaurar o schema, e depois os dumps de criação e de dados do Banco.

Método Point-in-Time-Recovery

Para habilitar o modo de arquivamento do Postgresql, a partir da versão 9.x, é necessário configurar as diretivas archive_command, wal_level e archive_mode no seu arquivo de configuração do Postgresql (tipicamente postgresql.conf).

# on 9.0 - 9.x
wal_level = archive
archive_mode = on
archive_command = 'test ! -f /mnt/waldir/%f && cp %p /mnt/waldir/%f'

Crie o diretório menchionado em archive_command:

mkdir /mnt/waldir

Opcionalmente, é possível gerar o arquivamento dos logs do Postgresql, com o seguinte archive_command alternativo:

archive_command = 'test ! -f /mnt/waldir/%f.gz && gzip -c %p > /mnt/waldir/%f.gz'

Observação: também é possível fazer backup utilizando o wal_level hot_standby do servidor master. Do servidor slave normalmente não é possível, pois este deve estar em permanente modo recovery.

Reinicie o serviço do Postgresql para aplicar as alterações.

Este método requer que as funções pg_start_backup e pg_stop_backup estejam operacionais. Você pode testá-las através dos seguintes comandos do pgsql:

select pg_start_backup('test');
select pg_stop_backup();

O diretório /mnt/waldir deve ser removido periodicamente quando seu backup são bem sucedidos e contemplando algum período de retenção. Um ClientRunAfterJob do Bacula pode fazer isso para arquivos maiores que 14 dias:

rm -f $(find /mnt/waldir -type f -mtime +14)

A configuração do plugin deve conter a diretiva archive_dir deve coincidir com o diretório onde os logs estão sendo gravados.

Para o funcionamento do método PITR, a opção Accurate (Precisão) do Job do Bacula também deve estar habilitada:

Job {
  Name = "Postgresql-PITR"
  Client = laptop1-fd
  FileSet = FS_postgresql
  Accurate = yes
  ...
}

A configuração do plugin, bem como a conexão com o banco, pode ser testado com o comando estimate do Bacula:

* estimate listing job=pg-test

Para este método as seguintes opções estão disponíveis na Tabela 2.

Opção	Default	Descrição	Exemplo
mode=pitr		Habilita o backup PITR
archive_dir	pg_xlog	deve apontar para onde os WAL estão sendo gravados pelo archive_command
user	postgres	Usuário do sitema operacional do postgresql
service		Informação de conexão com o Postgresql	service=main
pgpass		Caminho para o arquivo de senha do Postgresql, se necessário	pgpass=/etc/pgpass
bin_dir		Localização binários do Postgresql	bin_dir=/opt/pg9.1/bin

Tabela 2. Opções de PITR do Plugin Postgresql Bacula Enterprise

Para restauração:

Pare o servidor, se ele estiver em execução.
Se você tiver espaço para isso, copie todo o diretório de dados do cluster e quaisquer espaços de tabela para um local temporário, caso precise deles posteriormente. Observe que essa precaução exigirá que você tenha espaço livre suficiente no sistema para armazenar duas cópias do banco de dados existente. Se você não tem espaço suficiente, você precisa no mínimo copiar o conteúdo do subdiretório pg_xlog do diretório de dados do cluster, pois ele pode conter logs que não foram arquivados antes do sistema ficar inativo.
Limpe todos os arquivos e subdiretórios existentes no diretório de dados do cluster e sob os diretórios raiz de todos os espaços de tabela que você está usando.
Restaure os arquivos do banco de dados a partir do seu dump. Se você estiver usando tablespaces, deverá verificar se os links simbólicos em pg_tblspc / foram restaurados corretamente. Se necessário, verifique a opção de restauração do PrefixLinks.
Remova todos os arquivos presentes em pg_xlog; estes vieram do backup e, portanto, são provavelmente obsoletos e não atuais. Normalmente, esse diretório deve estar vazio.
Se você desarquivou os arquivos de segmento do WAL que salvou na etapa 2, copie-os para pg_xlog/. (É melhor copiá-los, não movê-los para que você ainda tenha os arquivos não modificados se ocorrer um problema e você tiver que começar de novo).
Edite o arquivo de comando de recuperação recovery.conf.sample no diretório de dados do cluster e renomeie-o como recovery.conf. Você também pode querer modificar temporariamente o pg_hba.conf para impedir que usuários comuns se conectem até que você tenha certeza de que a recuperação funcionou.
Inicie o servidor. O servidor entrará no modo de recuperação e continuará lendo os arquivos WAL arquivados de que precisa. Se a recuperação for finalizada devido a um erro externo, o servidor pode simplesmente ser reiniciado e continuará a recuperação. Após a conclusão do processo de recuperação, o servidor renomeará o recovery.conf para recovery.done (para evitar a reintrodução acidental do modo de recuperação no caso de uma falha mais tarde) e, em seguida, iniciará as operações normais do banco de dados.

su postgres
cd /path/to/your/data/directory
mv recovery.conf.sample recovery.conf
vi recovery.conf
pg_ctl -D $PWD start

Inspecione o conteúdo do banco de dados para garantir que você tenha se recuperado onde você deseja. Se não, volte para o passo 1. Se tudo estiver bem, deixe os usuários acessarem restaurando o pg_hba.conf.