Capítulo 22. Criação e restauração de cópias de segurança

Sumário
22.1. Método SQL-dump
22.1.1. Restauração da cópia de segurança
22.1.2. Utilização do pg_dumpall
22.1.3. Tratamento de bancos de dados grandes
22.1.4. Precauções
22.2. Cópia de segurança no nível de sistema de arquivo
22.3. Cópia de segurança em-linha
22.3.1. Cópia dos arquivos de segmento do WAL
22.3.2. Criação da cópia de segurança base
22.3.3. Recuperação a partir de cópia de segurança em-linha
22.3.4. Cronologias
22.3.5. Cuidado
22.4. Migração entre versões

Como tudo que contém dados importantes, devem ser feitas cópias de segurança dos bancos de dados do PostgreSQL regularmente. Embora o procedimento seja essencialmente simples, é importante possuir uma compreensão básica das técnicas e princípios subjacentes.

Existem três abordagens fundamentalmente diferentes para fazer cópia de segurança dos dados do PostgreSQL:

Cada uma tem seus próprios pontos fortes e pontos fracos.

22.1. Método SQL-dump

A idéia por trás do Método SQL-dump é gerar um arquivo texto contendo comandos SQL que, ao serem processados pelo servidor, recriam o banco de dados no mesmo estado em que este se encontrava quando o arquivo foi gerado. O PostgreSQL disponibiliza o programa utilitário pg_dump para esta finalidade. A forma básica de utilização deste programa é:

pg_dump nome_do_banco_de_dados > arquivo_de_saída

Conforme pode ser visto, o programa pg_dump escreve o seu resultado na saída padrão. Será visto abaixo como isto pode ser útil.

O pg_dump é um aplicativo cliente normal do PostgreSQL (embora seja particularmente astuta). Isto significa que o procedimento de cópia de segurança pode ser realizado a partir de qualquer hospedeiro remoto que possua acesso ao banco de dados. Porém, deve ser lembrado que o pg_dump não opera com permissão especial. Em particular, é necessário possuir acesso de leitura a todas as tabelas que se deseja fazer cópia de segurança. Portanto, na prática, quase sempre é necessário ser um superusuário do banco de dados.

Para especificar qual servidor de banco de dados o pg_dump deve se conectar, devem ser utilizadas as opções de linha de comando -h hospedeiro e -p porta. O hospedeiro padrão é o hospedeiro local, ou o que estiver especificado na variável de ambiente PGHOST. De maneira semelhante, a porta padrão é indicada pela variável de ambiente PGPORT ou, na falta desta, pelo padrão de compilação (Por conveniência, o servidor normalmente é compilado usando o mesmo padrão).

Assim como qualquer outro aplicativo cliente do PostgreSQL, o pg_dump se conecta por padrão ao banco de dados cujo nome é igual ao nome do usuário corrente do sistema operacional. Para que seja outro, deve ser especificada a opção -U, ou definida a variável de ambiente PGUSER. Não deve ser esquecido que as conexões do pg_dump estão sujeitas aos mecanismos normais de autenticação de cliente (conforme descritos no Capítulo 19).

As cópias de segurança criadas pelo pg_dump são consistentes internamente, ou seja, as atualizações feitas no banco de dados enquanto o pg_dump está executando não estão presentes na cópia de segurança. O pg_dump não bloqueia outras operações no banco de dados enquanto está executando (Exceto as operações que necessitam operar com modo de bloqueio exclusivo, como o VACUUM FULL).

Importante: Quando o esquema do banco de dados é dependente dos OIDs (como chaves estrangeiras, por exemplo) deve-se instruir o pg_dump para que também inclua os OIDs. Para que isto seja feito, deve ser utilizada a opção de linha de comando -o. Também, não são feitas cópias de segurança dos "objetos grandes" por padrão. Se forem utilizados objetos grandes, deve ser consultada a página de referência do programa pg_dump.

22.1.1. Restauração da cópia de segurança

Os arquivos texto criados pelo programa pg_dump são feitos para serem lidos pelo programa psql. A forma geral do comando para restaurar uma cópia de segurança é:

psql nome_do_banco_de_dados < arquivo_de_entrada

onde o arquivo_de_entrada é o que foi utilizado como arquivo_de_saída pelo programa pg_dump. O banco de dados nome_do_banco_de_dados não será criado por este comando, devendo ser criado a partir de template0 antes de executar o psql (por exemplo, usando createdb -T template0 nome_do_banco_de_dados). O psql possui opções semelhantes às do pg_dump para controlar a identificação do servidor de banco de dados e o nome do usuário. Para obter informações adicionais deve ser consultada a página de referência do programa psql.

Antes de começar a executar a restauração, não basta existir o banco de dados de destino. Devem existir, também, todos os usuários que possuam objetos ou concessões para os objetos contidos na cópia de segurança do banco de dados. Caso estes usuários não existam, a restauração não será capaz de recriar os objetos com os mesmos donos e concessões originais (Algumas vezes é o que se deseja, mas geralmente não é).

