2009/3/13 Euler Taveira de Oliveira <[email protected]> > Fabrízio de Royes Mello escreveu: > > [mantenha a lista no -cc] > > > 2009/3/12 Euler Taveira de Oliveira <[email protected] > > <mailto:[email protected]>> > > > > O problema desse tipo de "backup" é que: (i) você fica preso a > > arquitetura > > (ii) versão do PostgreSQL (iii) parâmetros em tempo de compilação > > tais como > > BLCKSZ, XLOG_BLCKSZ e LC_CTYPE (só para citar alguns) (iv) além de > > ter que > > ficar um tempo fora (para garantir a consistência dos dados). > > Particularmente, > > são tantos os problemas desse tipo de "backup" que eu não o > recomendo. > > > > > > Estou ciente destas restrições, entretanto restaurar um backup desse > > tipo, de uma base muito grande, não seria bem mais rápido do que um > > pg_restore??? > > > Vide resposta no outro e-mail ao questionamento do Fábio. Eu só quis > ressaltar > as desvantagens do "backup" físico e nada mais. > > > Ou o melhor mesmo é utilizar o PITR conforme o Jota comentou?? > > > Ambas as soluções trabalham com cópia física do $PGDATA e tem desvantagens > semelhantes (as que citei acima). Porém, o PITR te oferece uma "perda" > menor > de dados já que você vai ter os dados de no máximo _archive_timeout_ > segundos > atrás. > > > Só faço esse questionamento pois cada uma das soluções tem suas > > vantagens e desvantagens não é mesmo... agora a respeito do PITR, em > > determinado momento eu não teria de fazer um backup lógico (pg_dump) ou > > físico (sistema de arquivos) e apartir desse momento no tempo "arquivar" > > os logs de transação??? ou seria melhor ter um outro servidor em > > "stand-by" fazendo os "recovery" sistematicamente (com isso temos uma > > replicação)??? > > > Gravar os logs de transação e o "backup" físico na mesma máquina que está o > PostgreSQL é um tiro no pé. E se o seu sistema de discos falha? Você > perderá > os dados e o "backup". > Quanto a utilizar um servidor de espera ("standby"), isso vai depender de > vários fatores tais como SLA e orçamento da solução. > > > Acredito que cada caso é um caso (velha máxima da medicina) e dependendo > > da situação podemos adotar uma ou outra estratégia... > > > > *Ainda* não tive problemas com esse tipo de backup do sistema de > > arquivo, apesar das restrições citadas, mas devido ao seu conhecimento > > do assunto esse comentário soa no minimo como um "alerta" para a forma > > como trabalho, e isso me deixou com "uma pulga atrás da orelha"... > > > > > -- > Euler Taveira de Oliveira > http://www.timbira.com/ > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
Boa tarde. Veja bem pessoal, eu não me lembro de ter lido algo nesta discussão dizendo que backup físico é a MELHOR opção e sim é uma das opções de backup que temos, é importante este bate papo que estamos tendo mas eu acho que perdemos um pouco o foco, eu perguntei sobre como retornar com esse tipo de backup, qual é a maneira mais adequada pra isso? -- Leandro Hamid SERPRO - Serviço Federal de Processamento de Dados Maito: [email protected] Maito: [email protected] Skype: leandro_hamid http://www.serpro.gov.br Weblog: http://sysaprendiz.wordpress.com/ Linux User #485051
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
