Documentação do PostgreSQL 7.4.1 | ||||
---|---|---|---|---|
Anterior | Início | Capítulo 22. Criação e restauração de cópias de segurança | Fim | Próxima |
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:
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.