Opções de recuperação de desastre do PostgreSQL

Question

Meu cliente tem um tamanho bastante grande (o tamanho total da pasta "data" é 200G) do banco de dados PostgreSQL e estamos trabalhando em um plano de recuperação de desastres. Nós identificamos três tipos diferentes de desastres até agora: falta de hardware, carga excessiva e perda de dados não intencional devido a má migração erroneamente executada (como DELETE ou ALTER TABLE DROP COLUMN).

Os dois primeiros tipos parecem ser fáceis de mitigar, mas não podemos elaborar um bom plano de mitigação para o terceiro tipo. Propus-me a usar o ZFS e snapshots frequentes (de hora em hora), mas "ZFS" significa "OpenIndiana" atualmente e nossos engenheiros de operações não têm muita experiência nele, portanto, usar o OpenIndiana impõe outro risco. Os colegas tentam me convencer de que a restauração do backup do PostgreSQL PITR pode ser tão rápida quanto a restauração de um instantâneo do ZFS, mas duvido muito que a repetição, digamos, de 50G de WALs arquivados possa ser considerada "rápida".

Quais outras opções estão faltando? O ZFS é uma alternativa viável? Podemos obter um tempo de restauração rápido do Pg DB no ambiente Linux?

    

Answer 1

Por que o FreeBSD não é uma opção viável para rodar o ZFS e o PostgreSQL? Os desenvolvedores do FreeBSD ZFS trabalham muito próximos com a equipe Illumos e recentemente Pawel Jakub Dawidek (O homem que primeiro portou o ZFS para o FreeBSD) adicionou Suporte a SSD TRIM para ZFS . Isso provavelmente também será adicionado ao código do Illumos ZFS em breve.

Outra vantagem do FreeBSD e do ZFS é o framework GEOM . No Solaris, quando discos inteiros são adicionados a um pool do ZFS, o ZFS ativa automaticamente o cache de gravação. Isso não é feito quando o ZFS gerencia apenas fatias discretas do disco, pois não sabe se outras fatias são gerenciadas por sistemas de arquivos não-protegidos por cache, como o UFS. A implementação do FreeBSD pode manipular liberações de disco para partições graças à sua estrutura GEOM e, portanto, não sofre desta limitação.

    

Answer 2

Eu sugiro que você dê uma olhada no Barman, Gerenciador de Backup e Recuperação do PostgreSQL, que foi escrito por nós e está disponível como código aberto sob os termos da GNU GPL 3. Para se ter uma ideia, nós a usamos na produção em bancos de dados maiores que os seus (7 terabytes). A versão 1.0 foi lançada em julho. Já existe uma versão do RPM, o pacote Debian está a caminho (o Barman será incluído no Ubuntu 12.10). Para mais informações: www.pgbarman.org .

    

Answer 3

A reprodução de WALs arquivados é a melhor opção aqui e, provavelmente, a mais rápida.

É o melhor porque você recebe toda a linha do tempo. Nenhuma perda de dados em tudo. Com todos os tipos de instantâneos, você perderá dados. Instantâneos de hora em hora significam que, em um pior cenário, você perde 1 hora de alterações no banco de dados (o desastre acontece logo antes do próximo instantâneo).

Além disso, se você fizer físico (não lógico - requer instantâneo de db também, melhor para restaurar a tabela descartada, etc) a recuperação é feita no nível do bloco e é MUITO rápida.