2008/8/21 Euler Taveira de Oliveira <[EMAIL PROTECTED]>: > Fábio Telles Rodriguez escreveu: >> 2008/8/20 Sebastian SWC <[EMAIL PROTECTED]>: >>> 2008/8/20 Fábio Telles Rodriguez <[EMAIL PROTECTED]>: >>>> Você não vai se arrepender. Agora, para os demais da lista, repitam comigo: >>>> >>>> pg_dump != backup >>>> >>> Fabio, o que exatamente você considera backup? >>> > O Fábio não respondeu, mas *backup* (aka cópia de segurança) é um > processo de cópia de dados de um dispositivo de armazenamento a outro de > modo que, estes dados possam ser restaurados em caso da perda dos dados > originais [1]. Rotinas de cópia de segurança dependem muito de quão > valioso são os seus dados. > >> Veja... imagina que você tem uma base de 200GB. Algumas tabelas de 2 >> ou 4GB. Pois bem, fazer um dump pode ser uma tarefa trivial, certo? E >> fazer o restore? Quanto tempo você acha que vai demorar para fazer o >> restore desta base? Você pode demorar umas 2 horas para gerar o dump, >> mas o restore pode levar facilmente mais de 24 horas. E mais, você vai >> ter que rodar o analyze em toda a base depois de terminar a >> importação. >> > Se você utilizar um *pg_restore -Fc -U superuser -f arquivo.dump*, > talvez sim! Mas nenhum DBA PostgreSQL irá restaurar uma base de 200GB > utilizando apenas *um* comando pg_restore, certo? É sabido que o > pg_restore é *CPU-bound*; você pode gastar em menos tempo utilizando > vários *pg_restore -Fc -U superuser -L listacomobjetos.file -f > arquivo.dump* e *set maintenance_work_mem to 'XXGB'*.
Sim, é verdade. Mas ainda assim, o restore de um backup físico é sensivelmente menor. Mesmo que você tenha vários processadores e faça dumps paralelos (o que alias é uma técnica muito recomendada de realizar dumps). > >> Sentiu o drama? Para recuperação de desastres (tarefa primordial do >> backup) o dump não é de forma algum adequado. O backup físico é a >> política número um de bakcup, seja ele feito on-line ou off-line. >> > No caso online, eu acho que não. A menos que tu tenha uma política de > arquivamento dos logs de transação. Em ambiente de produção, o arquivamento dos logs deveria ser obrigatório. Ok, cada caso é um caso. Mas o que ocorre é que como o arquivamento não é uma opção que vem habilitada por padrão no PostgreSQL, as pessoas costumam ignorar isso. É um erro lastimável. O outro erro é acreditar que tutoriais de 2 linhas e ferramentas como o webmin que realizam backup apenas com o pg_dump são confiáveis e ponto final. > Para recuperação de desastre, você deve levar em consideração quanto > tempo você pode ficar fora. Em uma base de 200GB talvez seja prudente > utilizar uma replicação assíncrona para garantir que o tempo _sem > operação_ seja pequeno. > >> É por isso que é equivocado achar que pg_dump é sinônimo de backup. > pg_dump é uma ferramenta. Já a política de cópia de segurança depende > dos requisitos (qual o valor dos seus dados?). Esse é o ponto. O PostgreSQL assim como Oracle, DB2 e outros bancos de dados corporativos possuem opções que lhe permitem estabelecer uma política de backup de acordo com o SLA da empresa. Replicação (síncrona/assincrona, multimaster/master-slave), clusterização, stand by (frio, morno e futuramente quente também) , backup lógico (compactado, binário, em txt), físico (on-line, off-line), snapshots (via storage, LVM2 e outros), e por aí vai. Temos zilhões de opções para casos específicos. Ou seja, volto a afirmar que pg_dump não é sinônimo de backup, é apenas uma opção dentre muitas. A questão "quanto valem seus dados?" deveria sempre ser escrita assim: "Quanto custa perder seus dados?". That's all folks :-D -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
