22.2. Cópia de segurança no nível de sistema de arquivo

Uma estratégia alternativa para fazer cópia de segurança, é copiar diretamente os arquivos que o PostgreSQL usa para armazenar os dados dos bancos de dados. Na Seção 16.2 é explicado onde estes arquivos estão localizados, mas provavelmente você já os encontrou se está interessado neste método. Pode ser utilizada a forma preferida para fazer as cópias de segurança usuais dos arquivos do sistema como, por exemplo:

tar -cf copia_de_seguranca.tar /usr/local/pgsql/data

Entretanto, existem duas restrições que fazem com que este método seja impraticável ou, pelo menos, inferior ao pg_dump:

1. O servidor de banco de dados deve estar parado para que se possa obter uma cópia de segurança utilizável. Meias medidas, como impedir todas as conexões, não funcionam (principalmente porque o tar, e as ferramentas semelhantes, não capturam um instantâneo atômico do estado do sistema de arquivos em um determinado ponto no tempo). As informações sobre como parar o servidor podem ser encontradas na Seção 16.6. É desnecessário dizer que também é necessário parar o servidor antes de restaurar os dados.

2. Caso tenha se aprofundado nos detalhes da organização do sistema de arquivos do banco de dados, poderá estar tentado a fazer cópias de segurança ou restauração de apenas algumas determinadas tabelas ou bancos de dados a partir de seus respectivos arquivos ou diretórios. Isto não funciona, porque as informações contidas nestes arquivos possuem apenas meia verdade. A outra metade está nos arquivos de registro de efetivação pg_clog/*, que contêm o status de efetivação de todas as transações. O arquivo da tabela somente possui utilidade com esta informação. É claro que também não é possível restaurar apenas uma tabela e seus dados associados em pg_clog, porque isto torna todas as outras tabelas do agrupamento de bancos de dados inúteis. Portanto, as cópias de segurança do sistema de arquivos somente funcionam para a restauração completa de todo o agrupamento de bancos de dados.

Uma abordagem alternativa para cópias de segurança do sistema de arquivos é fazer um "instantâneo consistente" do diretório de dados, se o sistema de arquivos possuir esta funcionalidade (e se há confiança que foi implementado de forma correta). O procedimento típico é tirar um "instantâneo congelado" (frozen snapshot) do volume que contém o banco de dados, depois copiar todo o diretório de dados (não apenas parte deste, veja acima) do instantâneo para uma unidade de cópia de segurança, e depois liberar o instantâneo congelado. Isto funciona mesmo com o banco de dados em operação. Entretanto, a cópia de segurança criada desta maneira salva os arquivos do banco de dados em um estado onde o servidor de banco de dados não foi parado de forma apropriada; portanto, quando o servidor de banco de dados é iniciado acessando um diretório restaurado a partir de uma cópia de segurança deste tipo, considera que o servidor caiu e refaz o registro do WAL. Isto não é um problema, mas deve-se estar atento a este fato (e certifique-se de incluir os arquivos do WAL na cópia de segurança).

Se o banco de dados estiver distribuído através de vários volumes (por exemplo, os arquivos e dados e o registro do WAL em discos diferentes) pode ser que não haja nenhuma forma de obter instantâneos congelados simultâneos de todos os volumes. A documentação do sistema de arquivos deve ser lida com muita atenção antes de acreditar na técnica de instantâneo consistente em uma situação como esta. A abordagem mais segura é parar o servidor de banco de dados pelo tempo necessário para estabelecer todos os instantâneos congelados.

Deve ser observado que a cópia de segurança do sistema de arquivos não será necessariamente menor que a do Método SQL-dump. Ao contrário, é mais provável que seja maior; por exemplo, o pg_dump não necessita fazer cópia de segurança dos índices, mas apenas dos comandos para recriá-los.