Ter backups regulares de seu banco de dados PostgreSQL por si só não é suficiente para recuperação de desastres – você precisa garantir que os arquivos de backup estejam acessíveis e íntegros se e quando necessário para um procedimento de restauração. Continue lendo para ver alguns exemplos de como configurar testes automatizados de backups do PostgreSQL.
Backups feitos usando pg_basebackup
O pg_basebackup os backups contêm todo o diretório de dados de um cluster de banco de dados. Esse diretório geralmente é empacotado em um tarball, às vezes com um tarball adicional para arquivos WAL que foram criados desde o início do backup.
Para testar um pg_basebackup tarball, primeiro descompacte o tarball em um diretório vazio. Se houver um tarball de arquivo WAL separado, descompacte-o no
pg_wal diretório dentro do novo diretório:$ mkdir backup-test
$ cd backup-test
$ tar --no-same-owner xvf /path/to/base.tar.gz
$ mkdir -p pg_wal
$ cd pg_wal
$ tar --no-same-owner xvf /path/to/pg_wal.tar.gzAgora você pode iniciar um processo do servidor PostgreSQL para este diretório:
$ pg_ctl -D path/to/backup-test start(Observação:pg_ctl é uma ferramenta de linha de comando incluída na distribuição padrão do Postgres. Ela está disponível em todos os lugares que o próprio Postgres estiver, semelhante a outras ferramentas incluídas como o psql e pg_dump .Saiba mais sobre pg_ctl aqui.)
Se já houver um servidor PostgreSQL instalado/em execução nesta máquina, você provavelmente desejará iniciar em uma porta diferente da 5432 padrão:
$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" startSe tudo deu certo até agora, você vai querer verificar se os dados dentro do seu banco de dados restaurado estão corretos. Se você tiver scripts de teste automatizados para executar em seu banco de dados, agora seria um bom momento para iniciar pelo menos um pequeno conjunto desses testes nesse banco de dados restaurado. Caso contrário, você pode fazer algumas verificações rápidas usando o psql:
$ psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"O comando acima faz uma consulta simples em uma tabela que deveria existir. O código de saída do psql deve informar se a consulta foi bem-sucedida ou não. Claro, você pode executar consultas mais complexas, ou executar um arquivo .sql, ou até mesmo um script de teste separado que se conectará a esse banco de dados e executará testes.
Quando terminar o teste, você pode parar o processo do servidor Postgres com:
$ pg_ctl -D path/to/backup-test stopE limpe todo o diretório do cluster de banco de dados extraído:
$ rm -rf path/to/backup-testVeja como fica quando está tudo junto:
#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest backup
# TODO: copy out base.tar.gz and pg_wal.tar.gz of latest backup
# create a directory to work in
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
mkdir $BACKUP_DIR
# unpack the backup archives
tar -C $BACKUP_DIR --no-same-owner xvf /path/to/base.tar.gz
mkdir -p $BACKUP_DIR/pg_wal
tar -C $BACKUP_DIR/pg_wal --no-same-owner xvf /path/to/pg_wal.tar.gz
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/base.tar.gz /path/to/pg_wal.tar.gzBackups feitos usando pg_dump
O pg_dump ferramenta (docs) também pode ser usada para criar backups - isso é mais flexível, pois você pode selecionar opcionalmente o banco de dados/esquema/tabelas que deseja fazer backup, em oposição apg_basebackup que é um processo de tudo ou nada.
Com pg_dump , você pode gerar um único
.sql script ou um binário .pgdmp arquivo que contém todos os dados (e opcionalmente também as instruções DDL para criar as tabelas/índices etc.). Para restaurar esse arquivo, você precisa se conectar a um servidor livedatabase e executar os comandos SQL dentro do arquivo .sql/.pgdmp. Embora você possa usar o psql normal para executar o arquivo .sql, você precisará usar o pg_restore comando (docs) para executar o arquivo .pgdmp. Para testar esses backups, primeiro buscamos o arquivo e, em seguida, criamos um novo cluster de banco de dados vazio:
$ rm -rf path/to/backup-test
$ pg_ctl -D path/to/backup-test initdbe inicie um servidor PostgreSQL nele, escutando na porta 6000 como antes:
$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" startÉ possível gerar pg_dump arquivos que são totalmente autocontidos, mas também é possível gerá-los para que não sejam. Portanto, dependendo de como o dump foi gerado, algumas etapas de configuração podem ser necessárias:
- criar um banco de dados
- criar tabelas, índices etc.
- conceder privilégios
Feito isso, você pode usar o psql ou pg_restore para trazer os dados de volta à vida:
# for .sql files
$ psql -p 6000 -h /tmp -v ON_ERROR_STOP=1 -1 -b -f path/to/dump.sql
# for .pgdmp files
$ pg_restore -p 6000 -h /tmp -d mydb -C -1 -f path/to/dump.pgdmpComo antes, neste ponto, os testes podem ser realizados para garantir a sanidade dos dados armazenados.
Veja como fica, tudo junto:
#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest dump
# TODO: copy out the dump.sql or dump.pgdmp of latest backup
# create an empty database cluster
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
pg_ctl -D $BACKUP_DIR initdb
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# TODO: perform any specific setup steps here
# restore the file, .sql:
psql -p 6000 -h /tmp -v ON_ERROR_STOP=1 -1 -b -f path/to/dump.sql
# or .pgdmp:
pg_restore -p 6000 -h /tmp -d mydb -C -1 -f path/to/dump.pgdmp
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/dump.*Cuidado com os gatilhos
Ao restaurar um pg_dump backup, os dados são inseridos em tabelas, assim como quando um aplicativo faz isso. Se você tiver gatilhos que se conectam a serviços externos para notificar sobre inserções de linha, seria melhor desativá-los durante o procedimento de restauração.
Ao invocar pg_dump para emitir arquivos sql, você pode usar a opção
--disable-triggers dizer ao pg_dump para gerar script para desabilitar os gatilhos durante a inserção. Ao invocar pg_restore em um banco de dados que já possui gatilhos, você pode usar o
--disable-triggers em pg_restore para obter o mesmo efeito. Teste PITR
A recuperação pontual (PITR) no Postgres depende de um backup completo feito usandopg_basebackup , e uma sequência de arquivos WAL a partir desse ponto até o momento em que você deseja recuperar. O teste de PITR, portanto, envolve testar o backup completo, bem como os arquivos WAL subsequentes.
Para testes de backup automatizados, não temos um destino de recuperação específico. Todos os arquivos WAL arquivados do último backup em diante até o mais recente devem ser testados. A maneira mais fácil de testar isso é seguir as mesmas etapas do pg_basebackup método de teste, com apenas uma etapa adicional. Após descompactar o último backup, busque todos os arquivos WAL relevantes e disponíveis e coloque-os em
pg_wal antes de iniciar o servidor Postgres. Especificamente:#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest backup
# TODO: copy out base.tar.gz and pg_wal.tar.gz of latest backup
# create a directory to work in
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
mkdir $BACKUP_DIR
# unpack the backup archives
tar -C $BACKUP_DIR --no-same-owner xvf /path/to/base.tar.gz
mkdir -p $BACKUP_DIR/pg_wal
tar -C $BACKUP_DIR/pg_wal --no-same-owner xvf /path/to/pg_wal.tar.gz
# --> this is the new extra step <--
# TODO: fetch all WAL files from the WAL archive since the last
# backup, and place them in $BACKUP_DIR/pg_wal
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/base.tar.gz /path/to/pg_wal.tar.gzIsso deve verificar se o último backup e os arquivos WAL subsequentes são bons, para que possam ser usados para PITR se e quando necessário.
