A ideia por trás dessa abordagem de cópia de segurança é produzir um arquivo com comandos SQL que, ao ser processado, irá recriar o banco de dados no mesmo estado em que se encontrava no momento do em que foi produzida a cópia de segurança. O PostgreSQL fornece o programa utilitário pg_dump para esta finalidade. O uso básico desse comando é:
pg_dumpnome_do_banco_de_dados>nome_do_arquivo
Como se pode ver, o utilitário pg_dump escreve seu resultado na saída padrão. Veremos a seguir como isto pode ser útil. Embora o comando acima crie um arquivo de texto, o utilitário pg_dump pode criar arquivos em outros formatos que permitem paralelismo e controle mais refinado da restauração de objeto.
O utilitário pg_dump é uma aplicação
cliente do PostgreSQL comum
(embora particularmente inteligente).
Isto significa que se pode executar este procedimento de
cópia de segurança a partir de qualquer hospedeiro remoto que
tenha acesso ao banco de dados.
Mas lembre-se que o utilitário pg_dump
não opera com permissões especiais.
Em particular, deve ter acesso de leitura a todas as tabelas das
quais se deseja fazer a cópia de segurança, portanto, para fazer uma
cópia de segurança de todo o banco de dados, quase sempre se precisa
executá-lo como superusuário do servidor de banco de dados.
(Caso não se tenha privilégios suficientes para fazer a cópia de
segurança de todo o banco de dados, ainda poderá ser feita a cópia
de segurança das partes do banco de dados às quais se tem acesso,
usando opções como -n
ou esquema-t .)
tabela
Para especificar em qual servidor de banco de dados o utilitário
pg_dump deve se conectar, devem ser
usadas as opções de linha de comando
-h e
hospedeiro-p .
O hospedeiro padrão é o hospedeiro local, ou o que a variável
de ambiente portaPGHOST especificar.
Da mesma forma, a porta padrão é indicada pela variável de ambiente
PGPORT ou, na falta dessa, o padrão compilado.
(Convenientemente, o servidor terá normalmente o mesmo padrão compilado.)
Como qualquer outra aplicação cliente do
PostgreSQL, o utilitário
pg_dump se conectará por padrão com um
nome de usuário do banco de dados igual ao nome do usuário corrente
do sistema operacional.
Para mudar isto, deve-se especificar a opção -U,
ou definir a variável de ambiente PGUSER.
Lembre-se que as conexões efetuadas pelo utilitário
pg_dump estão sujeitas aos mecanismos
normais de autenticação de cliente
(descritos em Autenticação de cliente).
Uma vantagem importante do utilitário pg_dump sobre os outros métodos de cópia de segurança descritos a seguir, é que a saída produzida pelo pg_dump geralmente pode ser carregada em versões mais recentes do PostgreSQL, enquanto as cópias de segurança no nível de arquivo, e o arquivamento contínuo, são extremamente específicos da versão do servidor. O utilitário pg_dump também é o único método que irá funcionar ao transferir um banco de dados para uma arquitetura de máquina diferente, como passar de um servidor de 32 bits para um de 64 bits.
As cópias de segurança criadas pelo utilitário
pg_dump são consistentes internamente,
ou seja, a cópia de segurança representa um instantâneo do
banco de dados no momento em que o utilitário
pg_dump começou a ser executado.
O utilitário pg_dump não bloqueia outras
operações no banco de dados enquanto está funcionando.
(As exceções são aquelas operações que precisam operar com bloqueio
exclusivo, como a maioria das formas de ALTER TABLE.)
Os arquivos de texto criados pelo pg_dump destinam-se a ser lidos pelo programa psql usando suas configurações padrão. O formato geral do comando para restaurar uma cópia de segurança de texto é
psql -Xnome_do_banco_de_dados<nome_do_arquivo
onde nome_do_arquivo
é o nome do arquivo gerado pelo utilitário
pg_dump.
O banco de dados
nome_do_banco_de_dados
não será criado por este comando, então deve-se criá-lo a partir do
banco de dados template0 antes de executar o
psql
(por exemplo, usando createdb -T template0 ).
Para garantir que o psql seja executado
com suas configurações padrão, deve-se usar a opção
nome_do_banco_de_dados-X (--no-psqlrc).
O psql oferece opções semelhantes às do
pg_dump para especificar o servidor de
banco de dados ao qual se conectar e o nome de usuário a ser usado.
Veja a página de referência do psql
para obter mais informações.
Arquivos de cópia de segurança que não sejam de texto puro devem ser restaurados usando o utilitário pg_restore.
Antes de restaurar a cópia de segurança SQL, todos os usuários que são donos de objetos no banco de dados salvo, ou receberam permissões, já deverão existir. Caso contrário, a restauração irá falhar ao recriar os objetos com o dono e/ou permissões originais. (Às vezes é o que se deseja, mas geralmente não é.)
Por padrão, o script psql continua em
execução após ser encontrado um erro de SQL.
Pode-se, então, alterar este comportamento executando o
psql com a chave
ON_ERROR_STOP definida, fazendo com que o
psql termine com o status de saída 3
se ocorrer um erro de SQL:
psql -X --set ON_ERROR_STOP=onnome_do_banco_de_dados<nome_do_arquivo
De qualquer forma, restará apenas um banco de dados parcialmente
restaurado.
Como alternativa, pode-se especificar que toda a cópia de segurança
deva ser restaurada como uma única transação, de modo que a
restauração seja inteiramente concluída, ou inteiramente desfeita.
Este modo pode ser especificado passando as opções de linha de
comando -1 ou --single-transaction
para o psql.
Ao usar este modo, deve-se estar ciente de que mesmo um pequeno erro
poderá desfazer uma restauração que está sendo executada há horas.
Entretanto, isto ainda pode ser preferível a ter que limpar
manualmente um banco de dados complexo após uma cópia de segurança
parcialmente restaurada.
A capacidade do pg_dump e do psql de escrever ou ler por encadeamento (pipe), possibilita salvar um banco de dados diretamente de um servidor para outro. Por exemplo:
pg_dump -hhospedeiro1nome_do_banco_de_dados| \ psql -X -hhospedeiro2nome_do_banco_de_dados
As cópias de segurança produzidas pelo
pg_dump são relativas ao banco de dados
modelo template0.
Isto significa que quaisquer linguagens, procedimentos, etc.
adicionados via template1 também serão copiados
pelo pg_dump.
Como resultado, ao restaurar, se estiver sendo usado um
banco de dados template1 personalizado, deverá
ser criado um banco de dados vazio a partir do banco de dados
template0, como no exemplo acima.
Após restaurar uma cópia de segurança é aconselhável executar o comando ANALYZE em cada banco de dados, para que o otimizador de consultas tenha estatísticas úteis; veja Atualização das estatísticas do planejador e Processo de limpeza automática para obter mais informações. Para obter mais informações sobre como carregar grandes quantidades de dados no PostgreSQL de forma eficiente, veja Carregamento de dados no banco de dados.
O utilitário pg_dump faz a cópia de segurança de apenas um único banco de dados por vez, e não registra informações sobre funções de banco de dados (roles) ou espaços de tabelas (porque são para toda a instância, e não por banco de dados). Para dar suporte a uma cópia de segurança adequada de todo o conteúdo da instância, é fornecido o programa pg_dumpall, que faz a cópia de segurança de cada banco de dados de uma determinada instância, e também registra os dados globais de toda a instância, como funções de banco de dados e definições de espaços de tabelas. O uso básico desse comando é:
pg_dumpall > nome_do_arquivo
A cópia de segurança resultante pode ser restaurada usando o psql:
psql -X -f nome_do_arquivo postgres
(Na verdade, pode-se especificar qualquer nome de banco de dados
existente para começar, mas se estiver carregando em uma instância
vazia, geralmente deverá ser usado o postgres.)
É sempre necessário ter acesso de superusuário ao servidor de
banco de dados para restaurar uma cópia de segurança produzida pelo
pg_dumpall, porque isto é necessário
para restaurar as informações de função de banco de dados e
espaço de tabelas.
Se forem usados espaços de tabelas, deve-se certificar de que os
caminhos dos espaços de tabelas presentes na cópia de segurança
sejam apropriados para a nova instalação.
O utilitário pg_dumpall trabalha executando comandos para recriar funções de banco de dados, espaços de tabelas e bancos de dados vazios e, em seguida, chamando o pg_dump para cada banco de dados. Isto significa que, embora cada banco de dados seja consistente internamente, os instantâneos de diferentes bancos de dados não são sincronizados.
Pode-se salvar apenas os dados de toda a instância, usando a opção
--globals-only do pg_dumpall.
É necessário para complementar a cópia de segurança da instância,
se estiver sendo executado o comando
pg_dump em bancos de dados individualmente.
Alguns sistemas operacionais têm limites máximos de tamanho de arquivo, causando problemas ao criar grandes arquivos de saída do pg_dump. Felizmente, o pg_dump pode escrever na saída padrão, então pode-se usar as ferramentas padrão do Unix para contornar este problema em potencial. Existem vários métodos possíveis:
Uso de cópias de segurança comprimidas. Pode-se usar o programa de compressão favorito como, por exemplo, o gzip:
pg_dumpnome_do_banco_de_dados| \ gzip >nome_do_arquivo.gz
E restaurar usando:
gunzip -cnome_do_arquivo.gz | \ psqlnome_do_banco_de_dados
ou:
catnome_do_arquivo.gz | \ gunzip | psqlnome_do_banco_de_dados
Uso do split.
O comando split permite dividir a saída em
arquivos menores, com tamanho aceitável para o sistema de arquivos
subjacente.
Por exemplo, pode-se criar blocos de 2 gigabytes:
pg_dumpnome_do_banco_de_dados| \ split -b 2G -nome_do_arquivo
E restaurar usando:
catnome_do_arquivo* | \ psqlnome_do_banco_de_dados
Se estiver sendo usado o comando split do GNU, será possível usar o gzip junto:
pg_dump nome_do_banco_de_dados | \
split -b 2G --filter='gzip > $FILE.gz'
E restaurar usando o zcat.
Uso do formato de cópia de segurança personalizado do pg_dump.
Se o PostgreSQL foi construído em um
sistema com a biblioteca de compressão
zlib instalada, o formato personalizado
de cópia de segurança compactará os dados à medida que os escreve
no arquivo de saída.
Isto irá produzir arquivos de cópia de segurança com tamanhos
semelhantes ao se usar o gzip, mas com a vantagem
adicional de que as tabelas podem ser restauradas seletivamente.
O seguinte comando faz a cópia de segurança de um banco de dados
usando o formato de cópia de segurança personalizado:
pg_dump -Fcnome_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 usando o pg_restore. Por exemplo:
pg_restore -dnome_do_banco_de_dadosnome_do_arquivo
Veja a página de referência do pg_dump e do pg_restore para obter detalhes.
Para bancos de dados muito grandes, pode ser necessário combinar o
comando split com uma das outras duas abordagens.
Uso do recurso de cópia de segurança em paralelo do pg_dump.
Para acelerar a cópia de segurança de um banco de dados grande,
pode-se usar o modo paralelo de pg_dump.
Isto irá salvar várias tabelas ao mesmo tempo.
Pode-se controlar o grau de paralelismo com o parâmetro
-j.
As cópias de segurança em paralelo têm suporte apenas para o
formato de arquivamento “diretório”.
pg_dump -jnum-F d -fout.dirnome_do_banco_de_dados
Pode-se usar o comando pg_restore -j para
restaurar uma cópia de segurança realizada no modo paralelo.
Isto irá funcionar para qualquer arquivamento realizado usando o
modo de arquivamento “personalizado” ou
“diretório”, tenha sido criado ou não com
pg_dump -j.
Exemplo 25.1. Exemplo do tradutor
Cópia de segurança em texto puro
Neste exemplo a usuária ana
cria duas cópias de segurança de seu banco de dados
calçados: a primeira contendo
somente esquema; e a segunda contendo apenas os dados do banco de
dados. Em seguida os arquivos de cópia de segurança são transferidos
para a sua usuária no servidor 192.168.3.6,
ao qual ela se conecta através de ssh
e restaura estas cópias de segurança usando o
psql.
$ sudo su - ana
$ pg_dump --clean \
--create \
--schema-only \
--file=cal_schema.sql \
calçados
$ pg_dump --data-only \
--file=cal_data.sql \
calçados
$ scp -p cal_schema.sql ana@192.168.3.6:
$ scp -p cal_data.sql ana@192.168.3.6:
$ ssh ana@192.168.3.6
$ psql ana < cal_schema.sql
$ psql calçados < cal_data.sql