Nossa base tem 86GB. O dump leva 1 hora e o restore 1 hora para subir os dados. Depois leva mais um tempo [que varia de 9 a 11 horas] para criar constraints e índices.
On Dec 12, 2007 3:52 PM, Fabio Telles <[EMAIL PROTECTED]> wrote: > Em 12/12/07, Leandro Damascena<[EMAIL PROTECTED]> > escreveu: > > Fabio Telles escreveu: > > > Você já pensou em fazer backup físico ao invés de lógico? > > > > > > O backup lógico (dump) é muito bom para bases pequenas ou para > > > transportar dados entre versões ou ambientes diferentes. Mas para > > > restaurar uma base grande via backup lógico, o tempo de restauração é > > > realmente inviável. > > > > > > Atenciosamente, > > > Fábio Telles > > > > > Fabio, sei que você indicou isso para esse caso específico e pode > > parecer item básico para alguns da lista, mas como temos usuários de > > todos os níveis e já que estamos no assunto, vale a pena a conversa... > > - > > Backup físico não pode se tornar uma prática perigosa? Visto que hoje > > temos uma mistura muito grande nos data center da vida de máquinas > > 32bits e 64bits e fazendo o backup fisico pode ocorrer de precisar > > restaurar esse backup em uma máquina de arquitetura diferente e aí não > > há muito o que fazer... > > > > Falo isso pois eu tirava dump fisico de uma máquina 32 bits de um LDAP > > de um cliente e um dia a máquina morreu, trocaram ela por uma de 64 e o > > backup não subia, se não fosse a replica online que tinha, eu teria > > perdido toda a base.... > > Bom... isso é verdade. Você sempre imagina que vai restaurar o backup > físico num servidor com configuração semelhante. Mas o tempo de > restore é realmente algo importante. O backup lógico é algo mais > intuitivo e simples de manipular... > > Mas em uma base grande, pode demorar mais de um dia para fazer o > restore. Com o uso de storages, você faz o backup e restore em > segundos. Existe ainda a possibilidade de fazer um stand by também... > > Pensando bem... isto daria um bom artigo... > Mas enquanto isso, dê uma olhada na documentação oficial: > http://www.postgresql.org/docs/8.3/static/backup.html > > > > > Apenas para complementar o tópico, fiz um teste prático para ver como se > > comportava > > Teste: tar do pgdata da origem para o destino > > Origem: Linux myvm2 2.6.20-1.2320.fc5xenU #1 SMP Tue Jun 12 20:26:58 EDT > > 2007 x86_64 x86_64 x86_64 GNU/Linux > > Destino: Linux mymailserver 2.6.17-1.2142_FC4 #1 Tue Jul 11 22:41:14 EDT > > 2006 i686 athlon i386 GNU/Linux > > > > postmaster start - FATAL: incorrect checksum in control file > > > > Dando uma googlada achei alguns tópicos interessantes: > > http://www.thescripts.com/forum/thread423062.html - Comentário feito > > Note que aqui ele fala: "to load a newly transplanted database". Se > você teve uma pane de disco e trocou o disco... você não está > transplantando-o. Veja que subir um novo servidor não costuma ser algo > rápido também. A questão do backup físico é o tempo para colocar ele > de pé. Imagine por exemplo o tempo para você substituir um disco num > servidor hot-swap... > > Quando subimos o banco num servidor novo... estamos falando de > migração. Aí o backup lógico é mais flexível... e sempre mais lento. > > Atenciosamente, > Fábio Telles > -- > blog: http://www.midstorm.org/~telles/ > e-mail <http://www.midstorm.org/%7Etelles/e-mail> / jabber: > [EMAIL PROTECTED] > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Fernando Brombatti email-msn-gtalk-skype: [EMAIL PROTECTED] work: +55 54 3218-6060 mobile: +55 54 8112-7250 Visite www.datamais.com
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
