Uma estratégia de cópia de segurança alternativa é copiar diretamente os arquivos que o PostgreSQL usa para armazenar os dados no banco de dados; em Criação do agrupamento de bancos de dados é explicado onde estes arquivos estão localizados. Pode-se usar o método preferido para fazer cópias de segurança do sistema de arquivos; por exemplo:
tar -cf backup.tar /usr/local/pgsql/data
Entretanto, existem duas restrições que tornam esta solução senão impraticável, no mínimo inferior ao uso do utilitário pg_dump:
O servidor de banco de dados deve ser
parado para obter uma cópia de segurança utilizável.
Medidas intermediárias, como proibir todas as conexões,
não vão funcionar
(em parte porque o utilitário tar, e ferramentas
semelhantes, não tiram um instantâneo atômico do estado do sistema
de arquivos, mas também devido ao
buffer interno dentro do servidor).
Informações sobre como parar o servidor podem ser encontradas em
Parada do servidor de banco de dados.
Também é desnecessário dizer que é necessário parar o servidor
antes de restaurar os dados.
Se forem pesquisados os detalhes da disposição do sistema de
arquivos do banco de dados, pode-se ficar tentado a fazer uma
cópia de segurança, ou restaurar apenas determinadas tabelas ou
bancos de dados individualmente, a partir de seus respectivos
arquivos ou diretórios.
Isto não irá funcionar, porque as
informações contidas nesses arquivos não podem ser usadas sem os
arquivos de WAL, pg_wal/*,
que contém o status de efetivação de todas as transações.
Um arquivo de tabela só pode ser usado com estas informações.
Claro que também é impossível restaurar apenas uma tabela e os
dados do pg_wal associados, porque isto
tornaria todas as outras tabelas na instância inúteis.
Portanto, as cópias de segurança do sistema de arquivos funcionam
apenas para cópia de segurança e restauração de uma
instância inteira.
Uma abordagem alternativa de cópia de segurança do sistema de arquivos
é fazer um “instantâneo consistente” do diretório de dados,
se o sistema de arquivos oferecer suporte a esta funcionalidade (e
caso se esteja disposto a confiar que está implementada corretamente).
O procedimento típico é tirar um “instantâneo congelado”
do volume que contém o servidor de banco de dados, em seguida,
copiar todo o diretório de dados (não apenas partes, veja acima) do
instantâneo para um dispositivo de cópia de segurança e, por fim,
liberar o instantâneo congelado.
Isto funciona mesmo quando o servidor de banco de dados está em
execução.
Entretanto, uma cópia de segurança criada dessa maneira salva os
arquivos de banco de dados em um estado como se o servidor de banco
de dados não tivesse sido parado corretamente; portanto, quando
o servidor de banco de dados for ativado usando os dados da cópia
de segurança, ele pensará que a instância do servidor anterior travou,
e reproduzirá os arquivos de WAL.
Isto não é um problema; mas deve-se estar ciente disso
(e certificar-se de incluir os arquivos de WAL
na cópia de segurança). Pode-se executar um
CHECKPOINT antes de tirar o instantâneo,
para reduzir o tempo de restauração.
Se o banco de dados estiver distribuído por vários sistemas de arquivos, poderá não haver nenhuma maneira de tirar instantâneos congelados simultâneos de todos os volumes. Por exemplo, se os arquivos de dados e arquivos de WAL estiverem em discos diferentes, ou se os espaços de tabelas estiverem em sistemas de arquivos diferentes, talvez não seja possível usar a cópia de segurança de instantâneo, porque os instantâneos devem ser simultâneos. Deve-se ler a documentação do sistema de arquivos com muito cuidado, antes de confiar na técnica de instantâneo consistente em tais situações.
Se tirar instantâneos simultâneos não for possível, uma opção é parar o servidor de banco de dados pelo tempo suficiente para tirar todos os instantâneos congelados. Outra opção é executar uma cópia de segurança base de arquivamento contínuo (veja Criação de cópia de segurança base), porque estas cópias de segurança são imunes a alterações no sistema de arquivos durante a realização da cópia de segurança. Isto requer ativar o arquivamento contínuo apenas durante o processo de cópia de segurança; a restauração é feita usando a restauração contínua do arquivamento (veja Restauração usando uma cópia de segurança de arquivamento contínuo).
Outra opção é usar o utilitário
rsync
para executar uma cópia de segurança do sistema de arquivos.
Isto é feito primeiro executando o rsync
enquanto o servidor de banco de dados está em execução e, em seguida,
parando o servidor de banco de dados pelo tempo suficiente para
executar rsync --checksum.
(--checksum é necessário, porque o
rsync só tem granularidade de tempo de
modificação de arquivo de um segundo.)
O segundo rsync será mais rápido que o
primeiro, porque terá relativamente poucos dados para transferir,
e o resultado final será consistente, porque o servidor estava parado.
Este método permite que seja feita uma cópia de segurança do sistema
de arquivos com o mínimo de tempo de inatividade.
Note-se que uma cópia de segurança do sistema de arquivos normalmente será maior do que uma cópia de segurança SQL. (O pg_dump não precisa salvar o conteúdo dos índices, por exemplo, apenas os comandos para recriá-los.) Entretanto, fazer uma cópia de segurança do sistema de arquivos pode ser mais rápido.