Quaisquer problemas com backups apenas do sistema de arquivos no PostgreSQL?

Question

Estou executando meu servidor de banco de dados na nuvem amazon e tenho os arquivos de banco de dados em um volume separado do EBS. Quando se trata de operações de backup / restauração, eu achei infinitamente mais simples fazer apenas um backup em nível de sistema de arquivos em vez de despejo em sql porque eu posso criar backups e restaurá-los quase que instantaneamente.

Há algum problema que eu possa estar negligenciando se eu usar somente backups em nível de sistema de arquivos?

Executando o PostgreSQL 9.1 (atualizando para 9.3 no final deste ano) no Ubuntu 12.04

    

Answer 1

Are there any possible issues I may be overlooking if I stick to using solely file system-level backups?

Sim, mas não o que você está pensando. Contanto que você faça a cópia no nível do sistema de arquivos correta, é a dependência de backups físicos que é o risco.

Ao escrever isso, notei que o capítulo sobre backups em nível de sistema de arquivos precisa ser atualizado para apontar os usuários em pg_basebackup e pg_start_backup() . Embora tecnicamente parte da replicação de streaming e do PITR, essas ferramentas são apenas formas de tornar cópias seguras e consistentes no nível do sistema de arquivos, e devem ser referenciadas nessa parte dos documentos.

Fazendo isso com segurança

Por a documentação do backup em nível de sistema de arquivos do PostgreSQL e fazer um backup básico , é bastante seguro fazer uma cópia no nível do sistema de arquivos, desde que você segue as regras dadas lá, ou seja, fazendo um dos seguintes:

• Parando o servidor antes do backup e deixando-o desligado até o backup terminar;

• Usando pg_basebackup ;

• Usando pg_start_backup() e pg_stop_backup() e copie os arquivos gerados por pg_stop_backup() ; ou

• Usando uma captura instantânea e cópia do sistema de arquivos atômicos a partir da captura instantânea, caso em que nada pode ser gravado nela porque é uma captura instantânea.

Você também pode usar pg_basebackup -X stream , que é minha preferência. Ele usa o protocolo de replicação para fazer uma cópia em nível de sistema de arquivos, cuidando de pg_start_backup() etc para você.

Os backups físicos têm a principal vantagem de poderem ser usados como base para a recuperação pontual. Recuperação pontual .

O caso do instantâneo é seguro porque é como uma falha. Não há escrita em andamento e o estado do banco de dados é capturado em um determinado momento. Os logs write-ahead contêm todos os dados de transação confirmados, portanto, qualquer coisa que ainda não tenha sido liberada para o heap é reproduzida do WAL durante a recuperação quando o banco de dados é inicializado pela primeira vez. É como iniciar após um acidente. Você só precisa de pg_start_backup() e amigos se estiver copiando um diretório de banco de dados ativo que ainda está sendo gravado enquanto você o copia; um instantâneo evita isso.

Note que confiar em instantâneos só é seguro se o instantâneo é realmente atômico , ou seja, ele captura o estado do sistema de arquivos em um único instante no tempo. Também é seguro apenas se houver exatamente um volume / sistema de arquivos envolvido - você não pode usar dois snapshots de dois sistemas de arquivos separados para fazer um backup, eles não serão do mesmo instante no tempo. Se você estiver usando espaços de tabela, os backups de captura instantânea não são seguros por esse motivo, mas pg_basebackup ou pg_start_backup() , rsync, pg_stop_backup() ainda é seguro.

Isso significa que, se o sistema de arquivos do banco de dados for (digamos) quatro volumes do EBS em um array md raid, ou você tiver um para pg_xlog e um para o restante do db, não será possível usar snapshots do EBS faça um backup consistente. Se tudo for um volume do EBS, um snapshot do EBS é seguro.

Você também pode parar o PostgreSQL antes de executar o backup e iniciá-lo depois. Se você é uma das pessoas sortudas que podem pagar por janelas com tempo de inatividade de backup, bem, isso é legal. Pessoalmente prefiro backup quente de qualquer maneira.

Riscos

O verdadeiro problema a se preocupar é que, quando você faz um backup físico, você copia a estrutura do banco de dados, desmarcada e não verificada. Se houver corrupção não detectada, você pode ter backups muito menos úteis do que você imaginava. Pessoalmente, eu também estaria usando lixões lógicos.

Um compromisso útil pode ser iniciar o backup no nível do sistema de arquivos assim que você fizer a cópia, em seguida, fazer um pg_dump do backup no nível do sistema de arquivos. Isso garante que seja legível e fornece uma cópia lógica. Se o seu despejo lógico falhar, sua automação deve estar enviando e-mails para você e gritando por ajuda, porque isso sugere que sua cópia física também pode estar danificada.

BTW, escrevi um monte sobre evitar problemas de perda / corrupção de dados em meu antigo blog há algum tempo - veja Evitando a corrupção do banco de dados do PostgreSQL .

    

Answer 2

Você pode fazer um backup do sistema de arquivos que seja confiável se você encerrar completamente o Postgres, ENTÃO faça o backup enquanto o Postgres estiver desligado. Quando o backup terminar, inicie o Postgres.

Se o Postgres estiver em execução durante o backup, todas as apostas estarão desativadas.

É melhor fazer o que foi mencionado acima, além de um backup adequado do banco de dados "dentro do Postgres".