Uma vez feita a restauração, é aconselhável executar o comando ANALYZE em cada um dos bancos de dados, para que o otimizador possua estatísticas úteis. Uma forma fácil de se fazer é executando vacuumdb -a -z para efetuar o VACUUM ANALYZE de todos os bancos de dados; equivale a executar VACUUM ANALYZE manualmente.

A capacidade do pg_dump e do psql de escrever e ler de canais (pipes) torna possível replicar um banco de dados de um servidor para outro diretamente; por exemplo:

pg_dump -h hospedeiro1 nome_do_banco_de_dados | psql -h hospedeiro2 nome_do_banco_de_dados

Importante: As cópias de segurança produzidas pelo pg_dump são relativas a template0. Isto significa que todas as linguagens, procedimentos, etc. adicionados a template1 também serão incluídos na cópia de segurança feita pelo pg_dump. Como resultado, se estiver sendo utilizado um banco de dados template1 personalizado, ao ser feita a restauração deve ser criado um banco de dados vazio a partir de template0, conforme mostrado no exemplo acima.

Para obter conselhos sobre como carregar grande quantidade de dados no PostgreSQL de forma eficiente, deve ser consultado o Seção 13.4.

22.1.2. Utilização do pg_dumpall

O mecanismo mostrado acima não é cômodo nem apropriado para fazer a cópia de segurança de todo o agrupamento de bancos de dados. Por este motivo é fornecido o programa pg_dumpall. O pg_dumpall faz a cópia de segurança de todos os bancos de dados de um agrupamento, e também salva dados de todo o agrupamento, como os usuários e grupos. A forma básica de utilização deste programa é:

pg_dumpall > arquivo_de_saída

A cópia de segurança gerada pode ser restaurada pelo psql usando:

psql template1 < arquivo_de_entrada

(Na verdade, pode ser especificado qualquer nome de banco de dados existente para começar, mas se estiver sendo feita a restauração em um agrupamento vazio, então template1 é a única escolha disponível). É sempre necessário possuir acesso de superusuário do banco de dados para fazer a restauração de uma cópia de segurança gerada pelo pg_dumpall, para poder restaurar as informações de usuário e de grupo.

22.1.3. Tratamento de bancos de dados grandes

Como o PostgreSQL permite a existência de tabelas maiores do que o tamanho máximo de arquivo do sistema operacional, pode ser problemático fazer a cópia de segurança de uma tabela como esta em um arquivo, uma vez que o arquivo resultante provavelmente terá um tamanho maior que o máximo permitido pelo sistema operacional. Como o pg_dump pode escrever na saída padrão, podem ser utilizadas ferramentas padrão do Unix para superar este possível problema.

Utilização de cópias de segurança comprimidas. Pode ser utilizado o programa de compressão favorito como, por exemplo, o gzip.

pg_dump nome_do_banco_de_dados | gzip > nome_do_arquivo.gz

Restaurar com

createdb nome_do_banco_de_dados
gunzip -c nome_do_arquivo.gz | psql nome_do_banco_de_dados

ou

cat nome_do_arquivo.gz | gunzip | psql nome_do_banco_de_dados

Utilização do comando split. O comando split permite dividir a saída em blocos de tamanho aceitável para o sistema de arquivos subjacente. Por exemplo, para fazer blocos de 1 megabyte:

pg_dump nome_do_banco_de_dados | split -b 1m - nome_do_arquivo

Restaurar com

createdb nome_do_banco_de_dados
cat nome_do_arquivo* | psql nome_do_banco_de_dados

Utilização de formatos de cópia de segurança personalizados. Se o PostgreSQL foi construído em um sistema com a biblioteca de compressão zlib instalada, o formato de cópia de segurança personalizado comprime os dados ao escrever o arquivo de saída. Produz cópias de segurança com tamanhos semelhantes às produzidas utilizando o gzip, mas tem a vantagem adicional de permitir a restauração seletiva das tabelas. O comando abaixo gera a cópia de segurança do banco de dados utilizando o formato de cópia de segurança personalizado (custom dump format):

pg_dump -Fc nome_do_banco_de_dados > nome_do_arquivo

O formato de cópia de segurança personalizado não é um script para o psql, devendo ser restaurado pelo pg_restore. Para obter detalhes devem ser vistas as páginas de referência do pg_dump e do pg_restore.

22.1.4. Precauções

Por motivo de compatibilidade com as versões anteriores, o pg_dump não faz cópia de segurança dos objetos grandes por padrão. Para fazer cópia de segurança dos objetos grandes deve ser utilizado o formato de saída personalizado ou o formato tar, e utilizada a opção -b do pg_dump. Para obter detalhes deve ser consultada a página de referência do pg_dump. O diretório contrib/pg_dumplo, da árvore do código fonte do PostgreSQL, também contém um programa que pode ser utilizado para fazer cópias de segurança dos objetos grandes.

Por favor se familiarize com a página de referência do pg_dump.

SourceForge.net Logo CSS válido!