postgresql - Abordagem para backup de arquivos 'live' / hot?

Question

Perdoe-me pela pergunta ignorante, mas vejo que o postgres tem seus logs do WAL, e há conversas sobre o uso de snapshots do sistema de arquivos, e o WAL com os snapshots pode ou não ser suficiente backup / recover ... tradicionalmente um administrador / administrador de banco de dados (sou um desenvolvedor), mas chego a um ponto em que busco melhorar o suporte a essas necessidades.

Pergunta: O Postgres pode ser configurado em um sistema de 10GB ou 100GB para usar um software de backup especial, mas apenas usar o software de backup tradicional do sistema de arquivos (snapshots do sistema de arquivos?) e ter um método razoável de recuperação. usando este método? (se o dimensionamento importa, gostaria de saber)

Usecase 1: para evitar uma abordagem especial de backup ao usar o Postgres e apenas usar o sistema de arquivos normal. Sem tempo de inatividade ou < 5 segundos.

Nota 2: Quando usado com um ECM híbrido, como o Alfresco, onde o conteúdo do sistema de arquivos (imagens) e os metadados (banco de dados) devem sempre ser armazenados em backup e restaurados em uníssono. Sem tempo de inatividade ou < 5 segundos.

Por favor, explique sobre áreas que eu posso não estar perguntando, tais como boas / más idéias ou coisas que devem ser observadas: -)

(note que isso é para instalação local em ambientes Linux, se um sistema de arquivos específico for necessário para uma estratégia, tudo bem).

TIA!

-D

    

Answer 1

Question: Can Postgres be setup on a 10GB or 100GB sized system to not use special backup software, but instead just use traditional filesystem backup software (filesystem snapshots?) and has a reasonable method of recovery using this method?

Sim, se os instantâneos do sistema de arquivos forem atômicos . Isso é extremamente importante. Você deve ter um snapshot atômico , você não pode simplesmente copiar o diretório de dados diretamente. O método usual é fazer um snapshot com uma SAN, um gerenciador de volume lógico, um sistema de arquivos com captura de snapshot, etc, e montá-lo em outro caminho, depois fazer o backup. Então você está usando um script de pré e pós-backup.

Aqui, "atômico" é usado em seu significado de ciência da computação, de indivisível, um único momento no tempo em que tudo é antes ou depois daquele momento. No caso de um instantâneo, significa um instante no tempo, o estado do armazenamento naquele momento específico.

Entendo que o Serviço de Cópias de Sombra de Volume da Microsoft (para Windows) é apenas atômico no nível do arquivo, portanto você não pode usar sistemas de backup que dependam dele para consistência.

Se você não estiver realmente usando um instantâneo do sistema de arquivos, apenas copiando os dados no sistema de arquivos ao vivo, ainda é possível fazer isso, mas é necessário executar etapas adicionais. De acordo com a documentação , você pode informar ao PostgreSQL que o backup é ocorrendo, e ele entrará em um modo sem sobrescrever que torna os backups seguros enquanto está em execução. No entanto, para restaurar esse backup, você precisa de arquivos que sejam gravados após o script de pós-backup que chama pg_stop_backup() runs . A maneira mais fácil de ter certeza de que você tem esses arquivos é garantir que arquivamento do WAL está ativado; caso contrário, você precisará de alguns ganchos de script extras em seu sistema de backup para anexá-los ao backup.

Usecase 1: to avoid special backup approach when using Postgres and just use normal file system. No downtime, or < 5 seconds.

Para isso, basta usar pg_dump ou pg_basebackup . Não requer tempo de inatividade e é simples.

Qualquer sistema de backup decente suporta ganchos pré e pós-backup que facilitam isso.

Usecase 1: to avoid special backup approach when using Postgres and just use normal file system. No downtime, or < 5 seconds.

Para isso você vai querer snapshots atômicos, e você precisará ter certeza de que as imagens estão no mesmo snapshot que o PostgreSQL.

Caso contrário, você arrisca inconsistências onde o sistema de arquivos e o banco de dados não combinam muito bem.