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, porque sempre existe alguma buferização em andamento. Por esta razão também não é aconselhável confiar em sistemas de arquivo que dizem suportar "instantâneos consistentes" (consistent snapshots). 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). Este tipo de instantâneo 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).

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.

SourceForge.net Logo